Boost logo

Boost :

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

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

> 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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at