[bt-devel] Windows build system

[Jonathan Marsden]

Greg Hellings wrote:

> No, I think you're just failing to realize that you're dealing with
> Windows.

If cross-platform open source projects the size of Inkscape, and GIMP
can do it, I am not really all that sure why BibleTime, which is
significantly smaller, cannot.  Sometimes they just mandate that a
particular library *must* be installed *here*, but that's not
impossible, especially if *here* is the default install location for
said library anyway, or failing that, a somewhat logical directory under
C:\.  Inkscape goes as far as doing an initial compilation of a build
tool, and then using that tool to build Inkscape... there are plenty of
ways to do it that avoid a GUI/human interaction requirement.

Absolute worst case one could allow for only cross-platform compilation,
which CMake reputedly supports, so that building happens only on Linux
but the end result is a Windows .exe installer... but other projects
seem to be able to do much better than that in practice .. well,
"better" from the point of view of people who prefer working in Windows,
that is.

> In Windows, the expectation is that every program will include its own
> copies of all of its necessary libraries, except for those in
> C:\Windows\system32 which are part of the OS.

I do not believe this is entirely correct.  All directories in your PATH
are searched for DLLs, after the current directory and the Windows
system directory (which is not always C:\Windows\system32).  See
http://msdn.microsoft.com/en-us/library/7d83bc18.aspx for a slightly
longer and considerably more official Microsoft declaration of this, or
just test it and see for yourself :)  I've supported some rather
oddly-configured Windows servers on which %sysdir% expands to
D:\WINNT\system32, BTW :)

> Header files are not distributed, and thus there is no
> standard location to look to find them.

So you invent a reasonable location for each set of such files you need,
script how to get those files into those locations, and put the
locations into environment variables set in a .bat file, or Makefile, or
CMake file, or whatever, that is run as part of the build command...
those who choose to depart from your pseudo-standard must then modify
that file or override those definitions in some way.

> Thus, CMake for Windows has a very different model than CMake for
> Linux or my Mac.  It expects to be run from the GUI and will stop and
> display a line highlighted in red at the top of its list of
> CMakeCache variables any variable it couldn't locate and ask you to
> provide it.

That's CMake for Visual Studio, I think?  I'd try CMake for MinGW
instead, for what I suspect is a more conventional (and automatable, and
so reproducible) approach.

> Since there is no standard place to install the CLucene library and
> headers, the Boost headers, the SWORD library and headers and the cURL
> library and headers, I have to manually point the SWORD .vcproj file
> to the cURL files before building.  Likewise, while running CMake on
> BibleTime I must point it to the location of my Boost headers, CLucene
> and SWORD manually.  These could just as likely be in
> C:\Users\Greg\Desktop\build (as they are for me) as it is that my Qt
> install is in E:\Qt\4.4.3-vs2008 (which it also is).

So create a standard for each (and script the install process for those
libraries to the "standard" locations, of course)!  He who creates the
build system decides what the default locations are -- hopefully they
are all on the C: drive, to accommodate those whose Windows machines
(real or VMs!) have only one partition accessible to them :)

> Also, the Windows Installer issue is another beast entirely - the
> minimal installer included with Visual Studio 2008 is hardly capable
> of everything we will need outside of the alpha period.  There is now
> way for me to tell it to display the GPL license terms.  There is no
> way for me to search for already present SWORD Project for Windows or
> Xiphos or BibleDesktop install locations and determine if SWORD_HOME
> is already present.  So odds are good that I'll have to find Yet
> Another Installer Builder and create the installation tools for
> Windows manually from that for each new release and build of
> Bibletime.

Yet Another?  I'd suggest that the way to go is to use a scriptable (and
free, open source and cross-platform-runnable) installer like NSIS and
have the build environment know how to write scripts for it and run it.
 A while ago I did something along these lines for a couple of
Java-based projects that were moving from Linux-mostly to
Windows-also... it's nice when people with only free software
development machines can still generate a working .exe that installs the
resulting application on other people's Windows machines :)  And NSIS
has been around quite a while, and some commercial products use it, both
of which suggest that it is somewhat robust and capable.
http://nsis.sourceforge.net

> I don't really think that the one-step process that is so beautiful
> and graceful on *Nix is a reality in Windows for building.

Have you looked at how other open source projects ported from the
Linux/Unix world achieve (or nearly-achieve) this?  What makes you
reject their approaches as unworkable for BT?

> Installation for the user?  Definitely!  But those of us who want to
> get our hands dirty in the building and testing are going to have to
> expect to get positively filthy in the Windows world.

"Have to do" testing under Windows, sure.  "Have to do" building, and
creating installers, under Windows -- not necessarily, not if you don't
want to do that!

You really can run makensis on Linux (from within your Makefile or
build.xml or whatever build tool framework you use) and have it generate
you a Windows installer -- I know this because I have done it :)
Therefore, as long as you are willing to build and use a gcc/g++ to
mingw32 crosscompiler (and its related binutils toolchain) under Linux,
and you can persuade CMake on Linux to use it, I am pretty sure you
could avoid "having" to do anything under Windows except run the BT
installer executable, and then test the resulting application.

See http://www.mingw.org/wiki/LinuxCrossMinGW for some info on getting
started with that approach.  If you already tried this and rejected it
before I joined the list, then I apologize for being a latecomer :)

The only large piece of that toolchain that is totally unfamiliar to me
would be CMake... so that might be a showstopper, if it proves less
cross-platform capable than its documentation says it is.  Otherwise,
though, those who wish to stay in the nice clean Linux world for their
development work can do so, while creating Windows apps and installers.

I feel we may have a new slogan -- "Linux: keeps developer's hands
clean" ? :)

Jonathan