On Mon, May 11, 2009 at 8:57 PM, Jonathan Marsden <[email protected]> wrote: > Greg Hellings wrote: > >> Because there are some people who have no desire to learn anything >> about autotools ... > > Which is fine. That is their choice. Such people by definition should > probably not also choose to be volunteer developers on a project that uses > autotools. The project team chose its build system. I submit that > developers of that project have some responsibility to know at least the > basics of their own chosen toolset. So the way to avoid learning anything > about autotools ... is not to develop with it :)
I don't do anything more than muck around in the C++ code of mod2osis and the filters directly. Largely I've never even desired to go further into the code because the library is built with autotools - something I don't know about and don't want to. ;) > > Note that end users of such projects (including libraries) do not need to > use autotools directly, just the shell scripts and Makefiles it creates: the > usual ./configure && make && sudo make install incantation is fine. In > general (common hardware and OS platform, building from a released source > tarball), that is sufficient. 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. > You will find a message to this effect in every recent aclocal.m4, for > instance: Why would I look in there? :P >> ... inherently anti-cross-platform ... > > With several thousand Debian packages (including SWORD) using GNU Autotools > currently built for over ten different hardware platforms, that's an > unsupported statement of opinion which I think might be debated... but > that's probably off topic for this list. 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). It also has no support that I've ever seen for popular cross-platform IDEs, like Eclipse or CodeBlocks. It might go across every architecture that Linux or the major Unixes support, but its support for anything outside of that range is rather pathetic. If a library is supposed to have strong support for Linux only and treat everyone else as second-rate citizens, then autotools works marvelously. But if a library wants to be easily usable for building on Windows, Mac with XCode (for our iPhone developers, especially, this could be helpful) and Windows, then perhaps autotools is not the most perfect solution. I've heard Chris say at least twice in the recent weeks that he doesn't like the condition that the MSVC projects are in for the current SWORD release -- because we have to manually maintain them, and they often get out of sync with the rest of the source tree when files are added or removed or moved or new compiler flags are required, etc. I'm guessing the Borland project requires similar manual maintenance and if we had XCode, it would, also. > > SUMMARY: > > Users of GNU Autotools based libraries may need to know ./configure && make > && sudo make install to build and install them from source. Developers > working with unreleased changing code may need to know autoreconf as well. > I'm not convinced this minimal level of knowledge is a significant burden > for a developer to have to cope with, but that's just my biased opinion :) I agree that ./configure && make && sudo make install is not a burden. But if new developers are asked to get their hands wet with autotools, I feel that IS a major burden. But that's just my biased opinion. We seem to have strayed far from my initial point - it might be good to catch the absence of g++ and fail at the configure stage with an appropriate message is all I really wanted to say. :) Autotools is already in-place for building the SWORD project and I have the feeling, no matter its shortcomings, it will be seen as very tedious to make a change to anything else and definitely not in the middle of attempts to get the project branched to 1.6! --Greg > > Jonathan > > > _______________________________________________ > sword-devel mailing list: [email protected] > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page > _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
