[bt-devel] Windows build system

[Greg Hellings]

On Fri, Feb 27, 2009 at 9:25 PM, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
> Greg Hellings wrote:
>
>> The IF(WIN32) .... ELSE(WIN32) .... ENDIF(WIN32) structure shouldn't
>> be necessary.  Calls to pkg-config are superfluous if the rest of the
>> CMake is written properly - which is should be.  It is more or less an
>> exact copy of the CLucene.cmake file, which works fine.  The only real
>> problem before was that in WIN32, CMake is pretty much not going to
>> find where the libraries might have been built, and the file just
>> needs to get far enough to define the SWORD_LIBS and SWORD_LIBRARY_DIR
>> as unfound so that the user can manually point the CMake gui to the
>> proper location and continue.
>
> Surely the project should not be moving in the direction of a build
> process (on any platform) that requires manual human intervention and a
> GUI?  Building should be automated so that it can be done nightly from
> the SVN tree, for example... and so it can happen on a remote headless
> build server.

Actually, the current move would take us further from the need for
human intervention.  Putting in the fixed file would mean that the
human need only enter in the manual location of the SWORD library
build rather than patch the FindSword.cmake file and THEN manually
enter the information.  Building on a remote headless server, though,
is not feasible in Windows for a first-time build without manually
configuring all of the build output directories, etc.

>
> IMO ideally on Windows you would want to have the build process be
> capable of going all the way from a source tree to a built and packaged
> resulting software product (an installer.exe or installer.msi file) as
> the result of a single command (such as "make", or at worst something
> marginally more complex, like "./configure && make && make installer").
>
> Am I misunderstanding your suggestion here?

No, I think you're just failing to realize that you're dealing with
Windows.  In Linux/Unix, the expectation is that the system maintains
shared system libraries in /usr/lib and user installed libraries in
/usr/local/lib and their header informations in /usr/include and
/usr/local/include, for the most part.  Thus, a configure system like
autotools or CMake knows that there are a few basic places to look for
an installed library, and if it's not there, then there is an
extremely minimal chance that the library exists on the system.  If it
really was installed, just to a non-standard location, that can be
specified with something like SWORD's ./configure
--with-clucene=/opt/clucene or similar on CMake.

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.  Thus, The SWORD Project
for Windows has its own copy of libsword.dll and icu32dt.dll or
whatever in its own C:\Program Files (x86)\CrossWird\The SWORD
Project\.  Header files are not distributed, and thus there is no
standard location to look to find them.  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.  For some libraries this
isn't always the case - but making an installer put files in
C:\Windows\ does not seem very smart to me, for purely end-user Bible
software.

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).

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.

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.
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.

--Greg