On Sat, Oct 3, 2009 at 1:07 AM, Jonathan Marsden <jmars...@fastmail.fm> wrote: > OK, I'll bite. Let's run with this discussion a bit... > > Greg Hellings wrote: > >> Most Linux or FreeBSD users are familiar with a source tree compile >> with autotools. > > Really? In 2009? Do you have a source or at least some anecdotes to > back up that idea? > > If you are correct, why was it valuable to get this software packaged? > If that is really the standard conventional way today's Linux users > expect to receive and install software, then packaging it for them in > distro-specific ways is clearly a waste of my time! > > About 15 years ago, I would have agreed that most Linux users knew how > to use autotools and gcc and friends. Maybe 10 years ago that was still > true, although it was definitely a declining fraction of the userbase, > even then. I'm not at all sure the same is true today. How much time > have you spent on the Freenode IRC support channels such as #ubuntu or > ##linux or even #debian recently? I assure you, the vast majority of > questions being asked are not coming from users comfortable with the > command line and with compiling their application software from source code! > >> When a Linux or BSD user searches for software on the Internet, finds >> a home page, and sees a "Download" link they're very likely to be >> looking for an option that ends in a .tar.gz or .tar.bz2 so they can >> pull the source, compile, install and be on their way. This is >> native and natural ... > > I submit that it is no longer natural at all. In today's Linux world, > for end users, application software is packaged and signed and tested > before being allowed into a repository, and there are very few of these > for a given Linux distribution. The natural way to search for software > is therefore with your package manager, which is often a GUI tool > (Synaptic for example). > > Newcomers quickly find that you *don't* go around searching the Internet > for Linux software in random places, because (unlike Windows) installing > it when you find it there is often "too hard". Instead, Linux users > will often only use what is already packaged for their specific Linux > variant, and which is easily available for installation in a pretty GUI > tool. Some will even wipe their hard drive and reinstall from scratch > to use a different Linux distribution *just* to get some particular > piece of software that one distro packages and another does not! > > In Ubuntu, the default way to search for and then install software is to > click on a menu item labelled "Add/Remove...". It brings up a > (deliberately simplified!) graphical package manager. I suggest that > this is a clear sign that today's Linux distros do not expect their > users to be experienced in downloading and compiling tarballs at a > command line in order to install software :) > > I really do not think one should expect any autotools and compiler > knowledge at all in the average Linux user. Not any more. Those days > are over. > >> It is native and natural for a Windows user to look for a package >> that ends in .msi or .exe and download and install that. This is how >> software is expected in Windows. > > Indeed. They lack a common package manager, so they have to search the > entire Internet for individual (binary) packages. > > The direct equivalent in Linux is a binary .deb or a .rpm for ones own > distribution (most commonly found in the repos for ones own distribution > rather than elsewhere, to avoid dependency issues or trojans). This is > how software is expected in Linux, in 2009. > > Indeed, so prevalent is this approach that even providing .debs for > download in PPAs is considered by some to be for the "expert" few only, > and we find we need to provide a way to enable our team PPA that > completely avoids the command line, so that the PPA contents will be > useful to many users! > > And, as I said earlier, Crosswire currently directly provides the former > (compiled binaries for Windows) but not the latter (compiled binaries > for Linux). So which is the "poor cousin"? :) > >> On another hand, one could also point out that autotools is native to >> the SWORD library, is regularly updated when file names, directory >> structures and the like change. Thus, at any given point, a user >> could just pull the SVN tree and have a very high probability of >> things "just working." > > Autotools is not Linux-specific. > >> The Windows build files are maintained manually -- nearly every time >> I try to build from SVN on Windows (which is every 4-5 months, so not >> very regularly) thus far, I have had to edit the file list, or find >> compiler directives and defines, etc that need to be tweaked because >> of the manual system which does take a "poor cousin" seat all too >> often. > > Really? For SWORD itself? Not strange proprietary "project files", not > tweaks needed to suit one version of one specific commercial compiler, > or a specific IDE -- just the usual standard autotools/Makefile/GCC > approach, that is the same on all the other operating systems supported? > It is 4-5 months since SWORD 1.6.0 was released, so can you provide an > example of what in the SWORD 1.6.0 tarball had to be changed to permit > Windows compilation of SWORD with autotools/GCC?
In my opinon, the expected compiler to be used for Windows binaries is VC++, whether it is proprietary or not (for example, ask Mozilla, or OpenOffice, or Python). I believe it is generally considered to produce better and more efficient code than MinGW (whether correctly or not, I cannot judge). BPBible uses VC++ to build Sword binaries to make it work with the standard Python distribution on Windows. Whether or not MinGW/autotools works is irrelevant, since it is not the expected development environment. Jon _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
