Re: [cdt-dev] F1 CDT works under Linux but not Windows

[turnham@xxxxxxxxxx]

Hi,

Not sure I have good answers to any of your questions, but I'll give it a
go:

>Some things I've never understood in terms of the process of
>development:
>1. Why is the cdt is in a separate CVS archive instead of just being a
>separate CVS module in the same archive? In fact, with all the Eclipse
>plug-ins popping up on SourceForge and elsewhere, it would seem that it
>would make much more sense to encourage these developers to work out of
>an eclipse.org repository in the name of building a community. Of course
>if we can't integrate the cdt stuff, I guess it would be silly to expect
>some random plugin to have a project there...

This is a question for the folks at Eclipse.org (specifically the tools-dev
mailing list).  We (and GEF) are technically sub-projects of the "Eclipse
Tools Project" (http://www.eclipse.org/tools).  The operation of the CDT
(and GEF) is overseen by the "Eclipse Tools PMC (Project Management
Committee)", so any changes such as the ones you describe would require PMC
approval.  Requests\Questions of this sort will get answered on the
tools-dev mailing-list.


>2. The CDT build process (though somewhat obscure, much better
>documented now thanks to Jeff!) at least has a fairly simple "make" kind
>of interface. Of course all the other components have their own make
>processes. This is fine, but there should be documentation for each
>process, and it would help if there was a single top level build process
>that could bootstrap the whole shebang... So wouldn't it be more
>efficient to spend a little time cleaning that up in an effort to
>simplify the process for everyone?

Again this sounds like a question for the folks at Eclipse.org.  We are
nothing more than an extension to Eclipse and rightly have no control over
how other components build themselves.  Back when we were setting up our
nightly build processes, we found no standard way for building plugins from
the command line so we invented our own.  I know other groups that also use
makefiles, but many use Ant and I even know of one plugin (which shall
remain nameless)
that uses REXX ;-).  I think you should post your question about a standard
way for Eclipse plugins to built from the command line (and a 1-touch build
everything capability) to the eclipse newsgroup or a mailing-list.

>3. While I understand it's good to compartmentailize some development
>such that the cdt stuff is being developed with the 'last known good'
>core eclipse stuff, it would also be good to be building it with the
>current stuff so there is a shorter feedback loop to concurrent
>versioning. Has anyone looked at that?

I'm not sure I understand what the purpose of this build would be:

1.  Would it be to simply provide notification that the Bleeding Edge of
Eclipse breaks the CDT build?  If so, then I don't think it would be all
that useful.  The state of the code in Eclipse's CVS is not guaranteed to
be buildable itself, so we would probably spend time tracking down build
breaks that would just get fixed as a matter of course in the next
Stable\Integration Eclipse build anyway.

2.  Or would it be to provide some sort of package that is a combination of
the latest Eclipse and latest CDT?  If so, then I'm not sure anyone would
really want to use it.  It is risky enough to use a untested nightly build
of CDT with a tested Eclipse, but an untested CDT with an untested Eclipse
would probably be more trouble than it's worth.

Anyway AFAIK, Eclipse has not yet made the scripts they use to do their
internal builds (command-line ant) available yet, so even if we wanted to
add this to our nightly builds I don't think we could.

>4. The core eclipse CVS has a vast quantity of tag information. This is
>actually pretty useful in terms of trying to determine where stuff
>changed and which changes went together. Has anybody looked into a
>policy for tagging more like what the eclipse core is doing?

Yes we've talked about this before.  Recently I've started tagging our CVS
whenever we move to build against a new stable Eclipse (so there are M5,
I20020521 and F1 tags for example).  If we simply started tagging every
nightly build with the date (20020530, 20020531, etc) would that be what
you're looking for?

>Anyway, there's my questions/opinions... They're free and probably worth
>at least that much :). Thanks for listening.

Keep 'em coming ;-)

Jeff.