[sword-devel] Autotools Bug?

[Jonathan Marsden]

Greg Hellings wrote:

> 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.

Which is exactly what autoreconf does, and why it exists :)  And
learning to type autoreconf would be a skill that applies to other
projects, whereas I am unaware of other projects that use the autogen.sh
script name for this purpose.

>> You will find a message to this effect in every recent aclocal.m4, for
>> instance:

> Why would I look in there? :P

You wouldn't --  but when you actually *need* to regenerate the build
system the message will provide you with the info you need to do so.

Unless SWORD devs are being very careless and regularly failing to do an
autogen.sh and/or autoreconf before checking in changes to configure.ac
and Makefile.am, you won't need to use autotools directly even to get
fairly heavily involved with a project that uses it.

>>> ... inherently anti-cross-platform ...

> 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).

I read "platform" more as "hardware platform".  So the complaint is that
an open source build system lacks good support for proprietary closed
OSes and development tools?  It does know about Cygwin.  Fair enough,
but I'm not sure that those OSes and tools are a priority in the open
source world :)

> It also has no support that I've ever seen for popular cross-platform
> IDEs, like Eclipse or CodeBlocks.

Try http://www.eclipse.org/linuxtools/projectPages/autotools/

> 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.

Since 'that range' spans CPUs from things like the ARM and avr32 tiny
embedded stuff all the way up to IBM z390 mainframes, I'd argue that
there really isn't too much that is "outside that range" :)  It comes
down to what OS the user chooses to run on hardware architectures that
are *inside* that range of supported platforms -- which is a very
different thing.

> If a library is supposed to have strong support for Linux only and
> treat everyone else as second-rate citizens

AIX?  HPUX?  OpenBSD?  NetBSD?  FreeBSD?  How many more OSes do you
want?  How many do you need?  You only care about a couple of
proprietary OSes, it seems... and even then, autotools does run under
both Cygwin (under Windows) and under OSX :)

> 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.

That's a very long distance from "anti-cross-platform".

> 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.

Probably.  Proprietary development environments like this are just not
often seen as critical targets for open source tools, I would think.
Especially when it's not really clear what the benefits of MSVC and
Borland over gcc would be at the end of the day... will the resulting
app work differently?  Better?  Faster?  Or is this just a matter of
personal choice for the developer?

> 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
> opinion.

OK.  Then we can hide the autoreconf command by a one line shell script
called autogen.sh, that just runs autoreconf, if that is really less of
a burden to new developers.  It seems like roughly the same amount of
memory needed in either case, to me, and memorizing autoreconf is useful
across multiple platforms and projects, and memorizing autogen.sh is not.

> 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. :)

We can get there.  I have family stuff to do right now, but maybe later
tonight I'll get back to it.

Jonathan