[sword-devel] Autotools Bug?

[Jonathan Marsden]

Greg Hellings wrote:

> If the configure script can't find a required tool or library, it
> should die and issue an appropriate error message.

Seems reasonable, although "should" is maybe a bit strong.  Isn't that 
what AC_REQUIRE_CPP does?  I'll check it out this evening at home, if I 
have a chance.

> In this case, configure was just testing through and couldn't find 
> g++ and any of about a dozen other C++ compilers, but it continued
> ...

I think that's the default behaviour.  The search for a C++ compiler 
done by AC_PROG_CXX just defaults to g++ if it can't find one, rather 
than exiting with an error.  I'd guess there are historical reasons for 
that choice.

> I think it should fail, but the failure should be inside of
> configure.sh ...

OK.  I'm fairly sure that's "just" a matter of instructing autoconf to 
do what you want it to do.

> One of the problems with running sudo is that in many configurations
> (including the default configuration on Ubuntu) it "remembers" that a
> particular console or session is authorized for a certain amount of
> time, which would make it possible for extraneous sudo commands to
> slip into the configure or make system.

That's the kind of thing that led to sudo -k .  Security-conscious users 
who use sudo and are about to run untested scripts from unknown source 
tarballs should use sudo -k before running them.

> And the claim is not entirely academic - there have been a few
> isolated cases where a library's build system, after asking for root
> permissions, downloaded and installed code which was harmful to the
> user.  As such, I wouldn't ever supply my root password to a
> configure script without being VERY sure I knew who it came from.

Sure; but I wouldn't run a script with a non-standard name that even 
doesn't look like it was generated by autoconf, in an unfamiliar 
apparently-autoconf-using setup, without reading it first anyway -- even 
as my regular user ... it might add 'interesting' stuff to my .bashrc , 
or alias su or sudo to do very naughty things, or just /bin/rm -rf ~ :|

One should probably be building and testing untrusted code in a VM 
anyway, or if not, at least in a chrooted build environment, if system 
security is an important concern.  Which is often is, or often should be!

Seeing an unexpected or unexplained sudo password prompt is not an 
absolute sign of a problem in a script, IMO -- just a sign that you 
forgot to read through the script before running it!

> I have no problems with autogen.sh - I've seen something similar on
> almost every auto-tools based project I've pulled from a VCS.

autogen.sh seems fundamentally unnecessary to me.  If a couple of minor 
tweaks are made to configure.am and Makefile.am (tweaks which should be 
made anyway, since autoreconf really is supposed to work when used on an 
autotool-based source tree!), then what autogen.sh does is what 
autoreconf normally does -- or else I am misunderstanding what 
autogen.sh is all about, hence my questions regarding it :)

> The real problem here is that autotools isn't behaving properly -
> e.g. alerting the user that required programs aren't found.

As noted above, as far as I can tell, that's "just" a matter of telling 
autoconf that "alert and die" is the behaviour you want from its 
configure script regarding a C++ compiler, since, for whatever reason, 
that is not the default.  If it really is as easy as adding 
AC_REQUIRE_CPP to configure.ac, I'll provide a trivial patch in a few 
hours :)

Worst case we might have to use an AC_CHECK_PROG macro to test for this. 
  It's not a "real problem" either way, I think, more a matter of your 
expectations not exactly matching those of whoever created SWORD's 
configure.ac file, nor those of autotools' defaults.

Incidentally, running a quick autoscan on the SWORD 1.6.0RC3 sources 
suggests there are several things which "should" be being checked for 
but which are not currently being checked.

Jonathan