[sword-devel] Autotools Bug?
greg.hellings at gmail.com
Mon May 11 19:29:58 MST 2009
On Mon, May 11, 2009 at 8:57 PM, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
> Greg Hellings wrote:
>> Because there are some people who have no desire to learn anything
>> about autotools ...
> Which is fine. That is their choice. Such people by definition should
> probably not also choose to be volunteer developers on a project that uses
> autotools. The project team chose its build system. I submit that
> developers of that project have some responsibility to know at least the
> basics of their own chosen toolset. So the way to avoid learning anything
> about autotools ... is not to develop with it :)
I don't do anything more than muck around in the C++ code of mod2osis
and the filters directly. Largely I've never even desired to go
further into the code because the library is built with autotools -
something I don't know about and don't want to. ;)
> Note that end users of such projects (including libraries) do not need to
> use autotools directly, just the shell scripts and Makefiles it creates: the
> usual ./configure && make && sudo make install incantation is fine. In
> general (common hardware and OS platform, building from a released source
> tarball), that is sufficient.
To test the building process of BibleTime, which I do work with, I
often build against sword-svn. Having the autogen.sh keeps me from
having to remember what autotools options are needed, etc.
> You will find a message to this effect in every recent aclocal.m4, for
Why would I look in there? :P
>> ... inherently anti-cross-platform ...
> With several thousand Debian packages (including SWORD) using GNU Autotools
> currently built for over ten different hardware platforms, that's an
> unsupported statement of opinion which I think might be debated... but
> that's probably off topic for this list.
And 0 flavors of popular native Windows compilers (if you're lucky
enough to get Cygwin working with your necessary libraries or MSYS,
you might have a chance) and only in some cases of building on
Macintosh (command-line building only, no support for XCode). It also
has no support that I've ever seen for popular cross-platform IDEs,
like Eclipse or CodeBlocks. It might go across every architecture
that Linux or the major Unixes support, but its support for anything
outside of that range is rather pathetic.
If a library is supposed to have strong support for Linux only and
treat everyone else as second-rate citizens, then autotools works
marvelously. But if a library wants to be easily usable for building
on Windows, Mac with XCode (for our iPhone developers, especially,
this could be helpful) and Windows, then perhaps autotools is not the
most perfect solution.
I've heard Chris say at least twice in the recent weeks that he
doesn't like the condition that the MSVC projects are in for the
current SWORD release -- because we have to manually maintain them,
and they often get out of sync with the rest of the source tree when
files are added or removed or moved or new compiler flags are
required, etc. I'm guessing the Borland project requires similar
manual maintenance and if we had XCode, it would, also.
> Users of GNU Autotools based libraries may need to know ./configure && make
> && sudo make install to build and install them from source. Developers
> working with unreleased changing code may need to know autoreconf as well.
> I'm not convinced this minimal level of knowledge is a significant burden
> for a developer to have to cope with, but that's just my biased opinion :)
I agree that ./configure && make && sudo make install is not a burden.
But if new developers are asked to get their hands wet with
autotools, I feel that IS a major burden. But that's just my biased
We seem to have strayed far from my initial point - it might be good
to catch the absence of g++ and fail at the configure stage with an
appropriate message is all I really wanted to say. :) Autotools is
already in-place for building the SWORD project and I have the
feeling, no matter its shortcomings, it will be seen as very tedious
to make a change to anything else and definitely not in the middle of
attempts to get the project branched to 1.6!
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel