[gccsdk] [GCCSDK commit] cpalmer - r4148 - trunk/autobuilder
cpalmer at maths.otago.ac.nz
Mon Oct 5 16:33:53 PDT 2009
John Tytgat wrote:
> In message <4AC93444.30309 at maths.otago.ac.nz>
> Chris Palmer <cpalmer at maths.otago.ac.nz> wrote:
>> I would prefer that they stay - my plan was to get all the libraries
>> building successfully using build-libs (like Peter asked people to do a
>> month or so ago), then wipe my Debian install and start from scratch, so
>> I could see whether it's straightforward for anyone starting from
>> scratch to build all the libraries. However, the more packages that are
>> needed to build the libraries, the more cumbersome the main build script
>> I guess there are three options here:
>> 1. Keep it as is, perhaps with some more complicated system that
>> determines what packages have what programs and suggest the user install
>> 2. Remove the check from the build script and list the packages in a
>> file somewhere, so people can see what they need to have installed
>> before they start. The problem with this is that people may not be aware
>> of the list.
>> 3. Move the build dependencies to each individual package, so that along
>> with a depends file in each package directory, there is also a
>> build-depends package which says what native tools you need installed.
>> This would reduce the automation of the build process somewhat, in that
>> the current method requires all the native tools installed before you
>> start, so that once that is done the entire build can (in theory)
>> proceed from start to finish without user input.
>> I'm in favour of 1, since it currently won't require as much maintenance
>> work as the other two, and won't require any work to set up, as it's
>> already there.
>> Any thoughts?
> I like the intention but fear a bit the fallout for the occasional user or
> newbie autobuilder. Perhaps the list should be splitted in two, the
> ones we consider as vital and the others which are occationally needed
> for building some packages.
> If you miss the one of the former list, you get a build error; when you
> miss one of the latter list, you get a warning at start of your build
> that a build error later on might be due to missing build tools.
That's a good possibility. The main issue with that is determining what
is vital and what is not. I guess one metric that could be used there is
the number of packages that need a build tool, or whether a library used
by several applications or other libraries needed that tool.
Another possible approach to this problem would be to add a flag to the
build scripts enabling the user to turn on or off the abort on missing
build tools check. We could default it to being on, and people who knew
what they were doing could turn it off. Or the reverse, if the majority
prefer it that way.
I've just struck yet another build tool dependency while running
build-libs (this time xaw3d needs imake), so I'd like some consensus on
the way forward, even if it is just to do nothing, or to continue adding
tools the way I was doing.
More information about the gcc