[bt-devel] Updated Windows Build Procedure

Gary Holmlund gary.holmlund at gmail.com
Wed Oct 14 18:51:28 MST 2009


Greg Hellings wrote:
> 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?
>
>   
MSVC_REDIST is on of the new variable I documented that you must setup 
in cmake according to your location of the downloaded vcredist_x86.exe.

I suspect you are right that using ${BT_DES ...   is better.
>>>> 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
>   
Matthew Talbert suggests that ICU is not needed for anything if we make 
a small change in our stringmgr. I am looking into that.

Gary



More information about the bt-devel mailing list