[bt-devel] Updated Windows Build Procedure

[Greg Hellings]

Gary,

I'm glad someone else has picked up the ball on this.  I'll take a
look at your alterations this week, hopefully tomorrow.  On my system,
I think that I'm running VS2008. I don't see an SP1 anywhere in the
About dialog for Visual Studio (there is one for the .NET 3.5 SP1
runtime that I have installed).  Specifically I have version
9.0.21022.8 RTM.  I presume that's why I wasn't seeing the specific
crash you mention, as both my executable and libraries were all build
with 2008 and were including its system libraries.

On Tue, Oct 13, 2009 at 10:09 PM, Gary Holmlund <gary.holmlund at gmail.com> wrote:
> Greg,
>
> There is an issue where the Visual Studio 2008 SP1 compiler compiles
> libraries and exes and embeds a version number requiring the VS 2008 (not
> VS2008 SP1) run time libraries. Our cmake/NSIS installer was copying the
> VS2008SP1 libraries into the BibleTime\bin directory. This version number
> difference was causing crashes when we try to run on a non-development
> computer. There are more details about this issue at this link.
> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361682
>
> After looking at the workarounds in the above link, I was manually editing
> the version number in BT to the VS2008SP1 value. This also had to be done
> the Qt dlls. This manual procedure was rather ugly.
>
> On further study I found that Microsoft recommends a different procedure
> that is much cleaner. Instead of installing the VS run time libraries in
> BibleTime\bin, we install a program from Microsoft called vcredist_x86.exe.
> This installs the VS run time libraries in c:\Windows\WinSiS\...  These are
> then in a central location and shared among all programs requiring them. To
> do this I put steps into the BT installer to install the vcredist_x86.exe
> and then delete the exe as it is no longer needed. There are several
> versions of programs by this name, but we need the VS2008 version because
> that is what the VS2008 or VS2008SP1 compiler embeds into libs and exes.

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.

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

Again, thanks for all the help on this -- I was getting very nearly
discouraged about ever getting those icons to work in Windows without
having to convert them all to PNG!

--Greg

> MSVC_REDIST                   c:/Bt/msvcrt/vcredist_x86.exe
>
> http://devel.bibletime.info/wiki/Building_on_Windows
>
> Gary Holmlund
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
>