[gccsdk] [GCCSDK commit] cpalmer - r4148 - trunk/autobuilder
cpalmer at maths.otago.ac.nz
Sun Oct 4 16:48:20 PDT 2009
Jan-Jaap van der Geer wrote:
>> Author: cpalmer
>> Date: 2009-09-28 18:52:08 -0700 (Mon, 28 Sep 2009)
>> New Revision: 4148
>> Need automake-1.7
>> Modified: trunk/autobuilder/build
>> --- trunk/autobuilder/build 2009-09-28 23:24:20 UTC (rev 4147)
>> +++ trunk/autobuilder/build 2009-09-29 01:52:08 UTC (rev 4148)
>> @@ -77,7 +77,7 @@
>> - for build_prog in cvs svn wget autoconf automake rman realpath pkg-config doxygen xgettext unzip autoconf2.13 flex bison gperf glib-genmarshal xsltproc intltoolize ; do
>> + for build_prog in cvs svn wget autoconf automake rman realpath pkg-config doxygen xgettext unzip autoconf2.13 flex bison gperf glib-genmarshal xsltproc intltoolize automake-1.7 ; do
>> if ! type $build_prog > /dev/null 2>&1 ; then
>> echo "Autobuilder: $build_prog not found; is it installed on your path?"
>> exit 1;
> I may well be missing something, but I am a bit suspicious about
> these changes, I have seen several of these added recently. This
> particular one makes building vala complaining on my machine that
> it needs automake 1.7, while it coped fine without it previously.
> I'm sure there are some packages that need automake 1.7 but is
> enforcing they are available in the general buildscript the correct
> way to go?
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
More information about the gcc