- Boost - lists.boost.org

[cmake] Minimum viable cmakeification for Boost
by Niall Douglas 22 Jun '17

22 Jun '17

I've finished the mockup which can be studied at: https://github.com/ned14/boost-bmv-cmake Just Boost.System was cmakeified. Extensive comments are throughout to explain every single line of cmake and why it's there. A small sample program is in the root of the repo to show how this cmake would be used by end user programs. Readme.md follows for those who don't like clicking on links: --- cut --- This is a mock up of a **bare minimum viable** cmakeification of the Boost C++ libraries for the community to study and evaluate. It only cmakeifies Boost.System alone, its upstream dependencies are stubbed/faked. A demo program which shows how one would link against Boost.System is in this directory (`example_client_program`) and it demos linking against boost::system as a header only library, as a static library and as a shared library. # Specific design goals of this mock up: - Modern, **highly reusable by unknown third party cmake** cmake3 only throughout. - Minimum possible cmake complexity, no cmake innovating, even at the cost of extra boilerplate. - No custom macros, functions, nor custom build logic. Only vanilla cmake3. Keep the learning curve for the build system as gentle as is possible. - **Strict** separation of non-fixed configuration and build. Child CMakeLists must only EVER define build and *fixed* configuration like "I need C++ 11 minimum". *Variable* configuration like naming, directory layout for outputs, optimisation flags etc is ALWAYS defined in the **rootmost** CMakeLists. NEVER in child CMakeLists. - All custom build logic should always be placed in rootlevel cmake scripts (command line programs written in cmake, runnable using `cmake -V`, these can take args etc) or rootlevel CMakeLists, or combinations thereof. # Stuff in there we might yet remove: - This cmake mockup explicitly documents dependencies between Boost libraries in cmake, and so when I link against say Boost.System, cmake will also link in the things Boost.System depends against. Moreover this is minimal, so ONLY the stuff minimally necessary to fulfil the need for Boost.System is built. - We allow those Boost libraries support it to present header only, static and dynamic linkage editions of themselves. This does complicate the CMakeLists however. # What we don't do: - Test the boundaries of cmake or push any limits of what's possible. - Bespoke libraries of common functions dragged in wherever. - Complex custom build logic which needs to be documented and learned off by library developers. - Do anything which gets in the way of CMakeLists reuse by any arbitrary third party cmake written by any Boost user. --- cut --- The code should be fairly self explanatory. Yes there are no tests support. We are limiting the scope of discussion to build only for now. Technical questions are welcome. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

8 50

[review] Beast review coming up!
by Michael Caisse 22 Jun '17

22 Jun '17

The Boost formal review of Vinnie Falco’s Beast library will take place July 1 - 10, 2017. Beast is a C++ header-only library serving as a foundation for writing interoperable networking libraries by providing low-level HTTP/1, WebSocket, and networking protocol vocabulary types and algorithms using the consistent asynchronous model of Boost.Asio. This library will be familiar to programmers that have used Boost.Asio or the Networking TS. Users who wish to use asynchronous interfaces should already know how to create concurrent network programs using callbacks or coroutines. Beast is designed for: * Symmetry: Algorithms are role-agnostic; build clients, servers, or both. * Ease of Use: Boost.Asio users will immediately understand Beast. * Flexibility: Users make the important decisions such as buffer or thread management. * Performance: Build applications handling thousands of connections or more. * Basis for Further Abstraction. Components are well-suited for building upon. Beast can be found here: * Documentation : <http://vinniefalco.github.io/beast/> * Source code : <https://github.com/vinniefalco/Beast> * The FAQ answers real questions that come up : <http://vinniefalco.github.io/beast/beast/design_choices/faq.html> A lightning talk from CppCon 2016 introducing Beast can be found here: <https://www.youtube.com/watch?v=uJZgRcvPFwI> If you find an obvious bug or problem with the library, please open a GitHub Issue <https://github.com/vinniefalco/Beast/issues>. Vinnie has a track record of resolving issues quickly. Please feel free to take an early look at the library and ask questions. Maybe even click that github Star button! The actual review will be against a non-mutating branch starting July 1st. -- Michael Caisse Ciere Consulting ciere.com

2 1

[build] Use full compiler-version in library filenames
by Deniz Bahadir 22 Jun '17

22 Jun '17

Hi list, While reading Vinnie's mail (regarding the Boost library filenames which should additionally contain the address-model) I remembered another problem existing with library filenames. That is, that Boost libraries built with newer GCC versions (since GCC 5) never add the compiler-version into the library filenames. Building with GCC 5 and newer only adds "gcc" into the filename to determine the toolset, while building with earlier versions of GCC (e.g. GCC 4.9 or GCC 4.8) additionally adds the compiler's version (e.g. "gcc49" or "gcc48"). I assume this might be due to the fact that the version-scheme of GCC changed since GCC 5 and somehow the logic in Boost.Build no longer works because of this. But in order to install boost-libraries built by different GCC versions side-by-side in the same directory the version-number is really required in the filename. Maybe someone can fix this again? A bug-report on Github which addresses this issue already exists: https://github.com/boostorg/build/issues/191 Thanks in advance, Deniz -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Winterfeldtstr. 21 10781 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Advisory Board (Chairman): Stephan Schröder Board of Management: Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

2 1

[review] Review of Nowide has finished
by Frédéric Bron 22 Jun '17

22 Jun '17

Thanks for you interest and the discussion. Please be patient, it will take a few days for me to compile all the discussions and give the result of the review. Kind regards, Frédéric

1 0

1.65 closes for new libraries and breaking changes this Friday
by Marshall Clow 22 Jun '17

22 Jun '17

[ The calendar says today, but I forgot to send this out, so we're pushing the deadline back two days. ] Upcoming release dates: 28-Jun: Boost 1.65.0 closed for major changes 5-Jul: Boost 1.65.0 closed for all changes, except by permission of a release manager. 8-Jul: Boost 1.65.0 closed for all changes 12-Jul: Boost 1.65.0 beta; master branch re-opened 2-Aug: Release closed for all changes, except by permission of a release manager. 5-Aug: Boost 1.65.0 closed for all changes 9-Aug: Boost 1.65.0 release -- Marshall

1 0

Re: [boost] [review] Review of Nowide (Unicode)
by Yakov Galka 21 Jun '17

21 Jun '17

Dear all, Here is my review of the library. - What is your evaluation of the design? > I welcome the UTF-8 approach on Window. However, the fact that Nowide does not handle invalid UTF-16 transparently is an issue that has to be addressed. - What is your evaluation of the implementation? > Going through the code I can't spot any implementation issues. > - What is your evaluation of the documentation? > It's clear. No issues found. > - What is your evaluation of the potential usefulness of the library? > I already use this approach through a different implementation. Even though I wouldn't bring Boost just for that single library, for projects that already use Boost it might be a valuable addition. I do think that Nowide offers a superior solution to encoding issues compared to Boost.Filesystem. > - Did you try to use the library? With what compiler? Did you have any > problems? > I did try it years ago when it was first submitted to Boost. I didn't try the recent version, so NO. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > 30 minutes reading the code + mailing list discussions. > - Are you knowledgeable about the problem domain? > I rate myself as an expert. I'm a co-author of utf8everywhere.org. DISCLAIMER: I met Artyom a couple times IRL. > - Do you think the library should be accepted as a Boost library? Be > sure to say this explicitly so that your other comments don't obscure > your overall opinion. > Conditional acceptance, subject to transparent invalid UTF-16 resolution. -- Yakov Galka http://stannum.co.il/

4 3

[review] Last day to send your review of Nowide (Unicode)
by Frédéric Bron 21 Jun '17

21 Jun '17

Dear all, This is the last day to submit your review of Artyom Beilis' Nowide library. So far, 12 people participated to the review (not counting the author and the review manager): - Andrzej Krzemienski - Chris Glover - Degski - Edward Diener - Gavin Lambert - Niall Douglas - Norbert Wenzel - Paul Groke - Peter Dimov - Vadim Zeitlin - Yakov Galka - Zach Laine 8 reviews where received including * 6 reviews said nowide should be accepted (with conditions): - Degski, - Peter Dimov - Andrzej Krzemienski - Chris Glover - Norbert Wenzel - Yakov Galka * 1 review did not choose between accept/do not accept: - Paul Groke * 1 review said nowide should not be accepted as is: - Zach Laine Your participation is encouraged, as the proposed library is uncoupled, focused and rather small. Nowadays, everyone needs to handle Unicode but this is very difficult using only the standard library in a platform independant way. Nowide offers a very simple way to handle Unicode the same way on Windows/MacOS/Linux. Key features: * work with UTF-8 in your code, Nowide converts to OS encoding * Easy to use functions for converting UTF-8 to/from UTF-16 * A class to fixing argc, argc and env main parameters to use UTF-8 * UTF-8 aware functions: - stdio.h functions (fopen, freopen, remove, rename) - stdlib.h functions (system, getenv, setenv, unsetenv, putenv) - fstream (filebuf, fstream/ofstream/ifstream) - iostream (cout, cerr, clog, cin) Documentation: http://cppcms.com/files/nowide/html GitHub: https://github.com/artyom-beilis/nowide git clone https://github.com/artyom-beilis/nowide.git Latest tarballs: - to be unzipped in boost source: https://github.com/artyom-beilis/nowide/archive/master.zip - as a standalone library: http://cppcms.com/files/nowide/nowide_standalone.zip Nowide has standard boost layout. So, just put it into the boost source tree under libs/nowide directory for building and running tests. Or alternatively - for header only part of the library add the nowide/include path to the include path of your projects. Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. Frédéric

1 0

[sort] Timsort review result
by Steven Ross 21 Jun '17

21 Jun '17

After reviewing the responses, I have rejected Timsort. Here are the reasons: 1. No author/maintainer responses to the questions on boost (except for forwarding some documentation links). We need a maintainer for all our source, and I'm not volunteering to maintain new functions as complex as Timsort. 2. There was no response on the Timsort bug reported during the review, nor any tests for it. 3. We need better tests. 4. Francisco is including a more efficient stable sort as part of his additions to the library, including handling special cases like Timsort handles better than stable_sort does. Francisco will maintain his code. I'd like to note that many people THINK they are experts on sorting because they covered it in class or may have read about it in a textbook, but most do not understand hybrid sorts well. As a specific example, I saw O(N*log(N)) mentioned as the worst-case speed limit of general-case sorts, when in fact Spreadsort beats that as described in its docs: http://www.boost.org/doc/libs/1_61_0/libs/sort/doc/html/index.html#sort.ove… Many people also don't carefully analyze for worst-case performance, which can be tricky. With regards to future sorting library reviews, I'll get at least a one-page doc describing the algorithm for the review in advance, but the boost documentation formatting is an unreasonable request for a simple sorting function, and I don't see the value it adds for these simple reviews. It is useful for a full library, but we'll be integrating the documentation into our full library after a new function is accepted. It isn't accurate to call it a mini-review (as described here: http://www.boost.org/community/reviews.html#Fast-Track) because it's reviewing completely new source we're talking about adding to the library. That said, do you still want me to a call the upcoming one for pdqsort a "mini-review"?

3 3

Re: [boost] [cmake] Minimum viable cmakeification for Boost
by Thomas Heller 20 Jun '17

20 Jun '17

Am 20.06.2017 2:17 nachm. schrieb "Niall Douglas via Boost" < boost(a)lists.boost.org>: On 20/06/2017 07:27, P F wrote: > >> On Jun 19, 2017, at 6:42 PM, Niall Douglas via Boost >> <boost(a)lists.boost.org> wrote: >> >> I've finished the mockup which can be studied at: >> >> https://github.com/ned14/boost-bmv-cmake >> >> Just Boost.System was cmakeified. Extensive comments are throughout >> to explain every single line of cmake and why it's there. A small >> sample program is in the root of the repo to show how this cmake >> would be used by end user programs. > > Here some feedback, I have: > > - Having things like `::hl` or `::sl` is quite strange. In cmake, I > set `BUILD_SHARED_LIBS=On` when I want a shared library or I set it > to `BUILD_SHARED_LIBS=Off` when I want a static library. There should > only be one target `boost::config` or `boost::system` that I use. BUILD_SHARED_LIBS is a cmake2-ism and should not be present in modern cmake. Moreover, cmake now supports header only libraries, and BUILD_SHARED_LIBS causes problems with eventual C++ Modules support. The ::hl suffix means "link against the header only library edition", the ::sl suffix means "link against the static library edition" and the ::dl suffix means "link against the dynamic library edition". Err, I tend to highly disagree here. As a library author, I can not know if my users need a static or shared library. For a header only library, this hardly matters. Having those different conventions greatly increases the complexity for consuming your library (which do I need again in which circumstances?) so we need to depend on variables to link against the right target (so much for cmake2isms). Some bikeshedding over those names occurred off list. They don't hugely matter, they could be boost::system::header, boost::system::static and boost::system::shared if you wanted. Some bikeshedding also occurred over what boost::system with no suffix should mean. I recommend "whatever library edition the maintainer recommends as the best one" which is NOT necessarily the header only edition. For example, in the future with C++ Modules support the additional suffixs ::hlm, ::slm and ::dlm will be needed. Or longer named, boost::system::header_module, boost::system::static_module and boost::system::shared_module. So if C++ Modules were available, the maintainer might recommend the ::dlm variety, but recommend the ::hl variety if they weren't available. I think that will hugely vary per library as C++ Modules won't necessarily be always a win. Also, end users may wish to assemble all of Boost into a single C++ Module. We don't want to get in the way. > - Each project do things like > `include("${CMAKE_CURRENT_SOURCE_DIR}/../../cmake/BoostVersion.cmake”)` > which is broken when built on its own. That was intentional. Some bikeshedding occurred over that too with respect to which Boost library guaranteed to be a dependency for all other libraries ought to host the version setting script. Boost.Config is most likely. So the above is a placeholder. > - Doing `if(NOT TARGET boost::assert::hl)` is wrong. A target does > not have to exists to be able to link against it. Plus, it should > call `find_package(boost_assert)` to bring in the target for when its > not built in the superproject. That part is there solely to enable modular build. If you don't want to bother with modular build as this is a bare minimum viable cmakeification, you can eliminate it. > - There is no installation of the targets Not necessary right now, so out of scope. > - Doing `target_include_directories(boost_core-hl INTERFACE > "include”)` is wrong as this will only add the include directories > for the build. The include directories should be added for the build > and for the installation. As I've repeatedly explained now, installation logic is best implemented by a rootmost CMakeLists. Not in the per-library CMakeLists. We do tell cmake what targets are used by installation via install(TARGETS ...). That's the bare minimum needed for other cmake to implement the remaining installation logic. (On wider picture stuff, install paths need to be absolute I've found, whereas build paths can usually be relative. Relative paths are much nicer during build. In a rootmost CMakeLists which implements some installation logic, you'd iterate the targets for the Boost libraries and configure each programmatically for the appropriate install for that library and that type of library. All the metadata you need to make decisions is available) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

2 5

Re: [boost] [cmake] Minimum viable cmakeification for Boost
by Thomas Heller 20 Jun '17

20 Jun '17

Am 20.06.2017 4:21 nachm. schrieb "Peter Dimov via Boost" < boost(a)lists.boost.org>: Thomas Heller wrote: > As a general observation, I see a lot of statements along the lines of "I > state that XYZ is preferable over UVW", it would be nice to have to have > background information (pros and cons anyone? what do the cmake > authors/docs have to say about this?) on those statements so that everyone > can form their own opinion instead of having to choose whom to trust about > what's "standard" cmake. > That's the problem with CMake, there's no way for someone like me who does not follow it to get a definitive answer to what idiomatic CMake 3.5+ is. There are several articles about it, they all say more or less the same thing - use target_*. I get that. But that's not enough. I see a general (and very predictable) trend of moving from imperative to declarative. Programmers like imperative, but a proper build system really prefers declarative, so CMake is trying to evolve towards declarative. Take for example find_package. It's a command, find me this package, now. But it's much better if a library does not issue "find me this package" commands, but rather declares which packages it needs. So we get "best practice" hacks like redefining find_package. I'm sorry, this doesn't feel right. I hear what you're saying. We'll end up innovating cmake, which for me isn't a bad thing. I'm favoring CMake due to its great support for generating for all kinds of different environments (including proper visual studio solutions). To be fair, I haven't invested as much time in boost.build as I did for cmake. For all platforms I work on, both work equally nice with different quircks on different ends. I'm not using an ide though. For the sake of ide support, I'd lean towards cmake. Regarding the discussion of what's right and wrong when writing your CMakeLists.txt files, it's almost bike shedding. If you want to depend on a library, you'll make it work, no matter what, that's what we do. Nevertheless, in terms of cmakeisms, I really like what Paul put together and what Daniel Pfeifer said in his talk makes a lot of sense in a cmake world. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

1 0