[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Summit Agenda - Build System questions
|
Cool. Thanks, Chris. I think we still need an exemplary implementation
of a makefile generator to prove we can still do it as we muck with the
project/build model. But I agree we should probably just pick one make
variant and stick with it. The obvious choice here would be gnu make.
And pick MinGW over Cygwin for Windows, mainly because of the issues you
mentioned. And I think we should focus on simplifying the makefile
generator, and especially the pattern it generates. I think we were
trying to meet some requirements that I think we can dump (like forcing
a rebuild when certain build settings changed). Keep it simple. But we
need to keep it.
Doug.
________________________________
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
Sent: Tuesday, September 09, 2008 10:40 AM
To: CDT General developers list.
Cc: CDT General developers list.; cdt-dev-bounces@xxxxxxxxxxx
Subject: RE: [cdt-dev] Summit Agenda - Build System questions
So as the person that raised the original question of whether we
should keep supporting generating makefiles or not, I guess I should
jump in and give my $0.02 as to why I raised it in the first place...
* In the past it's handcuffed us as to what we could do
with the build system, because if we couldn't do it with make, we
couldn't do it. Furthermore, some things, while possible with make, get
really complicated.
* Difficulty in supporting the different flavours of make
on different platforms, which is a constantly moving target. E.g., at
some point CygWin make stopped supporting windows paths, which nuked a
lot of people.
* Who is going to work on supporting it? I can see IBM
possibly spending resources on the standard make builder and the
internal builder, but we have little interest in generating makefiles if
we can get headless builds working better with the internal builder.
* The makefile generator code is pretty hairy, and if we
end up reworking the project model at all, I foresee a lot of ugly work
in the builder.
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
"Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>
"Schaefer, Doug"
<Doug.Schaefer@xxxxxxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx
09/09/2008 09:34 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
+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
