RE: [cdt-dev] Summit Agenda - Build System questions

["Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>]

+1. While I use the internal builder whenever I use the CDT, there are
pretty obvious cases where you would need a makefile. I'd actually like
to see this turn into a action, though, i.e. Generate Makefile. Or
something like that, so you can keep using the internal builder but
generate a makefile for inclusion in a loadbuild process, for example.

Beyond that, I would like the internal builder to become as capable as
make, which was the initial goal of the build model. I still think this
can be achieved and would like to hold that as the bar.

Cheers,
Doug

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
> Sent: Tuesday, September 09, 2008 4:34 AM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] Summit Agenda - Build System questions
> 
> I also agree that generating Makefiles is important to 
> support.  Even if it becomes more and more deprecated as time 
> goes on.  We had issues with the Internal Builder in CDT 4 
> (that were difficult to reliably reproduce and track down).  
> When the internal builder is the clear winner I'm sure 
> there'll be much less opposition to this move.
> 
> > I don't know how to make a nightly build using just 
> internal builder.
> > Switching to "make" mode is an easy way to generate make files in 
> > order to launch build from command line. It seems to me important.
> 
> As an aside this is indeed possible.  There are a few bugs in 
> bugzilla which discuss this issue, see the comments in: 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=186847
> 
> Cheers,
> 
> James
> 
> >
> > Alex
> >
> >
> > Treggiari, Leo wrote:
> > > I was just looking at the current agenda and have some 
> input for a 
> > > couple of the Build System questions:
> > >
> > >     * >> Should we continue to support generating a makefile?
> > >
> > > I'm guessing that the unspoken part of this question is 
> whether the 
> > > internal builder is sufficient. I can think of a couple of
> > reasons why
> > > it may not be:
> > > 1. Certainly in the 3.1 timeframe, the internal builder did not 
> > > implement all of the MBS schema attributes that the
> > makefile generator
> > > does. I don't know how much the internal builder was
> > enhanced in 4.0.
> > > At the least, some significant testing would need to be
> > done using the
> > > existing MBS JUnits and other examples to ensure that the 
> internal 
> > > builder does handle all of the model.
> > > 2. Generating makefiles supports the ability start with a managed 
> > > project and then later decide to convert to a "makefile" 
> project and 
> > > maintain the makefile yourself. I'm not sure how 
> important this is, 
> > > but it would be a loss of functionality.
> > > What are the reasons for removing makefile generation support? Is 
> > > maintaining the support a large burden?
> > >
> > >     * >> Concurrency Issues
> > >
> > >     * Deadlocks, deadlocks, deadlocks
> > >     * What is the reason most of these are happening? How can the
> > >       architecture be changed to help alleviate this?
> > >
> > > I looked at this a couple of times some time ago. I
> > believed that the
> > > problem had to do with the indexer getting kicked off
> > before the build
> > > system information for a project was loaded. The indexer asks for 
> > > configuration information and then the build system needs
> > to load the
> > > information and somewhere in that process is the deadlock 
> potential.
> > > My thought, at the time, was that we needed some mechanism for 
> > > specifying the set of project open tasks and either an explicit 
> > > ordering capability, priority settings, ...
> > > If we could get the "phone" attendance working, I could 
> attend the 
> > > build system discussion on Tuesday or Thursday. I can't attend on 
> > > Wednesday.
> > > Thanks,
> > > Leo
> > >
> > --------------------------------------------------------------
> > ----------
> > >
> > > _______________________________________________
> > > cdt-dev mailing list
> > > cdt-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >
> >
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>