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

[Joe deBlaquiere <jadb@xxxxxxxxxx>]

On Thu, 2002-05-30 at 11:42, turnham@xxxxxxxxxx wrote:
> >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.
> 

I don't necesarily think the 'today's build doesn't build' info is
useful either, but it would be nice to have the CDT status being
monitored as the integration and stable builds. There are basically two
ways to handle the "stack of components" build:

1. build things in a waterfall like you have today where subsequent
components are built against the previous components stable version.
This has the problem that components further down the food chain tend to
lag.

2. build everything together. There is a tendency to end up with more
interdependencies in this model and you have to be willing to endure the
misery of getting everything building together and sychronizing the
integration process. 

Most of the time you end up somewhere in the middle. the CDT stuff tends
toward situation 1 above. Maybe if some of the barriers to building
everything together were removed developers would work on keeping things
up to date. What can I say, I'm a bleeding-edge addict... ;)

> 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.
> 

Is there a plan to make the magic beans available? Will I need to dust
off the REXX books? 

> >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?
> 

Actually you're pretty close now, I just thought it might be good to
have a consistent policy with all of eclipse and eclipse-tools... Some
of the eclipse tags seem cryptic to me. Tag-of-the day is going a little
far IMHO, and you can always check out by date. And besides, you have to
know that 16 May was "something special" in order to know what to get. 

Is there some sort of Changelog that is keyed to the CVS tags? 

-- 
Joe deBlaquiere
Red Hat, Inc.
voice : 256-217-0123
mobile: 256-527-5633
fax   : 256-837-3839
jadb@xxxxxxxxxx