[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
![Inactive hide details for "Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>]()
"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> |
|
|
+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
