Pre-build MSVC Boost binaries
Over the last year, I've set up a small SourceForge "WinBin" project [1] for distributing Microsoft Windows binaries for Boost (and some other projects). The repository is sorted by Boost version, compiler version and shared vs. static linking. Each file archive contains pre-build boost in debug/release for both 32/64-bit, following a include/lib[64]/bin[64] folder structure. There also seems to be some other sources for pre-built boost around (e.g. https://sourceforge.net/projects/boost/files/boost-binaries/ and http://boost.teeks99.com/bin/). However, these do not seem to provide boost built for both static and shared linking. Also, they do not appear to adhere to the "quasi standard" include/lib[64]/bin[64] folder naming convention used by many libraries. Finally, they seem to lack information on which version of python (and possibly other 3rd party SW) they are compiled against. Therefore, I decided to set up my own boost-binaries webpage. Please let me know if you might be interested in either improving the "WinBin" project, or somehow joining forces to merge the various sources of Boost binaries into a single, more "authoritative" repository. I would be more than happy to shut WinBin down if "similar enough" binaries can be downloaded elsewhere. Thanks in advance, Fredrik Orderud [1] https://sourceforge.net/projects/winbin/files/boost/
On Wed, Jul 31, 2013 at 5:22 PM, Fredrik Orderud <forderud@gmail.com> wrote:
Over the last year, I've set up a small SourceForge "WinBin" project [1] for distributing Microsoft Windows binaries for Boost (and some other projects). The repository is sorted by Boost version, compiler version and shared vs. static linking. Each file archive contains pre-build boost in debug/release for both 32/64-bit, following a include/lib[64]/bin[64] folder structure.
There also seems to be some other sources for pre-built boost around (e.g. https://sourceforge.net/projects/boost/files/boost-binaries/ and http://boost.teeks99.com/bin/). However, these do not seem to provide boost built for both static and shared linking. Also, they do not appear to adhere to the "quasi standard" include/lib[64]/bin[64] folder naming convention used by many libraries. Finally, they seem to lack information on which version of python (and possibly other 3rd party SW) they are compiled against. Therefore, I decided to set up my own boost-binaries webpage.
Please let me know if you might be interested in either improving the "WinBin" project, or somehow joining forces to merge the various sources of Boost binaries into a single, more "authoritative" repository. I would be more than happy to shut WinBin down if "similar enough" binaries can be downloaded elsewhere.
I believe, Tom Kent is maintaining Boost Installer for Windows [1]. Unfortunately, I couldn't find the actually built binaries for the installer or Boost. It would be great if a link to the built binaries was published on the website. [1] https://github.com/teeks99/boost-build/
On Thu, Aug 1, 2013 at 1:01 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Wed, Jul 31, 2013 at 5:22 PM, Fredrik Orderud <forderud@gmail.com> wrote:
Over the last year, I've set up a small SourceForge "WinBin" project [1] for distributing Microsoft Windows binaries for Boost (and some other projects). The repository is sorted by Boost version, compiler version and shared vs. static linking. Each file archive contains pre-build boost in debug/release for both 32/64-bit, following a include/lib[64]/bin[64] folder structure.
There also seems to be some other sources for pre-built boost around (e.g. https://sourceforge.net/projects/boost/files/boost-binaries/ and http://boost.teeks99.com/bin/). However, these do not seem to provide boost built for both static and shared linking. Also, they do not appear to adhere to the "quasi standard" include/lib[64]/bin[64] folder naming convention used by many libraries. Finally, they seem to lack information on which version of python (and possibly other 3rd party SW) they are compiled against. Therefore, I decided to set up my own boost-binaries webpage.
Please let me know if you might be interested in either improving the "WinBin" project, or somehow joining forces to merge the various sources of Boost binaries into a single, more "authoritative" repository. I would be more than happy to shut WinBin down if "similar enough" binaries can be downloaded elsewhere.
I believe, Tom Kent is maintaining Boost Installer for Windows [1]. Unfortunately, I couldn't find the actually built binaries for the installer or Boost. It would be great if a link to the built binaries was published on the website.
Oh, you've already provided the link to the built binaries (http://boost.teeks99.com/bin/). Sorry, I missed it somehow.
I'd be happy to join forces! 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. 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. 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. I do, however, already provide both the static and shared library builds in all the various versions/architectures. This is the main script that I use for all my builds. https://github.com/teeks99/boost-build/blob/master/BoostBuilding/BuildOneRel... Let me know what you think. Tom On Wed, Jul 31, 2013 at 8:22 AM, Fredrik Orderud <forderud@gmail.com> wrote:
Over the last year, I've set up a small SourceForge "WinBin" project [1] for distributing Microsoft Windows binaries for Boost (and some other projects). The repository is sorted by Boost version, compiler version and shared vs. static linking. Each file archive contains pre-build boost in debug/release for both 32/64-bit, following a include/lib[64]/bin[64] folder structure.
There also seems to be some other sources for pre-built boost around (e.g. https://sourceforge.net/projects/boost/files/boost-binaries/ and http://boost.teeks99.com/bin/). However, these do not seem to provide boost built for both static and shared linking. Also, they do not appear to adhere to the "quasi standard" include/lib[64]/bin[64] folder naming convention used by many libraries. Finally, they seem to lack information on which version of python (and possibly other 3rd party SW) they are compiled against. Therefore, I decided to set up my own boost-binaries webpage.
Please let me know if you might be interested in either improving the "WinBin" project, or somehow joining forces to merge the various sources of Boost binaries into a single, more "authoritative" repository. I would be more than happy to shut WinBin down if "similar enough" binaries can be downloaded elsewhere.
Thanks in advance, Fredrik Orderud
[1] https://sourceforge.net/projects/winbin/files/boost/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Aug 2, 2013 at 4:30 AM, Tom Kent <lists@teeks99.com> 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/BuildOneRel...
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
On Fri, Aug 2, 2013 at 3:46 PM, Fredrik Orderud <forderud@gmail.com> wrote:
On Fri, Aug 2, 2013 at 4:30 AM, Tom Kent <lists@teeks99.com> 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/BuildOneRel... *
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
On Sat, Aug 3, 2013 at 3:52 AM, Tom Kent <lists@teeks99.com> wrote:
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 very much understand your reluctance for uninstallers. My goal was not to argue in favor of that. Instead, I would personally prefer going back to plain 7z archives.
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).
Understandable and fine for me. :-)
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.
The PDB-files are generated for shared libraries, but for some reason not copied/installed to the target lib-folder. I've now sent an request to boost-build regarding that ( http://lists.boost.org/boost-build/2013/08/26894.php). Until fixed, you can copy them manually.
* 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.
Have you considered to replace "stage" with "install" in your b2 build command? By doing that, an "official" boost binary distribution will be generated within C:\boost (can probably be changed), with an "include"-folder for headers and "lib"-folder for the libraries. I do believe that this is a more standard folder layout, compared to skipping the "include" folder as in your case. Best, Fredrik
Hi, I just installed the binaries for 1.54 from boost-binaries on sourceforge, and I'm also wondering about the "lib"-folder stuff. Since I use cmake I would really prefer for the libs and dlls to be placed in a folder called "lib", since that appears to be where cmake looks for them. (Although, I guess I could try to petition the cmake people to add looking for the libs in the new places, if it is deemed better to have the installer put them in folders like "lib64-msvc-10.0") Sincerely Lars On Mon, Aug 5, 2013 at 8:26 PM, Fredrik Orderud <forderud@gmail.com> wrote:
On Sat, Aug 3, 2013 at 3:52 AM, Tom Kent <lists@teeks99.com> wrote:
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 very much understand your reluctance for uninstallers. My goal was not to argue in favor of that. Instead, I would personally prefer going back to plain 7z archives.
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).
Understandable and fine for me. :-)
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.
The PDB-files are generated for shared libraries, but for some reason not copied/installed to the target lib-folder. I've now sent an request to boost-build regarding that ( http://lists.boost.org/boost-build/2013/08/26894.php). Until fixed, you can copy them manually.
* 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.
Have you considered to replace "stage" with "install" in your b2 build command? By doing that, an "official" boost binary distribution will be generated within C:\boost (can probably be changed), with an "include"-folder for headers and "lib"-folder for the libraries. I do believe that this is a more standard folder layout, compared to skipping the "include" folder as in your case.
Best, Fredrik
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Aug 13, 2013 at 5:40 AM, Lars Hagström <lars@foldspace.nu> wrote:
Hi,
I just installed the binaries for 1.54 from boost-binaries on sourceforge, and I'm also wondering about the "lib"-folder stuff. Since I use cmake I would really prefer for the libs and dlls to be placed in a folder called "lib", since that appears to be where cmake looks for them. (Although, I guess I could try to petition the cmake people to add looking for the libs in the new places, if it is deemed better to have the installer put them in folders like "lib64-msvc-10.0")
Sincerely Lars
The problem is that we want the 32 bit and 64 bit libraries to be able to be installed side-by-side on the same machine. Since nothing in the library name indicates that, we have to (at the very least) have two directories. The -msvc-X.X part isn't essential, but makes it nice if you have just a subset of them all installed, you can quickly see which versions you have (or remove an old one). Tom
Ok, I guess that makes sense. I'll have a think about how cmake could be made to work with this. What did the boostpro installer do? Didnt it put the files under "program files" and "program files (x86)"? Not that I really like having boost under there, but at least it makes sense from a 32/64 bit point of view. And you can point to a complete installation with the BOOST_ROOT environment variable (which cmake looks at). It would mean multiple copies of all the headers though... On Tue, Aug 13, 2013 at 2:49 PM, Tom Kent <lists@teeks99.com> wrote:
On Tue, Aug 13, 2013 at 5:40 AM, Lars Hagström <lars@foldspace.nu> wrote:
Hi,
I just installed the binaries for 1.54 from boost-binaries on sourceforge, and I'm also wondering about the "lib"-folder stuff. Since I use cmake I would really prefer for the libs and dlls to be placed in a folder called "lib", since that appears to be where cmake looks for them. (Although, I guess I could try to petition the cmake people to add looking for the libs in the new places, if it is deemed better to have the installer put them in folders like "lib64-msvc-10.0")
Sincerely Lars
The problem is that we want the 32 bit and 64 bit libraries to be able to be installed side-by-side on the same machine. Since nothing in the library name indicates that, we have to (at the very least) have two directories. The -msvc-X.X part isn't essential, but makes it nice if you have just a subset of them all installed, you can quickly see which versions you have (or remove an old one).
Tom
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Thu Aug 01 2013, Tom Kent <lists-AT-teeks99.com> wrote:
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.
There are some notes on external dependencies you might want to read at https://github.com/boostpro/installer -- Dave Abrahams
participants (5)
-
Andrey Semashev -
Dave Abrahams -
Fredrik Orderud -
Lars Hagström -
Tom Kent