Use canonical boost includes style
Closed this issue · 5 comments
Now I see some boost libs are located in boost/boost_1_56_0 and boost is included like #include <boost_1_56_0/lockfree/queue.hpp> https://github.com/mattiasflodin/reckless/blob/master/reckless/include/reckless/basic_log.hpp#L31 .
But common practice is to include boost like #include <boost/lockfree/queue.hpp>.
So, I suggest to move all boost stuff to boost/boost_1_56_0/boost, add include paths to boost/boost_1_56_0 and all includes will be just like #include <boost/lockfree/queue.hpp>.
This purpose of this is to use other (system, newer) versions of boost rather than 1.56.0.
I quote from Boost FAQ (my emphasis):
Many of the Boost libraries are actively maintained and improved, so backward compatibility with prior version isn't always possible. Deal with this by freezing the version of the Boost libraries used by your project. Only upgrade at points in your project's life cycle where a bit of change will not cause problems. Individual bug fixes can always be obtained from the boost repository.
The Boost project also provides the BCP tool to extract a subset of a specific version of Boost, for this purpose.
I have intentionally gone through hoops to rename the boost folder and namespace to boost_1_56_0 so that it will not pollute the boost namespace, specifically for people who wish to use another version of boost for their stuff. This means that you are free to use any version of boost you like for your other code, without worrying about compatibility or name collisions when using reckless. Consider my use of Boost.Lockfree an implementation detail that should not affect your code in any way.
For what it's worth, in my development code I have completely removed Boost in favor of my own lockfree container. I expect to release this new version once I have cleaned it up and verified that there are no performance or quality regressions.
I see. Thanks for the explanation.
By the way I see the wip/windows branch with windows support and see there a solution file.
Maybe it's worth it to use some build system for C++ that generates project files like CMake?
Do you have any plans for this?
I'm asking this because I'm trying to investigate needs in simple C++ packet manager and how it should be organized the best way. E.g. how dependencies should be organized, included, managed etc.
I did have plans to use Tup on Windows just like I do on Unix. Unfortunately after spending a lot of time trying to get it working I ended up stuck due to problems with PDB files (gittup/tup#288). I feel like I've spent too much time on build systems now, and prefer to use something that I know will work.
While I admit to not having tried CMake, my impression is that it is too complex for a build language. Because build scripts are something you revisit rarely, they need to have a gentle and short learning curve. Otherwise you will have to make a big effort to relearn it every time you go back to change something.
If you are researching the needs for a package manager, my suggestion to you would be to try separate these three concerns to your best ability, so that the developer can learn and use them independently from one another:
- Dependency on third-party modules.
- Dependency generation for internal dependencies (e.g. cpp -> .h).
- Platform-dependent source and build configuration.
Of these, items 1 and 2 could probably benefit from being declarative, but I think item 3 would be better as an imperative language, preferably one that many users already know (e.g. Python). Have a look at Cargo for Rust, it's a good start (but seems to ignore all the intricacies that multiplatform C++ projects have to consider).
My approach with the Reckless build scripts, even back when I just supported linux, has been to provide one hassle-free Make script for the "I just want to build it" crowd, and use Tup for those that want to hack the source. The Tup scripts have all the bells and whistles with dependency management, unit tests, benchmarks etc. The Make script is good for building once without changing the source code. On Windows, the .vcxproj files fill a similar role to the Make script, except we are stuck with them for development also since I can't get Tup working properly.
Got it. Thanks a lot!