[sword-devel] Autotools Bug?

[DM Smith]

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