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
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
