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

Hi Doug/Chris,


Sorry for spoiling the original scope of this thread, and yes - I agree to both of you.


One driver is the need to find the errors early. Since Monday I understand that symbolic links for include paths or header files are a bad idea. After applying a workaround to my plugins, turning on syntax coloring for the indexer problems comes close. This is really  a big achievement! Give Markus another year and the ability to tame templates and the standard headers – done.


The second driver for me is large projects and users who know which directories to build in order to go debugging right away. I guess make targets are supposed to do that. However, in large projects running a make target refreshes the entire project which nullifies all the time advantage (, this is actually blocking me from doing it myself).


Then a make target could be created dynamically according to some user setting specifying the target. It uses the same builder as the project and the working directory is the one of the saved resource. All that is remaining to a user in this scenario is to manually run the make target for the executable, shared library, etc (which is nothing at all in most of our cases).


Greetings, Jens.


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
Sent: Tuesday, September 09, 2008 16:45
To: CDT General developers list.
Subject: RE: [cdt-dev] Summit Agenda - Build System questions


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

Inactive hide details for "Elmenthaler, Jens" <jens.elmenthaler@xxxxxxxxxx>"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>


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



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.


> -----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:
> 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
> > >
> > >
> >
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> >
> >
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
cdt-dev mailing list
cdt-dev mailing list

Back to the top