On Mon, May 11, 2009 at 4:00 PM, Jonathan Marsden <[email protected]> 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 _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
