[sword-devel] Autotools Bug?

[Daniel Owens]

I know someone's going to jump on me about this being in the 
documentation already, but the process below is not always so easy for 
folks like me, and the process DM outlines is not all in one place in 
the documentation. This should be in sword/INSTALL under QUICKSTART and 
on the website somewhere. I don't know how many times I've had to figure 
this out again... Call me a newbie and not a developer, but this 
information (because compiling from SVN is often so important at the 
user and module developer level) is important for more than just people 
used to compiling software from source...

Daniel

DM Smith wrote:
> I don't see what all the fuss is about. I know nothing about autotools 
> or configure other than SWORD uses it and that it is common.
>
> What I do know, it is simple to build the SWORD library.
>
> 1) Check out the files:
> svn co http://www.crosswire.org/svn/sword/trunk sword
>
> 2) Enter the build directory
> cd sword
>
> 3) Run autogen.sh:
> ./autogen.sh
>
> 4) Run usrinst.sh
> ./usrinst.sh
>
> 5) Examine the output to see if anything is missing and install that.
> This is the hardest part.
>
> 6) Run make.
> make
>
> 7) Once that is done, occasionally get updates from svn:
> svn update
>
> 8) If there are any added files then do a clean make and then go to 
> step 3 and start over (except 5 can now be skipped).
> make clean && ./autogen.sh && ./usrinst.sh && make
>
>
> On May 12, 2009, at 6:54 AM, Jonathan Marsden wrote:
>
>> 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
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>