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 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=178765,
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
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
