[sword-devel] Autotools Bug?

[Greg Hellings]

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
>> installing.
>
> 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
>> thanks!
>
> 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
> command?

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
aren't found.

--Greg