Storing boost as a 'vendor library' within svn and minimising it's size
Hi We wish to use boost.python in our project that runs on both Windows and Linux platforms. I think that the best way of making boost available to the developers, particularly under Windows, will be as a 'vendor library' within our project's subversion repository. That way, we can control the version of boost in use and make available pre-built binaries. My problem is that I want to minimise the size of that vendor library in order to minimise the time of checkouts and updates within Subversion. This is important as we have developers on the other side of the world, connected via low bandwidth links. First of all, I would welcome any experience or suggestion of how best to share boost, using a vendor library or whatever. Secondly, I have built just the boost.python shared libraries (v.1_43) and then executed 'boost install' to create a directory of just the header files and binaries. This will become the vendor library. Is this a sensible approach? Thirdly, the install directory is 48MB, which is large compared to the other directories in the svn project. I am considering deleting the header file directories not used by boost.python. But this is a trial and error process, as boost.python uses lots of boost header files. Any ideas on how best to do this? I will be very grateful for any advice. With best regards David
On 13/07/10 11:24, David Aldrich wrote:
Thirdly, the install directory is 48MB, which is large compared to the other directories in the svn project. I am considering deleting the header file directories not used by boost.python. But this is a trial and error process, as boost.python uses lots of boost header files. Any ideas on how best to do this?
There is a bcp utility that you can find to only copy what the library needs.
Hi
There is a bcp utility that you can find to only copy what the library needs.
Thanks for telling me about bcp. I tried: C:\boost_1_43_0>bin.v2\tools\bcp\msvc-9.0\release\link-static\threading-multi\bcp.exe boost\python.hpp \boostpython I am surprised that the result contains the serialization library. Also, there are no libs. Best regards David
Hi
There is a bcp utility that you can find to only copy what the library needs.
I executed: C:\boost_1_43_0>bin.v2\tools\bcp\msvc-9.0\release\link-static\threading-multi\bcp.exe python \boostpython But I found that no libraries were copied to the destination folder. They exist in: C:\boost_1_43_0\bin.v2\libs\python\build\msvc-9.0\release\threading-multi Can anyone suggest what I am doing wrong please? David
But I found that no libraries were copied to the destination folder.
bcp copies source only - not any binaries you may have built. Doing a "bjam stage" from the root directory of the destination folder will build what you copied over, or you can of course copy binaries from the existing distribution. HTH, John.
Hi
Doing a "bjam stage" from the root directory of the destination folder will build what you copied over, or you can of course copy binaries from the existing distribution.
Thanks, I will just copy the libraries over. I guess that since I am copying over the binaries, I can delete the libs folder of the bcp destination folder (as it contains only .cpp files and build files). Would you agree? BR David
On 14/07/10 09:40, David Aldrich wrote:
Hi
Doing a "bjam stage" from the root directory of the destination folder will build what you copied over, or you can of course copy binaries from the existing distribution.
Thanks, I will just copy the libraries over.
I guess that since I am copying over the binaries, I can delete the libs folder of the bcp destination folder (as it contains only .cpp files and build files). Would you agree?
Isn't it weird to put binaries under revision control?
Mathias Gaunard wrote:
On 14/07/10 09:40, David Aldrich wrote:
Hi
Doing a "bjam stage" from the root directory of the destination folder will build what you copied over, or you can of course copy binaries from the existing distribution.
Thanks, I will just copy the libraries over.
I guess that since I am copying over the binaries, I can delete the libs folder of the bcp destination folder (as it contains only .cpp files and build files). Would you agree?
Isn't it weird to put binaries under revision control?
No, it's not weird. There are some risks involved, in particular that the binaries might eventually stop working because your OS is upgraded too much, and at this point you'll find that source no longer compiles either. But, in general, I don't see anything particularly wrong about putting binaries under version control. - Volodya
I agree that it is awkward, and can seriously deteriorate the performance of some source control systems, but it is common and often necessary. I have even heard of some firms that put their compilers and build tools under source control as well, so that at any point in time in the future, they can go back and recreate a build, if they still have compatible hardware. Some systems like Perforce really didn't deal well (as of ~5 years ago) with a large number of large binaries in the system. -K -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Mathias Gaunard Sent: Wednesday, July 14, 2010 5:30 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Storing boost as a 'vendor library' within svn and minimising it's size On 14/07/10 09:40, David Aldrich wrote:
Hi
Doing a "bjam stage" from the root directory of the destination folder will build what you copied over, or you can of course copy binaries from the existing distribution.
Thanks, I will just copy the libraries over.
I guess that since I am copying over the binaries, I can delete the libs folder of the bcp destination folder (as it contains only .cpp files and build files). Would you agree?
Isn't it weird to put binaries under revision control? _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. _______________________________________________
On Wed, Jul 14, 2010 at 2:43 PM, <Kevin.Stevens@barclayscapital.com> wrote:
I agree that it is awkward, and can seriously deteriorate the performance of some source control systems, but it is common and often necessary. I have even heard of some firms that put their compilers and build tools under source control as well, so that at any point in time in the future, they can go back and recreate a build, if they still have compatible hardware. Some systems like Perforce really didn't deal well (as of ~5 years ago) with a large number of large binaries in the system.
Why necessary? I have worked in environments in which the Boost libraries are under svn control, and consider the practise to be a total disaster, which I would move heaven & earth to avoid in future! The Boost libraries are pretty huge, which makes a full checkout a fairly heavyweight task, which strongly discourages "experimental" activity in a temporary checkout. Putting Boost under SVN also tends to nail-down the version since updating to more recent Boost (and possibly reverting later) becomes quite high cost compared to touching a path in a makefile somewhere. A released Boost version is (I believe) a completely fixed thing, so putting in a system whose purpose is track change seems bizarre to me. Just my $0.02 worth. - Rob.
Hi As the original poster, I thought I should respond to the comments made ;-)
A released Boost version is (I believe) a completely fixed thing, so putting in a system whose purpose is track change seems bizarre to me.
Our application uses several third party libraries, including wxWidgets and SystemC. Adding Boost makes the development environment even more complex. As a newbie, I would suggest that Boost is not easy to build. Even the installation of third party pre-built binaries is not easy. Our developers have plenty to worry about without having to be concerned about configuring a complex build environment. Also, they are spread geographically so that support is not easy. Lastly, it is very important that all developers use the same library version across all platforms, so that build errors can be reproduced and fixed. All this means, for us, that storing Boost as a vendor library, including binaries, is preferable. Yes, it will affect performance (checkout times) but it will not break Subversion. Best regards David
Quoting Robert Jones <robertgbjones@gmail.com>:
A released Boost version is (I believe) a completely fixed thing, so putting in a system whose purpose is track change seems bizarre to me.
It is pretty routine for us to have patch Boost for one reason or another. Once you've done that, source controlling it rapidly becomes a serious option, including binaries. With an appropriate directory structure, checkouts are not slowed down much because you aren't "svn up"-ing the 3rd-party directory day-in/day-out.
Hi Peter
With an appropriate directory structure, checkouts are not slowed down much because you aren't "svn up"-ing the 3rd-party directory day-in/day-out.
I am interested in your directory structure. Do you have something like the following? MyProj-|-branches |-tags |-trunk |-vendor---boost Best regards David
On Wed, Jul 14, 2010 at 3:29 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Isn't it weird to put binaries under revision control?
Binaries can have revisions too, can't they? ;-) But seriously, there are a *lot* of shops out there that like to put pre-built third party libs under revision control. When I first was introduced to the practice, it took me a while to get over my "source only" mentality. Jon
participants (8)
-
David Aldrich -
John Maddock -
Jonathan Franklin -
Kevin.Stevens＠barclayscapital.com -
Mathias Gaunard -
Peter Bartlett -
Robert Jones -
Vladimir Prus