[bt-devel] Updated Windows Build Procedure

[Greg Hellings]

Gary,

On Tue, Oct 13, 2009 at 11:43 PM, Gary Holmlund <gary.holmlund at gmail.com> wrote:
> Greg Hellings wrote:
>> On Tue, Oct 13, 2009 at 10:09 PM, Gary Holmlund <gary.holmlund at gmail.com>
>> wrote:
>> This makes me wonder - does it obviate the need for installing two
>> different copies of the "system" libraries: one in BibleTime/bin and
>> the other in BibleTime/bin/plugins/imageformats?  I would hope that
>> installing into a global \Windows\* directory would mean we don't need
>> to include two copies of the libraries anymore.
>>
>>
>
> Yes, we don't need to have any ms dll's in our bin or plugin directories.
> They are found in WinSis automatically.

I tried to build and package just a few moments ago - I have no
Windows\WinSiS directory, though I have a Windows\WinSxS directory.
Also, the application fails to launch due to the "application was not
configured correctly" issue.  I don't know if this is because the MSVC
redistributable is not being installed properly or if it's because I'm
on a Windows XP test VM.  I see the line
INSTALL(PROGRAMS ${MSVC_REDIST} DESTINATION bin)
Generally other install macro calls use ${BT_DESTINATION} instead of
the string literal "bin."  Additionally I can't find where
${MSVC_REDIST} is being set.  Am I just missing it, or should that be
something we add to CMake's find commands?

>>>
>>> I have updated the cmake/BTCpack.cmake to do this and I have updated the
>>> building on windows wiki instructions. Please note that I added two cmake
>>> variables to the procedure.
>>>
>>> CMAKE_BUILD_TYPE       Release
>>>
>>
>> Unfortunately, for IDE generator types, the CMAKE_BUILD_TYPE is
>> ignored by CMake.  I was confused by that at first, until I read that
>> the reason is pretty straightforward - Makefile type systems expect
>> one configuration per tree, so CMake should be build in a parallel
>> directory.  IDE systems, on the other hand, take care of building in
>> their own subdirectories based on the configuration you select at
>> build time.  Thus for the INSTALL macro, at least, you use the
>> optional CONFIGURATIONS parameter to INSTALL that is documented at
>> http://www.cmake.org/cmake/help/cmake2.6docs.html#command:install.  I
>> don't exactly know what options CPack has for this, especially as
>> documentation seems more sparse for CPack and its a more recent
>> addition to the CMake suite.  Perhaps better support exists in CPack
>> now that CMake 2.8 is out.  When I look at what you've setup tomorrow
>> I'll see what I can find.
>>
>
> I guess that makes sense that the CMAKE_BUILD_TYPE is not needed. Also, I
> don't believe it make sense to build an installer for a debug version. It
> can be debugged best where it is built.

This is probably true.  I just generally package up the Debug build to
transfer over to my VM to test there.  Just because it gives more
verbose feedback when I'm testing for bugs that only manifest on that
system.  Since you're using the INSTALL command, you can have two
versions like such:

INSTALL(PROGRAMS ${MSVC_REDIST} DESTINATION ${BT_DESTINATION}
CONFIGURATIONS "Release")
INSTALL(PROGRAMS ${MSVC_REDIST_DEBUG} DESTINATION ${BT_DESTINATION}
CONFIGURATIONS "Debug")


> I see that libsword is being built without ICU. I have exchanged some email
> with Matthew Talbert about this. He suggests checking out the icu-sword svn
> at crosswire.org. I will try this tomorrow night.
>

I'm pretty sure that building the default ICU for Windows is strongly
supported in MSVC 2008 (I've heard rumor it's the preferred
platform?).  I personally have noticed no difference in SWORD with or
without it, so it was for me an "after I get BT working in its
simplest configuration" objective.  It sounds like we're close to that
time.  Chris is the sword-devel list expert on this topic.  I believe
you just need to pull ICU into a parallel directory and build it, be
sure that SWORD is configured appropriately to find it, and the SWORD
build files will automagically build it in.  We should definitely
bring him in on that issue.

--Greg