Re: [boost] Pre-build MSVC Boost binaries

Subject: Re: [boost] Pre-build MSVC Boost binaries
From: Tom Kent (lists_at_[hidden])
Date: 2013-08-02 21:52:09

On Fri, Aug 2, 2013 at 3:46 PM, Fredrik Orderud <forderud_at_[hidden]> wrote:

> 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 originally was doing .7z releases, but I had people asking for an
installer. For a long time I simply made a self-extracting 7z file to
appease these people, but when I tried to make things more official I bit
the bullet and made a full-fledged installer.

I could enable the uninstaller functionality that is built in to inno
setup, but I'm not a huge fan of uninstallers, especially for libraries. In
our organization we just install new versions alongside the old versions,
so there is never any removing of older ones. I'm open to change though.

>
> > 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'd been meaning to start a thread on this mailing list to ask that, but
haven't gotten around to it. If anyone who knows is reading this thread....?

>
>
> > 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.
>
>
As soon as I can find time I'll get things set so that we can build against
2.7 for the next version. I'm not so wild about adding it to the name,
since python is only a dependency for one of the libraries. Same with zlib
and bzip (and MPI if we ever start including that). I think the way to go
here would be to include a README_WIN_BINARY.txt at the top level that
lists all the dependency versions (and VC versions too).

>
> > 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.bathttps://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)?
>

I was trying to keep it similar to what someone would get if they ran
b2 --build-type=complete stage
my only change was to move the results up a level from the stage dir and to
rename the lib directory to something with the visual c version and
architecture that was used, so that they could all live side-by-side.
(originally I only had it separated by architecture lib32 vs. lib64, since
all the libraries have vc versions in their name).
Every group I've worked with that has had DLLs before, only move them to a
bin directory along with executables that required them to run. If we're
just supplying DLLs without any executables (as the libraries are) that it
doesn't seem like the should  be going in a bin directory.

* Do you include debug symbols? (I couldn't find any PDBs)
>

I'm on the road now and don't have a build in front of me to look at now. I
just build whatever comes from
b2 --build-type=complete stage
If PDBs are part of that then they should be included.

> * 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?
>

No, I definitely do not want to re-arrange anything that comes from the
source boost distribution. For a very long time I wasn't even including the
source in the installers (everyone needed to install that separately). I
had several people ask me to start including them, so I did, but I was very
hesitant. The most important thing should be to keep this release
completely, 100% compatible with people who just have the source
distribution and build themselves.

I'll be back from vacation to look at this some more next week.
Tom