[sword-devel] Autotools Bug?
jonmmorgan at gmail.com
Tue May 12 05:01:41 MST 2009
On Tue, May 12, 2009 at 1:13 PM, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
> 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
>> 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
> 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.
The most common usage of cross-platform is referring to Windows, Mac,
and Linux (and other similar platforms, but they are considered the
important ones). For PC consumer software now the only really
important hardware platform is x86. There are certainly others (and
handhelds and mobile phones are another story), but x86 is likely to
be the standard for Windows, Linux and newer Macs for a reasonable
>> 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 :)
Your evaluation is assuming that the number of choices is the
important thing. For me, and I suspect for anyone who wants to
provide software to be useful to people, number of users must be the
important thing (I don't know many people using AIX, HPUX, or any of
the BSDs). That means Windows support is unquestionably the most
important. If you want to take an ideological position that people
should be using free software that is fine, but most people do not
take that position. If we wish to help them, we must do it on the OS
that comes with their computer by default and that they are used to,
and that is generally Windows. If you look at high-profile and
non-high profile open source projects, many will use MSVC by default
on Windows because it is known to work better (Mozilla and Python are
the examples that springs to mind, but I've seen many others).
More information about the sword-devel