[gccsdk] [GCCSDK commit] cpalmer - r4148 - trunk/autobuilder

Chris Palmer 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
>>
>> Modified:
>>    trunk/autobuilder/build
>> Log:
>> 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 @@
>>         popd
>>      fi
>>    fi
>> -  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?
> 
> Cheers,
> Jan-Jaap
> 

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 
becomes.

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 
those.

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?

Chris.






More information about the gcc mailing list