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.
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
