[sword-devel] Windows users as "poor cousins"?

[Jonathan Morgan]

On Sat, Oct 3, 2009 at 1:07 AM, Jonathan Marsden <jmarsden at 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