[sword-devel] Autotools Bug?

[Jonathan Marsden]

Eeli Kaikkonen wrote:

> If some aspect of a project has a problem, it should be fixed.

Agreed.  Other than not supporting some proprietary OSes as well as some
might wish, is Autotools as a build system really a significant problem
for SWORD?  It seems to be building it OK for me (and I have built it
rather a lot of times over the past few months!).

Some of the configuration files need minor updates, but that's hardly "a
problem" of any significance, just some (overlooked?) maintenance that
needs doing.  My trivial patch earlier today does some of that; there
are a few := assignments that should perhaps be more portable =
assignments, but I'm not ready to patch those without more testing...

> It doesn't mean that those who dislike it should go away.

Indeed.  I did not say (or imply) that they should.  I said:

>> So the way to avoid learning anything about autotools ... is not to develop with it

This is IMO a non-ridiculous statement.  The way for me to avoid
learning anything about Haskell is not to develop with it, too.

There are absolutes in my statement that are *very* far from "dislike"!
 In particular "avoid learning anything about" != "dislike".  Also "not
to develop with" != "go away".

If you dislike using the bash shell and working at the command line
prompt as strongly as Greg appears to dislike autotools, then IMO you
probably should not get a job as a sysadmin of a Linux server, because
you would (most likely) be using bash (or a similar command shell)
rather often in that kind of job.

Equally, if you're going to spend your free time volunteering to work on
a software project, it makes sense to pick one that uses tools
(language, OS, libraries, etc etc) that you like, or, more importantly,
to pick one that does *not* require you to frequently use some subsystem
that you strongly and actively *dis*like using, and so refuse to learn
anything at all about.

"dislike" != "have no desire to learn anything about (plus make claims
about being inherently anti-cross-platform, etc.)"

At least in my view, one of those is a lot stronger than the other.  Why
are you apparently equating them, when I did not?

> If all developers who dislike some aspect of this project had gone
> away there wouldn't be many left.

In the light of the above, this is a non sequitur, I think.  It does not
follow from, and is not logically connected to, what I wrote.

Disliking something does not automatically imply total unwillingness to
learn anything about it.  Nor even imply not using it at all.  I believe
what I said was appropriately qualified with things like "some
responsibility" and "the basics"... and you seem to be totally ignoring
that?  I think that isn't a helpful way to read what I wrote.  Those
qualifiers were present for a reason.

Further, in this instance, Greg IMO should be able to "not develop with"
autotools without "going away" at all -- as an application developer, he
just needs SWORD releases to be frequent enough and functional enough
for him to use them, rather than needing to use unreleased SWORD svn code.

Where did your idea of "going away" come from?  This concept was not
even present in what I wrote, as far as I know.

Hypothetically, I may perhaps prefer Python to Perl, bash to tcsh, bzr
to git, and Linux to Windows.  I may even dislike using tcsh, git and
Windows.  That does not imply I never use any of them, or must "go away"
from them.  It does imply that when I have the choice, I am likely to
choose a different shell/DVCS/OS.  If my dislike of Windows were
sufficiently strong, I might choose computing tasks that did not require
its use, and even actively look for ways to avoid its use.  That has
nothing to do with "going away", either.

I think Greg's comment that, to develop BibleTime, he felt he was
*forced* or *required* to use SWORD SVN (and therefore autotools beyond
just ./configure) is important and highly relevant here.  I really hope
that this is addressed by more frequent releases of SWORD from here
onward.  No-one (who is not developing SWORD itself) should *need* to
use it in an unreleased form.  If the released product is not meeting
the needs of its intended users, then *that* is (IMO) a significant
"problem" which truly "should be fixed".  A much more significant
problem than which build system is being used!

> As far as I know quite many people hate autotools.

Yes.  Greg has expressed strong dislike, others might go as far as
"hate", though I think that is regrettable.  Some have not even read the
GNU manuals, much less the free O'Reilly book online, and spent time
learning this subsystem, so they don't understand it, so they "hate" it.
 Others are only happy if all their tools have a GUI.  Hate is an
irrational emotional response to the unknown, often based on fear.
Some, apparently, may need support for very specific proprietary OS
target platforms -- which is fine, but no excuse for hate.  Let's not
start "hating" anything...

> Nowadays there are better alternatives available and I
> think many new projects choose them.

Better for whom, by what criteria? :)  Is Python "better" than Perl?  Is
Ubuntu "better" than Debian?  Is a GUI "better" than a command line?  If
many new users choose them... does that make them "better"?

> Any new system needs learning and I couldn't create a cmake script
> for SWORD, so I can't volunteer, but I just say that "anything is
> better than autotools".

Without supporting evidence (such as that cmake script!), this is just
more emotion -- one more anecdote.  On the #ubuntu-motu IRC channel I
notice fairly frequent gripes about the use of non-standard (i.e.
non-autotools!) build systems that lead to packaging issues, or at least
make troubleshooting packaging issues difficult for packagers and MOTUs
who then have to learn "yet another" new build system.  I don't know the
details of the issues, so that's just another anecdote, no better and no
worse than yours.

As Greg noted, SWORD *does* currently use autotools.  Therefore, IMO,
making that build system work well, with a few minor tweaks and updates,
seems a reasonable thing to do.  Tonight I found out that AC_REQUIRE_CPP
does not do what I hoped it did, and I've not written the AC_CHECK_PROG
macro yet.


Instead of blaming ones tools, I'd recommend focus on what the end user
of SWORD wants to see, and trying hard to consistently deliver that.  I
*strongly* suspect that this would put (relative) lack of bugs, good
documentation, and probably also frequent releases, far ahead of
switching to a different build system.

In Greg's situation, I think that (among other things, no doubt!) this
means SWORD needs to become usable to him, as a front end developer,
*without* him having to mess with svn and the SWORD build system, at
all.  To me, that seems a reasonable objective.  IMO the same holds true
for module creators using osis2mod and related tools.  They should not
have to be grabbing code out of svn and building from source, just to
get working tools.

This could be addressed (for example) with more frequent releases,
possibly even by making weekly or nightly builds available as tarballs,
and perhaps also a more comprehensive automated test suite to help
minimize the number of bugs remaining unnoticed in each release.
Switching to a build system Greg happens to prefer would not address the
underlying issue, which (I think) is that he should not have to be
messing with SWORD's build system (or version control system), just in
order to develop a front end application that uses SWORD.  Until and
unless Greg wants to develop the SWORD library itself, he shouldn't have
to care what build system it uses.

Mannfred's recent comment about just needing a working Makefile, not
caring how it was created, seems to me to reinforce this approach.

Jonathan