Re: [doc] b2 headers
Mateusz Loskot via Boost-build <[email protected]>
| Newsgroups | gmane.comp.lib.boost.build |
|---|---|
| Message-ID | <CABUeae-vudqk_WMqhZSffDA0y+7zC1bTUNRv-gLoMPc9Hf26YQ@mail.gmail.com> |
On 9 April 2018 at 19:40, Robert Ramey via Boost-build <[email protected]> wrote: > On 4/9/18 10:27 AM, Steven Watanabe via Boost-build wrote: > > OK - you're going to argue that I'm not a typical end user. I don't kno > about that. But this is a great way of working. We should encourage users > to connect to github directly. The idea of downloading a huge monolithic > boost distribution on from time to so last century. That's why I've been prototyping CMake configuration for Boost.GIL that should allow contributors to use reasonably new Boost installed system-wide from binary distribution, then `git pull boostorg/gil` only and be able to develop. >>> But, as long-time Boost.Build users, I dare to judge this is an >>> excellent example of why peole hate this awesome build system :) > > I think the build system lacks clarity regarding whom it is trying to serve, > what it's proper scope is and what it is supposed to do. Might be. TBH, I'm not able to clarify myself what bit of the docs belongs to where. However, using CMake-based knowledge, for general CMake options I go to cmake.org/docs; for a project specific build options, I refer to project.org/docs. But, I know that the former start with CMAKE_ prefix and that small detail is extremely important to get my bearings right. I see no conventions or patterns, no no-brainers to learn. Why not allow intrinsic b2 properties as options b2 --toolset=gcc --variant=debug while all project/configuration-specific can only be given as b2 --property foo=bar b2 -p foo=bar or something like that. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net _______________________________________________ Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build