[sword-devel] Autotools Bug?
greg.hellings at gmail.com
Mon May 11 14:18:36 MST 2009
On Mon, May 11, 2009 at 4:00 PM, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
> Greg Hellings wrote:
>> The install was not 100% fresh... I had already tried to do
>> autotools.sh, and thus installed automake/conf and libtool.
> OK. I suspect that the number of developer machines out there which have a
> working autotools installation, but no C++ compiler, is fairly small :) So,
> there is probably not much of a need to better address this specific (rare)
> situation in the SWORD build system.
I see we've slightly mis-communicated. I wasn't thinking of the
SVN-using autotools-needing SWORD developer, but just someone who was
building a SWORD tarball from source. They wouldn't need autotools,
since the tarball already has a configure. But they'd run the
configure, see that it completed with no errors, and just issue "make"
and then have "make" tell them that it can't find the command g++ --
that's sorta backwards in my mind. If the configure script can't find
a required tool or library, it should die and issue an appropriate
error message. 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 on as though those were optional tools. IMO that should be
handled by making configure die with a complaint if it can't find g++
or if g++ doesn't work properly (I've seen that happen numerous times
in MSYS or on Sun OS 5.10 when g++ was configured incorrectly) rather
than continue on as though it were optional.
>>> sudo apt-get install build-essential
>> Never did like that - I enjoy doing things in Linux the longer way.
> Which is 100% fine for experts... but surely the whole point of having
> project-specific "easy-to-use" shell scripts like autogen.sh is to make
> things simpler for the non-experts? So, if we're going to have such
> convenience scripts in SWORD, shouldn't they add real convenience? :)
>> That pulls in extra packages (dpkg-dev) that I don't want to bother
> It's one package, it is tiny (600K download, 1.2MB installed) compared to
> g++ and libstdc++, and it is something that most Debian/Ubuntu developers
> are going to want to use at some point, as they look into or modify the
> contents of .deb packages and their corresponding source packages.
> But doing things the longer way is your choice, as an expert, of course.
> That's not really what I'm trying to address here. The point is that there
> exists a well-known way to install the standard set of development tools on
> Debian and Ubuntu -- and it would have helped to prevent the issue you ran
> into, had you chosen to use it, or had the convenience script you ran
> detected and offered to remedy the issue, by using that approach.
>> I would be startled, alarmed and probably not trust a package which
>> asked me for my sudo password while I was just configuring it. No
> So in your view, it is better (for most SWORD developers and wannabe SWORD
> developers -- not just for you!) to have a project-specific non-standard
> helper/convenience script just fail? That is preferable to displaying
> something like "Your system does not have the appropriate development tools
> installed, please provide your sudo password and they will be installed for
> you now using "sudo apt-get install build-essential" and then running the
I think it should fail, but the failure should be inside of
configure.sh (after all, usrinst.sh is completely unnecessary and just
a helpful way to remember the options that are passed to configure,
which is a standard script) and it should complain in a proper way.
For example, "No usable C++ compiler found on your system, please
install one and try configuring again" is a message I've seen on other
systems when g++ wasn't in the path, wasn't installed, or a broken
version was installed.
> As a "middle ground" compromise, the script could just output a message
> suggesting that the developer run "sudo apt-get install build-essential" and
> then re-run the helper script, in these circumstances, if the idea of the
> script running the install command itself is really that troubling.
Agreed - at present it does no such thing. It just silently moves on
from not finding g++ or anything similar.
> Given that most folks who run autogen.sh will already have the relevant
> basic development tools in place, and so will never be so prompted, only
> novice (or forgetful!) SWORD developers on new systems will ever see this...
> it seems to me there is value in doing something like this.
> [Aside: I was somewhat "alarmed" at the use of non-standard scripts for the
> SWORD build process when I first unpacked the source tarball and read the
> INSTALL file, and so I read them through before running them ... I think
> most experienced developers would do the same. Their doing so would address
> any concern about the appropriateness of using sudo therein. ]
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. 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.
> If the idea of autogen.sh is other than to be a convenience for SWORD
> developers, what *is* its purpose? Indeed, an expert developer with no
> prior knowledge of SWORD seeking to recreate the build system would probably
> see a configure.ac file and then instinctively run autoreconf (maybe with
> --install and/or --force options), since AFAIK that is the standard way to
> regenerate a GNU build system.
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. My
problem is actually with auto-tools in general, but that discussion is
neither here nor there. The real problem here is that autotools isn't
behaving properly - e.g. alerting the user that required programs
More information about the sword-devel