In message <20121012212824.gp12...@chiark.greenend.org.uk>
Theo Markettos <t...@markettos.org.uk> wrote:
> On Fri, Oct 12, 2012 at 08:58:33PM +0100, John Tytgat wrote:
> > I don't think it is difficult to implement this, do people see value
> > in this idea ? Will this solve the auto* issues we're having in
> > Autobuilder ?
>
> I don't know the issue Alan's been having, but generally IME running
> automake/autoconf is the wrong idea. A program will come with an existing
> ./configure script.
Some packages need changes in configure.{in,ac} or Makefile.{in,am}
so you need to run automake/autoconf to take those changes in your build.
Another approach is to create patches for the configure/Makefile which
are part of the source tar ball but I'm not in favour of that as this
is very fragile.
> We can fudge the decisions the script makes by making
> ro-config set extra variables which show up as 'cached' settings to
> ./configure (all the stuff in ro-config like 'export ac_lt_cv_foo=yes'), or
> passing those variables to ./configure in setvars. Unless the script can't
> be fudged in this way, or is never supplied at all (eg direct repository
> checkouts), I'd stay a long way away from running autoconf/et al.
I agree with this advice but in some cases you need to run the auto*
tools. Or those auto* tools get run as part of the package build because
it thinks the already created configure{.in}, Makefile{.in} files are
outdated.
BTW, the export of environment variables is the way to go for
autoconf tests which are based on running the built test program (not
all autoconf tests are like that, some only use the preprocessor, some
only a compile and some a compile + link). That of course doesn't work
in cross-compile environment so the solution is indeed to predefine the
intended outcome of such test via an environment variable.
> If we build this stuff already as part of GCC, could we just copy the
> autoconf/etc binaries into $GCCSDK_INSTALL_ENV/bin/ as part of the install
> process? I'm not sure how to ensure the right version got run though.
> Maybe something for a package's setvars/preprocess to handle explicitly?
For gccsdk 4.7.x @ trunk we're building automake 1.11.1 and autoconf 2.64
so very specific versions, e.g. for 4.1.2 branch, that's automake 1.9.6
and autoconf 2.59. I wouldn't make the for gccsdk built versions available
to autobuilder as this would couple things too much.
Basically I was thinking if a package really needto do automake/autoconf,
it can set e.g. "NEED_AUTOMAKE=1.11" and "NEED_AUTOCONF=2.63" and in
build-program we fetch the right automake/autoconf sources from ftp.gnu.org
and build those and make sure that in PATH used to finally build the
package you have the bin directory of the installed automake/autoconf
you've just built. See the top Makefile of gccsdk gcc4 directory. I.e.
basically the same idea as gccsdk build system is doing.
John.
--
John Tytgat, in his comfy chair at home BASS
john.tyt...@aaug.net ARM powered, RISC OS driven
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
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
