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

[Subs <dmsubs@xxxxxxxxxxxxx>]

I'd echo this - removing makefile generation would be a disaster.

Makefiles fit easily into existing build frameworks, are cross-platform 
(e.g. develop on Windows, but build on Linux), run quickly (this is very 
important) and are can run completely unattended (who will be around to 
dismiss that "Problem has occured" box...)

Please don't remove makefile generation - you wil lose a lot of 'customers'.

Alex Chapiro wrote:
> 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.
>
> 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


--
Subs