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: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
