Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Summit Agenda - Build System questions

Of course. Most CDT users actually use standard make, especially in the
commercial world. We'd be fired if we got rid of it ;).

Incremental isn't necessarily as obvious. We would need the mapping from
source file to build target handy. And what if you change a header file?

Or is what you really want is the CDT to find your errors without having
to call the compiler at all. I wonder how close we are getting to being
able to do that...

Doug.
 

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Elmenthaler, Jens
> Sent: Tuesday, September 09, 2008 10:23 AM
> To: CDT General developers list.
> 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
> 


Back to the top