IRC channel logs
2013-12-01.log
back to list of logs
<jmd>Is hydra.gnu.org having problems? <jmd>gnu-build-system doesn't work with configures created with earlier versions of autoconf <mark_weaver>what makes you say that? it works with plenty of ancient packages. <jmd>I'm preparing a report now. But basically older configure does not accept command line arguments of the form SHELL=xyz <jmd>This is because newer configures have the following snippet: <jmd> ac_envvar=`expr "x$ac_option" : 'x\\([^=]*\\)='` <jmd> # Reject names that are not valid shell variable names. <jmd> case $ac_envvar in #( <jmd> '' | [0-9]* | *[!_$as_cr_alnum]* ) <jmd> as_fn_error $? "invalid variable name: \\`$ac_envvar'" ;; <jmd> eval $ac_envvar=\\$ac_optarg <jmd> export $ac_envvar ;; <jmd> # FIXME: should be removed in autoconf 3.0. <jmd> $as_echo "$as_me: WARNING: you should use --build, --host, --target" >&2 <jmd> expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null && <jmd> $as_echo "$as_me: WARNING: invalid host type: $ac_option" >&2 <jmd> : "${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option}" <jmd>But in older ones, the *=*) clause is absent. <jmd>Hence, if one tries to run ./configure SHELL=/nix/blahblahblah it triggers the <jmd>invalid host warning. <jmd>Somewhere between Autoconf 2.13 and 2.24.5 the behaviour changed. <jmd>I'm not sure what the solution should be. Maybe run <jmd>SHELL=/nix/blahblah ./configure <jmd>but in pathalogical cases that could also be problematic. <mark_weaver>It might actually be reasonable to just make a patch to add the *=* clause to the configure script. <mark_weaver>I've had to patch a couple of old configure scripts to get things to build on MIPS. <jmd>I was trying to build libgnome <jmd>Do you mean patch it in the package, or in the build-system ? <mark_weaver>I don't understand the question, but you can look at the commit I cited above to see precisely what I had I mind. <jmd>I was wondering if you wanted the workaround in gnu-build-system.scm <jmd>To patch the configure <mark_weaver>it would be hard to make a general mechanism to do that. <jmd>Yeah. And probably self defeating. <mark_weaver>and the problem seems to be rare enough that patching around the few cases doesn't seem so bad. of course, poking upstreams to upgrade their build system would also be good. <civodul>did you find a way out of the problems you were experiencing? *jxself is trying to convince someone to free their documentation <jmd>civodul: Which ones? <jmd>One thing that guix makes clear: There is no combination of gnu packages, which unpatched, can build with each other. <jmd>mark_weaver: Without resorting to multiple versions I mean. <civodul>jmd: that's a bit of an overstatement, i think :-) <civodul>look: Guix can be built with an unpatched Guile! <jmd>Try getting all the gnome packages to build against each other!