[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] FW: [eclipse-dev] Issues with large-scale development
|
Johan,
We have similar needs for multiple indexer profiles,
but in our case they structure around having different
top level make targets. Ie,
make foo
and
make bar
will cause completely different include paths
and macro definitions to be used. A developer
would need to choose to look at a project
within the context of one make target or another.
It sounds like your indexer profile need is a
subpart of my multi-target need... ie, in C/C++,
we need someway of looking at the same code
from different perspectives (and don't
get me started on the interesting and useful
things you could do once Eclipse is aware of
all of those perspectives :)
Ed
Johan Walles wrote:
Don't know whether this qualifies (you be the judge of that), but how
about "https://bugs.eclipse.org/bugs/show_bug.cgi?id=25682" "Indexer
profiles"?
The connection with large projects would be the assumption that large
projects tend to be cross-platform. Cross platform projects have some
common files and some platform specific files (I'm talking about a C
project here).
An indexer profile would be a way of telling Eclipse what files are
relevant to a certain platform. Thus, in the C case I could define a
Linux profile and a Windows profile. The profile would contain
information about what macros are #defined, and what files should be
indexed by the CDT indexer.
Inside the IDE I could then say "let me look at the code for Windows
ia32", and the IDE would care only about the files relevant to that
profile.
This is a migration issue as well; currently we have a Visual Studio
project that needs to be updated every time a file is added. Having
yet another IDE that needs to have the same information updated
manually wouldn't really be accepted.
Regards //Johan
Thomas Fletcher wrote:
Forwarding just in case this request for information is interesting
to some of the CDT folks.
Thomas
------------------------------------------------------------------------
*From:* eclipse-dev-admin@xxxxxxxxxxx
[mailto:eclipse-dev-admin@xxxxxxxxxxx] *On Behalf Of *John Arthorne
*Sent:* November 5, 2004 1:22 PM
*To:* eclipse-dev@xxxxxxxxxxx
*Cc:* platform-core-dev@xxxxxxxxxxx
*Subject:* [eclipse-dev] Issues with large-scale development
One of the major development themes for Eclipse 3.1 is to improve
support for "Large-scale development" in Eclipse. This includes
improving collaboration for large, distributed teams, but it also
encompasses support for large workspaces. The Eclipse committers
form a large, distributed group, so we have no problems gathering
requirements for the first aspect of the problem. However, we don't
tend to work on very large projects or have very large workspaces
(Eclipse is broken up into many small projects and each committer
tends to only work with a handful of them). This makes it difficult
for us to see the most pressing and important problems for those
working in such environments. Bug reports have helped us identify
some areas with room for improvement, such as project creation (bug
74392), recursive deletion (bug 10628), and building (bug 60803). We
are making progress on these fronts, but want to make sure we are
not missing other problem areas for users with very large workspaces
and/or locally mounted remote file systems.
This is a general call for those using Eclipse for large-scale
development to let us know what the major problem areas are. What
operations are very slow? Could the UI be improved or made more
responsive during long operations? We are particularly interested
in applications of Eclipse beyond the Java IDE realm, such as in CDT
and web tools. Don't hesitate to also remind us about old bugs that
have already been reported that are still important to you, as they
sometimes get lost in bugzilla.
Please respond with issues and suggestions on the platform-core-dev
mailing list. We don't promise to address all of the problems that
people may raise, although help with identifying problems and
implementing and testing solutions can greatly improve a bug's
chances of being fixed. Clearly there is a lot of potential work in
this area, so we want to ensure that we are focused on the areas
with the largest potential gain for the Eclipse community.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev