Re: [boost] Pre-build MSVC Boost binaries

Subject: Re: [boost] Pre-build MSVC Boost binaries
From: Fredrik Orderud (forderud_at_[hidden])
Date: 2013-08-02 16:46:19

On Fri, Aug 2, 2013 at 4:30 AM, Tom Kent <lists_at_[hidden]> wrote:

> I'd be happy to join forces!
>

Thank you for your positive response Tom. :-)

> For the last several versions I was just posting them to my personal
> website, but with this release (and the closing of BoostPro with their
> windows binary installer) we made my builds available in the same place as
> the official source releases.
>

Could you explain why the binaries are distributed through an installer
executable, instead of a regular file archive like 7z? One downside of
installers is that users are typically reluctant to delete the installed
files/folders afterwards. Instead, they start looking for an associated
"uninstaller" in the control panel, which doesn't seem to be there in this
case.

> I think that should be the place we should direct people to for windows
> binaries, be it the ones I'm currently building or the ones that come from
> your project.
>

Agree! It would be great with more easily accessible boost binaries. The
"boost" SourceForge project seems like the natural place for these. Do you
know what it would take to get a link from
http://www.boost.org/users/download/ to
https://sourceforge.net/projects/boost/files/boost-binaries/?

> I've never actually used the python (or zlib bzlib) functionality, so I
> wasn't aware there were version dependencies that needed to be noted there,
> but I can definitely add that to my releases. The only thing I'd like to
> avoid is doing multiple builds for something like this. I'm already doing
> one for each Visual C version, I wouldn't want to have the double or triple
> for each python.
>

By opening Boost-Python DLLs in "Dependency Walker" you can verify that
they have a run-time dependency to a specific "pythonXX.dll" (e.g.
"python26.dll" for your boost_1_54_0-msvc-11.0-64.exe). I agree that
supporting multiple Python versions is probably unrealistic for now, but
could be possible for you to upgrade your script to at least compile
against a newer version moving forward (e.g. Python 2.7 or 3.x)? Also, it
would be an advantage to more clearly document the Python version used. As
an example, I append a "_pyXX" suffix to the archive filenames to make this
clear.

> I do, however, already provide both the static and shared library builds in
> all the various versions/architectures.
>

Great! I didn't notice that before now. Sorry for my ignorance.

This is the main script that I use for all my builds.
>
> https://github.com/teeks99/boost-build/blob/master/BoostBuilding/BuildOneRelease.bat
>
> Let me know what you think.
>

I haven't studied the script in detail yet, but I still have some questions
regarding the packaging:
* Have you considered to move DLLs (& any PDBs) to a separate
"bin[64]-msvc-XX.X" folder, so that run-time dependencies are separated
from linking dependencies (LIB files)?
* Do you include debug symbols? (I couldn't find any PDBs)
* Have you considered to move the boost headers into a "include" subfolder,
so that one can add boost headers to the include-directory search-path
without also adding everything else?

Best regards,
Fredrik