building, debugging and contributing to an individual boost library
Hi, Once I have forked an individual boost library, what is the best way of building the library with b2? How are dependencies on other libraries handled? Secondly, how can I build, run and debug tests using visual studio? Any help appreciated. Kind regards Sean.
On Sat, Feb 16, 2019 at 3:42 AM Sean Farrow via Boost <boost@lists.boost.org> wrote:
Secondly, how can I build, run and debug tests using visual studio?
I can't speak for all libraries, but Boost.Beast has strong support for Visual Studio, as it is the environment which I do all of my development on. The CMakeLists.txt in beast is hand-crafted to give the best possible solution and project files, where sources are grouped logically into folders. The entire include/boost/beast directory is mapped into a folder in each project so you can browse and search conveniently. For example: <https://github.com/boostorg/beast/blob/d43d9421a40c0251614bc45ea6dcf921a3dbaf37/test/beast/core/CMakeLists.txt#L10> The tests are also designed to output to the Visual Studio Output window if ::IsDebuggerAttached() returns TRUE, for additional convenience. And finally the tests enable the CRT Debug Heap tracking to provide leak reports on exit. Hope this helps!
Sean Farrow wrote:
Hi,
Once I have forked an individual boost library, what is the best way of building the library with b2? How are dependencies on other libraries handled?
Secondly, how can I build, run and debug tests using visual studio?
Which specific library do you have in mind? The easiest way to run the tests is to just clone the whole Boost, with git clone --recursive, run `b2 headers`, then cd into libs/<library>/test and run b2 -j8 (or however many cores you have). In general - unless the library contains a VS project - there's no good way to run the tests under Visual Studio (or if there is, I don't know it.) What I do is run the tests with b2, and if I need to debug one of them, I make a project that does #include <libs/<library>/test/failing_test.cpp> and run that.
Hi Peter, Thanks for the info. I'm planning to contribute to serialization. Do the instructions you provided still work for this case, or do I need to adapt them? Also, is there a way of forking boost completely, or should I just fork individual libraries? Thanks, Sean. -----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Peter Dimov via Boost Sent: 17 February 2019 01:44 To: boost@lists.boost.org Cc: Peter Dimov <lists@pdimov.com> Subject: Re: [boost] building, debugging and contributing to an individual boost library Sean Farrow wrote:
Hi,
Once I have forked an individual boost library, what is the best way of building the library with b2? How are dependencies on other libraries handled?
Secondly, how can I build, run and debug tests using visual studio?
Which specific library do you have in mind? The easiest way to run the tests is to just clone the whole Boost, with git clone --recursive, run `b2 headers`, then cd into libs/<library>/test and run b2 -j8 (or however many cores you have). In general - unless the library contains a VS project - there's no good way to run the tests under Visual Studio (or if there is, I don't know it.) What I do is run the tests with b2, and if I need to debug one of them, I make a project that does #include <libs/<library>/test/failing_test.cpp> and run that. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2/17/19 7:23 AM, Sean Farrow via Boost wrote:
Also, is there a way of forking boost completely, or should I just fork individual libraries?
I usually checkout/clone all of boost, and then fork the individual library that I want to contribute to. In general, individual boost libraries are best build from within the entire boost tree. You can use symbolic links to your fork, but I prefer to use a bit of git magic instead. The example below illustrates this for Boost.Core. Notice that you need to change insert_user_name_here and insert_branch_name_here. # From the boost tree cd libs/core # Add git aliases for upstream and my own fork git remote add upstream https://github.com/boostorg/core git remote add fork git@github.com/insert_user_name_here/core # Develop on own fork git remote set-url origin `git remote get-url fork` git pull # Sync with upstream git fetch upstream git merge upstream/develop git push # Prepare for pull-request git checkout -b feature/insert_branch_name_here git merge develop # or git rebase develop # Then develop code and push commits, and finally do pull-request # via GitHub interface # Restore boost tree after pull-request git checkout develop git remote set-url origin `git remote get-url upstream` git pull
On Sun, 17 Feb 2019, 14:10 Bjorn Reese via Boost <boost@lists.boost.org wrote:
On 2/17/19 7:23 AM, Sean Farrow via Boost wrote:
Also, is there a way of forking boost completely, or should I just fork individual libraries?
I usually checkout/clone all of boost, and then fork the individual library that I want to contribute to.
In general, individual boost libraries are best build from within the entire boost tree. You can use symbolic links to your fork, but I prefer to use a bit of git magic instead.
FYI, some libraries allow 'lightweight' development setup: clone only library you want to contribute to and test it using Boost libraries installed from (fairly recent) release package. E. G. Such workflow is allowed for GIL and, AFAIU, Beast and perhaps others too. Hopefully you'll be able to find details in respective CONTRIBUTING.md files. Mateusz Loskot, mateusz@loskot.net (Sent from mobile)
FYI, some libraries allow 'lightweight' development setup: clone only library you want to contribute to and test it using Boost libraries installed from (fairly recent) release package.
For "casual" development that's by far the best way: clone the individual library you want to contribute to, and just place it's include directory before the boost-wide include path on the command line (or in your IDE). Every so often you will get a library which depends on the develop branch of something else, but that's not too common. You can always clone boost-master, and switch individual sub-libraries to develop if you hit that particular case. There are also very few Boost libraries that require any special handling when building even if they're not header only, so I have a visual studio solution I call "libraries" with one sub-project in it for each library that has separate source files (or at least those I actually need) - I build these as static libraries with BOOST_ALL_NO_LIB defined for each project to disable auto-linking. Then I have one project solution for each library I want to work on, and import into that whatever other library-projects I need on an ad-hoc basis. Hopefully that makes sense ;) HTH, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Sun, 17 Feb 2019 at 16:31, John Maddock via Boost <boost@lists.boost.org> wrote:
FYI, some libraries allow 'lightweight' development setup: clone only library you want to contribute to and test it using Boost libraries installed from (fairly recent) release package.
For "casual" development that's by far the best way: clone the individual library you want to contribute to, and just place it's include directory before the boost-wide include path on the command line (or in your IDE).
I'm glad to have the workflow confirmed as reasonable and not a whim :)
There are also very few Boost libraries that require any special handling when building even if they're not header only, so I have a visual studio solution I call "libraries" with one sub-project in it for each library that has separate source files (or at least those I actually need) - I build these as static libraries with BOOST_ALL_NO_LIB defined for each project to disable auto-linking. Then I have one project solution for each library I want to work on, and import into that whatever other library-projects I need on an ad-hoc basis. Hopefully that makes sense ;)
I have used CMake to achieve purpose. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
participants (6)
-
Bjorn Reese -
John Maddock -
Mateusz Loskot -
Peter Dimov -
Sean Farrow -
Vinnie Falco