- Boost - lists.boost.org

Re: [boost] CMake, modular Boost, and other stories
by Mike 27 Apr '19

27 Apr '19

> +1. Aside from the other benefits mentioned: What benefits exactly? I don't think anyone has mentioned any benefits of dropping the second form at all at all. This isn't an "either or" question - currently both versions are supported. So why exactly should one be dropped? We have talked a lot about Modularization, but little about the original question. Best Mike

1 0

CMake, modular Boost, and other stories
by Peter Dimov 26 Apr '19

26 Apr '19

It's been quiet lately, so it must be time for another CMake discussion. As you know, Boost 1.70 installs CMake configuration files on `b2 install`, and we've started to receive feedback, some of which more interesting than what doesn't work. At present, `b2 install --with-filesystem` for example installs a configuration file boost_filesystem-config.cmake, which enables CMake users to issue the command `find_package(boost_filesystem)` and then use Boost.Filesystem. This mimics what an ordinary, independent library that happened to be called "boost_filesystem" would do. It also installs an umbrella BoostConfig.cmake file, which enables the alternative use of `find_package(Boost COMPONENTS filesystem)`, which treats Filesystem as a component of the package Boost, rather than as a standalone library. This is compatible with the existing, pre-1.70 use of FindBoost.cmake to locate Boost from CMake. Brad King (from Kitware, who should know) argues that installing separate configuration files for all the libraries is wrong. He says that the preferred practice is to only support the second use, with Boost as the package, and the libraries as components, not accessible as packages on their own. (The discussion is here: https://gitlab.kitware.com/cmake/cmake/issues/19186) The reason I went with installing separate configuration files was that I expected that (a) this would be our preferred future approach when, or if, we switch to building with CMake and (b) even if not, this seemed like a step in the right, "modular", direction where libraries are treated as independent rather than parts of the monolithic package Boost. I'm having second thoughts though. It looks to me that Brad is right, and that the various library configuration files should be implementation details of a single Boost package (in the CMake sense) and not be user-visible. That is, only support find_package(Boost COMPONENTS filesystem) and drop find_package(boost_filesystem) Thoughts?

7 11

[build] b2 help moving disjoint_sets
by James E. King III 26 Apr '19

26 Apr '19

I have merged disjoint_sets into boostorg/graph locally and submitted a pull request for it (https://github.com/boostorg/graph/pull/169) The build jobs are failing however, due to disjoint_sets already existing and already having links: https://ci.appveyor.com/project/jzmaddock/graph/builds/24131163/job/uguk1li… b2 headers Performing configuration checks - default address-model : 32-bit - default architecture : x86 - symlinks supported : yes error: Cannot create link boost\pending\detail\disjoint_sets.hpp to libs\graph\include\boost\pending\detail\disjoint_sets.hpp. error: Link previously defined to another file, libs\disjoint_sets\include\boost\pending\detail\disjoint_sets.hpp. Command exited with code 1 This happened for me locally when I did the work, so I removed it from the superproject locally, and deleted disjoint_sets locally. Any thoughts on how I can tell the build to ignore disjoint_sets so it can install the headers from the new location and complete? This is a temporary situation until the superproject is updated, but the superproject cannot be updated until the code is merged into graph, and the builds are all failing so I cannot prove to the graph maintainers that the pull request is viable. The only way I can see around this is to rename the disjoint_sets headers from pending and into graph, and then fix up graph and graph_parallel, but my intention was to just merge the header into graph, not to change the location of delivered headers. That said, getting something out of pending is always a good thing. Any other ideas? Thanks, Jim

2 1

Making two Boost libraries interoperate
by Andrzej Krzemienski 26 Apr '19

26 Apr '19

Hi Everyone, Somewhat in connection with the discussion about modularizing Boost libraries, we had a certain conceptual problem recently about providing a customization code that allows Boost.Serialization library to serialize Boost.Optional. Such customization requires some code to be written (template specializations provided). Conceptually, such customization code does not belong to Boost.Serialization: we do not expect that Boost.Serialization provides specializations for every library that someone might ever want to serialize. It would also require the maintainer of Serialization to keep track of the implementation of Optional. However, it also does not belong to Boost.Optional: we do not expect that Boost.Optional provides customization points for every framework out there that the users may want to ever use. It would also require the maintainer of Optional to keep track of the implementation of Serialization. However, it is a natural expectation of a Boost user that if the library offers two components they should just smoothly inter-operate with one another. We could provide a small module Serialization-Optional-interop, but that would require many such components to exist and be maintained by someone. I would like to obtain some guidance on how to address such issue. The same problem must already be present between other Boost libraries. Maybe this has been already brought up, and we have a policy for solving this problem somewhere? Regards, &rzej;

10 23

Google Summer of Code slots
by David Bellot 24 Apr '19

24 Apr '19

Dear Boost community, Google has allocated 11 slots for our summer students this year. It's a great news. It means that 11 brilliant students will have the opportunity to work full-time with us and contribute to our libraries. The selected students will be announced soon. I'd like to thank all the mentors for their hard work in preparing the proposals and helping the students to candidate. And of course, a big thank you to Google for supporting open source every year. Best regards, David Bellot

1 0

undefined behavior in Boost.Program_Options
by Chris Rorvick 24 Apr '19

24 Apr '19

I am seeing my GCC ubsan builds littered with "downcast of address xxxxxxxx which does not point to an object of type 'holder'" errors [3] coming from Boost.Program_options (Boost 1.69). The issue has been documented in various places [1][2] but I do not see anything on the mailing list in recent months; apologies if I have missed something. A workaround is proposed on the StackOverflow post [1]. Does anyone have any thoughts on this? Many thanks! Chris [1] https://stackoverflow.com/questions/38987728/why-does-boostany-exhibit-unde… [2] https://github.com/boostorg/program_options/issues/76 [3] .../boost/boost/any.hpp:249:17: runtime error: downcast of address 0x602000053610 which does not point to an object of type 'holder' 0x602000053610: note: object is of type 'boost::any::holder<std::string>' 6f 00 80 67 d0 91 ec 88 fe 7f 00 00 68 33 09 00 40 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^~~~~~~~~~~~~~~~~~~~~~~ vptr for 'boost::any::holder<std::string>' #0 0x7ffe8df13e3d in boost::program_options::typed_value<std::vector<std::string, std::allocator<std::string> >, char>::xparse(boost::any&, std::vector<std::string, std::allocator<std::string> > const&) const (redacted+0x28be3d) #1 0x7ffe88bb0cd5 in boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::vector<std::string, std::allocator<std::string> > const&, bool) const (.../libboost_program_options.so.1.69.0+0xdacd5) #2 0x7ffe88ba9193 in boost::program_options::store(boost::program_options::basic_parsed_options<char> const&, boost::program_options::variables_map&, bool) (.../libboost_program_options.so.1.69.0+0xd3193) #3 0x7fff0b727dbf in rdx::launch::OptionsWrapper<boost::program_options::options_description, boost::program_options::variables_map>::prepare(int, char**, std::vector<int (*)(boost::program_options::options_description&), std::allocator<int (*)(boost::program_options::options_description&)> > const&) (redacted+0x448dbf) #4 0x7fff0b755e80 in int generic_wrapper<std::vector<int (*)(boost::program_options::options_description&), std::allocator<int (*)(boost::program_options::options_description&)> >, rdx::Function<int (boost::program_options::variables_map const&), 56u>, rdx::launch::OptionsWrapper<boost::program_options::options_description, boost::program_options::variables_map> >(int, char**, std::vector<int (*)(boost::program_options::options_description&), std::allocator<int (*)(boost::program_options::options_description&)> > const&, rdx::Function<int (boost::program_options::variables_map const&), 56u> const&, rdx::launch::OptionsWrapper<boost::program_options::options_description, boost::program_options::variables_map>&) (redacted+0x476e80) #5 0x7fff0b76593c in redacted(std::string const&, int, char**, std::vector<int (*)(boost::program_options::options_description&), std::allocator<int (*)(boost::program_options::options_description&)> > const&, rdx::Function<int (boost::program_options::variables_map const&), 56u> const&) (redacted+0x48693c) #6 0x95c21d in main (redacted+0x95c21d) #7 0x7ffe82fb83d4 in __libc_start_main (/lib64/libc.so.6+0x223d4) #8 0x963523 (redacted+0x963523)

3 2

Re: [boost] CMake, modular Boost, and other stories
by Mike 24 Apr '19

24 Apr '19

> Hmmm - so no boost library should include any > other boost library? DoesÂ that seem a good idea? Please don't put words in my mouth. I didn't say that and you know it. But the dependency graph could easily be significantly simplified once c++03 is no longer a concern. Again: I'm talking about the future, not the current state. Just an example: [1]Boost.TypeErasure depends on [2]Boost.Thread(and all that entails), just because somewhere in its bowels it needs a mutex. > It's always been good practice to notÂ repeat/copy > functionality in one library into another. Not always. A recent example I stumbled over: Boost.Signal2 depended on boost multi index (which itself depends on a lot of other libs) because it reused it's scope guard implementation (IIRC about 50 lines of straight forward code). Tying yourself to another library for something trivial like that should not be a no-brainer. > But what is really needed - and it may already exist > in BCP but hasn'tÂ been promoted is a simple tool: > a) start with one's application > b) run the app through a tool which recurrsively > reads headers > c) and creates a list of all headers needed > d) extract library names from that list > e) add the git repo of those libraries to my apps > project. So boost should not only get its unique build system, but also its unique dependency management tool? I can tell you as a user: Thanks but no thanks. Also: Didn't you forget source files somewhere in there? What about tests? Bottom line: If boost as a whole was developed as a single project with some coordinated devlopment goal and strategy , it would make sense to distribute it as a single package/framework and a single cmake config file. It seems to me however, that it is more a (huge) collection of independently developed libraries, so I think it is more appropriate to treat them as such, even if there is a huge amount of coupling between them. Am 23.04.19, 23:56, Robert Ramey via Boost <boost(a)lists.boost.org> schrieb: On 4/23/19 2:28 PM, Mike via Boost wrote: > I for one very much hope that boost (at least the libraries that > are actively maintained) will become less coupled > in the future, such that when I just want to use > library X, the rest of boost doesnʼt come as a > dependency with it. Hmmm - so no boost library should include any other boost library? Does that seem a good idea? Itʼs always been good practice to not repeat/copy functionality in one library into another. Iʼve said it many times before so I wonʼt make a big deal about it here. But what is really needed - and it may already exist in BCP but hasnʼt been promoted is a simple tool: a) start with oneʼs application b) run the app through a tool which recurrsively reads headers c) and creates a list of all headers needed d) extract library names from that list e) add the git repo of those libraries to my apps project. I donʼt seen any way to get around this. And util we can easily do this - boost will not be modular. Robert Ramey _______________________________________________ Unsubscribe & other changes: [3]http://lists.boost.org/mailman/listinfo.cgi/boost References 1. http://Boost.TypeErasure/ 2. http://Boost.Thread/ 3. http://lists.boost.org/mailman/listinfo.cgi/boost

6 5

[doc][geometry][gil][signals] Broken links for Boost 1.70
by Mateusz Loskot 24 Apr '19

24 Apr '19

Hi, On https://www.boost.org/doc/libs/1_70_0/ links to these documentations are broken: https://www.boost.org/doc/libs/1_70_0/libs/geometry/index/doc/html/index.ht… https://www.boost.org/doc/libs/1_70_0/libs/geometry/extensions/doc/html/ind… https://www.boost.org/doc/libs/1_70_0/libs/gil/doc/html/index.html https://www.boost.org/doc/libs/1_70_0/libs/signals/ Could anyone help to identify what is going wrong with those and how to fix it? p.s. I considered posting to boost-docs but that list seems inactive. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

5 5

CMake, modular Boost, and other stories
by Mike 23 Apr '19

23 Apr '19

I'm very much in favor of separate packages. James is right, that - at the moment - most boost libraries are so tightly coupled that they can't really be treated as separate libraries, but when changing things it is just as important to ask, "Where do you want to go?" as "where you are now". I for one very much hope that boost (at least the libraries that are actively maintained) will become less coupled in the future, such that when I just want to use library X, the rest of boost doesn't come as a dependency with it. It also fits the management structure (or rather the lack thereof) much better. Also, the mechanisms for modular boost distributons already exist through e.g. vcpkg and conan, so I don't see the problem in also providing independent cmake configfiles. Finally: About how many libraries are we talking here anyway? Only the compiled ones get their separate config file - correct? Best Mike

3 2

[GSOC2019][Boost.uBLAS]
by swornim baral 23 Apr '19

23 Apr '19

Hi List, I realize the deadline has passed for seeking a mentor for GSOC, and I apologize for the delay in initiation. I came to know about the program two weeks prior to the deadline, and started working on completing my proposal and competency test prior to finding any mentors. However, I am still very much interested in working on the project of adding a new numerical and multi-linear algebra algorithm to Boost.uBLAS library. I would love to work on the algorithm for calculating Kronecker and Hadamard product with the guidance of a potential mentor. Since I submitted the proposal in a hurry and without any discussion with a mentor, I could not include specific implementation details in my proposal. Below is the link to my final proposal that I submitted for the GSOC 2019. I would really appreciate any feedback on the proposal, competency test and suggested reading materials to get a head start on implementing the algorithm from any interested mentors. https://drive.google.com/open?id=1saUedBfMCOpmVqQfn1a3YcfPtjPYLeDC . Sincerely, Swornim baral

1 0