[Discuss] Essentially all free apps will soon be available on Windows

[Alan W. Irwin]

On 2007-02-16 08:17-0800 Adam Parkin wrote:

> The "same apps are now available for both platforms" can go both ways, as now 
> why switch to Linux when I can use Firefox (as an example) under Windows? 
> Ultimately people will switch to Linux when they want to use Linux, not when 
> the programs they want to run are available for it (although the absence of 
> such programs is certainly a knock against Linux).

Actually, I doubt most people (obviously excluding the "hands-on" type of
people lurking on this list) make choices about underlying OS.  Instead, it
is the IT staff or their organization or the company selling them their
computers that make the OS decision.  For the presumed scenario where free
apps are preloaded regardless of OS, then I assert users will tend to use
the default and the demand for, e.g., windows Office licenses will gradually
dry up.  As soon as you have a noticible fraction (say greater than 10 per
cent) of users running nothing but free apps, then it is an easy decision
for the IT staff of organizations or the company selling computers to switch
those users to the GNU/Linux OS underneath.  Such a switch is to the
organization's advantage for the usual reasons of security, reliability,
easier support, freedom from license hassles, etc. The free app users won't
notice the switch except that reliability will suddenly be improved.  :-)

In sum, we have heard for years about the resistance to switching to the
rock-solid and secure GNU/Linux OS because of the lack of high-quality free
apps availabel on that OS.  Well, free apps have matured a lot so I think it
is entirely possible to turn the argument on its head, help to make the free
apps the preloaded ones that people tend to choose by default regardless of
underlying OS, and look forward to the good things that will happen as a
result.

>
>> dependencies).  This is a big step forward compared to the previous
>> situation where autotools did not allow a windows port at all. I think 
>
> I think that's a bit of an overstatement, yes autotools are not the greatest, 
> but certainly it is possible to work with projects that use them on Windows 
> (I do some work on the Marsyas project which uses autoconf, etc, and all my 
> work is done on a Windows machine under Cygwin).

I was referring to bare windows above, and I should have made that clear. I
have actually had a lot of experience dealing with the fallout of trying to
get our previous autotools-based build system for PLplot to work on Cygwin
and MinGW.  For example, shared libraries failed to work on Cygwin for many
years for us until we realized the "file" command was a prerequisite since
the libtool script used that command internally.  Everything was so badly
obfuscated by that incredibly long script that the solution was not obvious,
and we only found it by accident.  One of our developers had the Cygwin file
package installed and another one didn't, and it took many days to track
down why they were getting such different results.  For another example, we
had no luck at all with shared libraries on MinGW until we finally found and
fixed two libtool script errors for that platform.  (One dealt with the math
library in the shared library case, and one dealt with a sed script error on
MinGW that screwed up shared library configuration in general on that
platform.) Our patch for the two fixes was accepted by the libtool team so a
lot of other MinGW shared library libtool users should benefit from our
work. Nevertheless, it was a lot of work to sort out these problems with the
libtool script and our confidence in autotools was greatly reduced by
encountering these egregious bugs for the shared library case that nobody
had fixed for years. Thus, our developers were more than ready to switch to
CMake.  That turns out to have far fewer problems on Cygwin and MinGW, and,
of course, is also allows you to port to bare windows as well.

>
> At any rate thanks for pointing out CMake, as it is something I will check 
> out..

As a first step try the "hello world" example at
http://www.cmake.org/HTML/Examples.html which builds a (very) small library
and an application that uses that library.  The CMake syntax in the
CMakeLists.txt files (one top-level one, and one each for the library
directory and application directory) are so simple that it is
self-explanatory.

Now contrast this simple and clean approach with what you would have to do
with autotools for the same example. configure.ac requires a number of
"magic" boiler-plate macros (written in m4 rather than some reasonable
language) written in a particular magic order.  A Makefile.am file (with
reasonably simple syntax but with little power compared to CMake) must be
deployed in each directory.  Then to generate the configure script and
Makefile.in files most users see, you need to run aclocal, autoheader,
libtoolize, automake, and autoconf for complicated projects and some subset
of those commands for simpler projects.  Then finally you run configure to
generate the required Makefiles (which internally run libtool for every
compile and link step which adds latency to the build).

I am sure I sound way over the top about CMake, but it really has been that
good for us (and KDE and Scribus and lots of other projects).  It covers all
the autotools platforms (including Cygwin and MinGW) more reliably than
autotools, and with CMake your build system works on bare windows as well.
Also, you feel like you have just escaped from hell when you can kiss the
autotools complexity and confusion goodby and instead you just use the
simple CMake syntax instead.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________