[bt-devel] A few more matters for Windows Building

[Martin Gruner]

Hi Greg,

thanks for your mail. I applied your patch with slight modifications so that 
Sword detection on Linux continues to work. We should unify the detection for 
Linux and Windows, getting rid of pkg-config while keeping the sword version 
check, also for windows.

I don't like the idea of having fixed version numbers in the detection scripts 
for e.g. sword. Can you rename these folders, e.g. from sword-1.5.11 to sword?

Let me know if I broke stuff please.

mg

On Friday 17 April 2009 03:33:45 Greg Hellings wrote:
> So I've strongly updated, including comments, on the Building on
> Windows wiki page.  It now presupposes the attached patch is part of
> the BibleTime source tree.  I'll try to comment on each of the changes
> here, so people can modify the patch accordingly if it breaks
> configuring on other systems.
>
> The change to CMakeLists.txt just adds the BibleTime source tree to
> the include directories before the other include directories.  I don't
> know what that might change for Linux or Unix building, but it's
> necessary for Windows builds, where I was pulling in different
> config.h files than the one that I wanted from BibleTime.
>
> The changes to FindCLucene.cmake allow the user to have CLucene built
> in a parallel directory to BibleTime when using MSVC and it will still
> automatically pick up the directory for the configure so long as the
> person is using 0.9.21b, which is the latest build of CLucene.
>
> The last line that was changed to delete the WIN32_DEBUG_POSTFIX
> reflects the actual behavior of CLucene's build system.  If the user
> uses CMake to build the library, as I advise them to do so as to avoid
> compile time errors with a missing clucene-config.h, their library
> will not have any of the terminal strings (UMTD or whatever) that
> other builds of CLucene might have.
>
> The changes to FindSword.cmake are for the same purpose.  The
> additions at lines 18 and 23 are to expose the parallel-build
> directory structure under Windows.  The change at line 33 I'm not
> certain about.  There I'm deleting the sword/ at the beginning of the
> search file... on Windows this is necessary because the include files
> for sword are under ../sword-1.5.11/include but on Linux/Unix the
> files will be under something like /usr/local/include/sword/ and there
> it's probably necessary.  However, as I understand it, all the in-code
> references have been changed to actually just call, e.g., swmgr.h and
> similar.  So we probably should change the TRIAL_INCLUDE_PATHS to be
> ${SWORD_HOME}/include/sword
> ${CMAKE_INSTALL_PREFIX}/include/sword
> /sw/include/sword
> ../sword-1.5.11/include
>
> and then just search for swmgr.h.  However, I don't know if the above
> will also pick up /usr/local/include/sword and /usr/include/sword
> which are both liable to the most common on Linux.  On line 80 I
> comment out the line which appends /sword to the SWORD_INCLUDE_DIR
> path.  This is because it was appending /sword to my
> ../sword-1.5.11/include/ and causing MSVC to be unable to find the
> SWORD include files.  If we append the /sword to the search paths to
> begin with, then just search for swmgr.h, we won't need to append
> /sword/ to the end of the path.  I think my version will work, but I
> don't know that for sure.
>
> On a related note -- CLucene is included as part of Qt 4.5.0 (and
> 4.4.3 and other earlier versions, at least back to the version Eeli
> has installed).  I didn't spend too much time poking through it, but
> when I was diffing it against my clucene-core-0.9.21b I did notice
> that all the method signatures that I looked at closely had been
> modified away from using char* and TCHAR* to using QString &.  If that
> is included in standard distributions of Qt (I know it's an optional
> module to install QtCLucene from MacPorts and I've seen RPMs of it) we
> might consider at least experimenting with that for our search.  The
> version in Qt seemed relatively complete, so it might be interesting
> to see whether it handles our Unicode issues more elegantly than the
> standard CLucene.
>
> --Greg