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

[Chris Recoskie <recoskie@xxxxxxxxxx>]

This is a prime example of the kind of feature which is hard to do in a generic way in order to support command line builders. How do we know what target to actually build? On some platforms it will be .o by convention, on others, .obj. In theory, especially with a standard makefile where the user is able to specify whatever naming scheme they wish, there is no real way to know what the right answer is.

For building and cleaning selected files, we were more or less forced to rely on the internal builder, because it knows what outputs are derived from which inputs. We can then ask it to execute all build steps required to build the targeted file.

===========================

Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt

"Elmenthaler, Jens" <jens.elmenthaler@xxxxxxxxxx>

"Elmenthaler, Jens" <jens.elmenthaler@xxxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx

09/09/2008 10:22 AM

Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

To	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject	RE: [cdt-dev] Summit Agenda - Build System questions

Just curious: What about the standard make?

Is it kept?!
Any ideas for incremental build support, e.g. calling "make resource.o" when it is saved instead of calling the incremental make target?

Greetings, Jens

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaefer, Doug
Sent: Tuesday, September 09, 2008 15:35
To: CDT General developers list.
Subject: RE: [cdt-dev] Summit Agenda - Build System questions

+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
> 
_______________________________________________
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