[boost] [cmake] Minimum viable cmakeification for Boost

[Niall Douglas via Boost]

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/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Sankel via Boost]

On Mon, Jun 19, 2017 at 7:42 PM, Niall Douglas via Boost <
***@lists.boost.org> wrote:

> I've finished the mockup which can be studied at:
>
> https://github.com/ned14/boost-bmv-cmake


Niall, thanks so much for contributing this. It is the most viable Boost
CMake convention I've seen yet and I'm 100% behind it. It is super
informative as well for learning the CMake 3.5 style.

Things I very much like about this system:
- The separation of concerns between library.cmake and systems's
CMakeLists.txt. The former only consists of the library's content where the
latter declares all dependencies. I suspect this would aid in reuse where
someone would prefer to declare different dependencies (or dependencies in
a different way).
- The minimalism. I love how it is both immediately useful for people and
omits bells and whistles. I think it is an excellent way to start for
CMakeification of Boost.

I have a few questions and comments below.

In library.cmake, you use include commands like follows,

include("build/headers.cmake")

. How does 'include' know how to resolve this relative path? Will it always
resolve to CMAKE_CURRENT_SOURCE_DIR? I'm surprised you didn't need to do
this,

include("${CMAKE_CURRENT_LIST_DIR}/build/headers.cmake")

.

In system's 'CMakeLists.txt', you have this,

set(BOOST_LIBRARY_PROJECTS ${BOOST_LIBRARY_PROJECTS} ${PROJECT_NAME}
PARENT_SCOPE)

. I was thinking it may be better to use

list(APPEND BOOST_LIBRARY_PROJECTS ${PROJECT_NAME})

, but then I realized that 'list' doesn't have a parent scope option. You'd
have to add,

set(BOOST_LIBRARY_PROJECTS ${BOOST_LIBRARY_PROJECTS} PARENT_SCOPE)

, which doesn't seem like much of an improvement.

In your top level 'CMakeLists.txt' file, I saw,

add_subdirectory("boostorg" EXCLUDE_FROM_ALL)

. I was wondering how you would deal with unused Boost targets that have
dependencies that don't exist on the system (e.g. Boost.Python's Python
dependency). I suppose the 'boostorg/CMakeLists.txt' could conditionally
add targets by checking dependencies first, but then it seems like one
would get the reverse problem (Boost.Python is really needed, but the
Python dependency isn't there). In this case one would get a cmake-time
error stating that boost::python doesn't exist. Unfortunately, there
wouldn't be any explaination as to why. This isn't a big deal though by any
stretch.

The 'system/CMakeLists.txt' shows situational awareness by including
dependencies with '..' and using 'BoostVersion.cmake'. This precludes
'system' from being buildable outside of the Boost tree. However, I can see
how solving this problem is still up for debate and would be
straightforward to add on top of what you have.

-- David Sankel

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[P F via Boost]

> On Jun 19, 2017, at 6:42 PM, Niall Douglas via Boost <***@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.

- Each project do things like `include("${CMAKE_CURRENT_SOURCE_DIR}/../../cmake/BoostVersion.cmake”)` which is broken when built on its own.

- 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.

- There is no installation of the targets

- 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.




_______________________________________________
Unsubscribe & other changes: http://lists.boost

[Niall Douglas via Boost]

On 20/06/2017 07:27, P F wrote:
>
>> On Jun 19, 2017, at 6:42 PM, Niall Douglas via Boost
>> <***@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".

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.boo

[P F via Boost]

> On Jun 20, 2017, at 7:17 AM, Niall Douglas via Boost <***@lists.boost.org> wrote:
>
> On 20/06/2017 07:27, P F wrote:
>>
>>> On Jun 19, 2017, at 6:42 PM, Niall Douglas via Boost
>>> <***@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.

No, cmake best practice including cmake 3:

* Leave the control of `BUILD_SHARED_LIBS` to your clients[1]

> 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".
>
> 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.

Yes, but this breaks cmake best practice that says:

* Make sure all your projects can be built as standalone and as a subproject of another project.

>
>> - 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.

What do you mean by modular build? There is only two ways it can be as standalone or as a modular build.

>
>> - There is no installation of the targets
>
> Not necessary right now, so out of scope.

It is necessary.

>
>> - 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.

Even if were implemented in the topmost, it would be broken when using `find_package` as the target is using the include directories in the build directory and not the install directory.

>
> (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)

I dont what you are saying here. Install paths should be relative or they should use the `$<INSTALL_PREFIX>` generator expression in order to make the installation relocatable.

[1]: https://de.slideshare.net/DanielPfeifer1/cmake-48475415


_______________________________________________
Unsubscribe & other changes

[P F via Boost]

> On Jun 20, 2017, at 8:32 AM, P F <***@yahoo.com> wrote:
>
>>
>> On Jun 20, 2017, at 7:17 AM, Niall Douglas via Boost <***@lists.boost.org <mailto:***@lists.boost.org>> wrote:
>> 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.
>
> What do you mean by modular build? There is only two ways it can be as standalone or as a modular build.

Correction, I meant to say: there is only two ways it can be built as standalone or as a subproject of another project.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Niall Douglas via Boost]

>>> - 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.
>
> No, cmake best practice including cmake 3:
>
> * Leave the control of `BUILD_SHARED_LIBS` to your clients[1]

That's exactly what I'm doing. A rootlevel CMakeLists can choose to
observe global variables and apply them by choosing only the targets
which are static or shared for build. Non-rootlevel CMakeLists should
have no business ever touching, using, or relying on any global variable
or state. Declaration only.

>>> - 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.
>
> Yes, but this breaks cmake best practice that says:
>
> * Make sure all your projects can be built as standalone and as a
> subproject of another project.

Let me repeat myself because you didn't read my words:

"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.
>
> What do you mean by modular build? There is only two ways it can be as
> standalone or as a modular build.

Ok, "exactly what is needed" build so. If I ask to link against
Boost.System, only Boost.System and its dependencies get built by cmake.
No unnecessary stuff.

You don't actually need that for minimum viable cmake of course. You
could have b2.exe call cmake to build the whole of Boost and place it in
staging exactly as at present.

But it seemed to me if one is to bother with cmakeification, you might
as well formally specify the dependencies of each library and make
possible "exactly what is needed build on demand". It's not much extra
work, and it contributes much added value.

>>> - There is no installation of the targets
>>
>> Not necessary right now, so out of scope.
>
> It is necessary.

No, it really isn't. If people want installation logic, it's trivially
easy for them to write a rootlevel CMakeLists which implements that from
what we've given them. No need for Boost to dictate what installation
means or is by hard coding it into non-rootlevel CMakeLists.

>>> - 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.
>
> Even if were implemented in the topmost, it would be broken when using
> `find_package` as the target is using the include directories in the
> build directory and not the install directory.

That's trivially easy to change at the rootlevel. Just iterate the
targets and change the properties to whatever you feel they need to be.

I also deliberately left open a customisation point on this where
headers.cmake is auto-generated by rootlevel cmake script. It could
inject $<BUILD_INTERFACE> and $<INSTALL_INTERFACE> there if it chose.

I think it unwise to hard code that stuff. It's non-fixed configuration.
End users reusing our cmake may have custom install paths and needs. We
should not be dictating to them what those should be. Let rootlevel
CMakeLists implement that stuff.

>> (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)
>
> I dont what you are saying here. Install paths should be relative or
> they should use the `$<INSTALL_PREFIX>` generator expression in order to
> make the installation relocatable.

For the output yes. I was referring to the input.

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/boos

[paul via Boost]

On Tue, 2017-06-20 at 16:35 +0100, Niall Douglas via Boost wrote:
> >
> > >
> > > >
> > > > - 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. 
> > No, cmake best practice including cmake 3:
> >
> > * Leave the control of `BUILD_SHARED_LIBS` to your clients[1]
> That's exactly what I'm doing. A rootlevel CMakeLists

The clients aren't necessarily the rootlevel cmake. They are mainly the ones
who are invoking cmake.

> can choose to
> observe global variables and apply them by choosing only the targets
> which are static or shared for build. Non-rootlevel CMakeLists should
> have no business ever touching, using, or relying on any global variable
> or state. Declaration only.
>
> >
> > >
> > > >
> > > > - 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.
> > Yes, but this breaks cmake best practice that says:
> >
> > * Make sure all your projects can be built as standalone and as a
> > subproject of another project.
> Let me repeat myself because you didn't read my words:
>
> "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.
> > What do you mean by modular build? There is only two ways it can be as
> > standalone or as a modular build.
> Ok, "exactly what is needed" build so. If I ask to link against
> Boost.System, only Boost.System and its dependencies get built by cmake.
> No unnecessary stuff.

That already happens when you use `EXCLUDE_FROM_ALL`, so cmake only builds the
targets it needs.

>
> You don't actually need that for minimum viable cmake of course. You
> could have b2.exe call cmake to build the whole of Boost and place it in
> staging exactly as at present.
>
> But it seemed to me if one is to bother with cmakeification, you might
> as well formally specify the dependencies of each library and make
> possible "exactly what is needed build on demand". It's not much extra
> work, and it contributes much added value.
>
> >
> > >
> > > >
> > > > - There is no installation of the targets
> > > Not necessary right now, so out of scope.
> > It is necessary.
> No, it really isn't. If people want installation logic, it's trivially
> easy for them to write a rootlevel CMakeLists which implements that from
> what we've given them. No need for Boost to dictate what installation
> means or is by hard coding it into non-rootlevel CMakeLists.

Yes, but when we are building standalone the so called "non-rootlevel" is the
rootlevel cmake.  
>
> >
> > >
> > > >
> > > > - 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.
> > Even if were implemented in the topmost, it would be broken when using
> > `find_package` as the target is using the include directories in the
> > build directory and not the install directory.
> That's trivially easy to change at the rootlevel. Just iterate the
> targets and change the properties to whatever you feel they need to be.
>
> I also deliberately left open a customisation point on this where
> headers.cmake is auto-generated by rootlevel cmake script. It could
> inject $<BUILD_INTERFACE> and $<INSTALL_INTERFACE> there if it chose.
>
> I think it unwise to hard code that stuff. It's non-fixed configuration.
> End users reusing our cmake may have custom install paths and needs.

This is to support custom install paths, and it will support relocatbility as
well.

> We
> should not be dictating to them what those should be. Let rootlevel
> CMakeLists implement that stuff.

For standalone, it is the rootlevel.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.

[Thomas Heller via Boost]

Am 20.06.2017 2:17 nachm. schrieb "Niall Douglas via Boost" <
***@lists.boost.org>:

On 20/06/2017 07:27, P F wrote:
>
>> On Jun 19, 2017, at 6:42 PM, Niall Douglas via Boost
>> <***@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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailm

[Peter Dimov via Boost]

Thomas Heller wrote:

> Err, I tend to highly disagree here. As a library author, I can not know
> if my users need a static or shared library.

You don't have to know. You provide library::static and library::shared
targets, they link to whatever they prefer.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Heller via Boost]

Am 20.06.2017 4:20 nachm. schrieb "Peter Dimov via Boost" <
***@lists.boost.org>:

Thomas Heller wrote:

Err, I tend to highly disagree here. As a library author, I can not know if
> my users need a static or shared library.
>

You don't have to know. You provide library::static and library::shared
targets, they link to whatever they prefer.


That's problematic​. There are platforms which don't allow for shared
libraries. Is the implication that I always have two sets of binaries lying
around? Sometimes, objects need to be built differently, so I'll get to
build everything twice by default? That does not sound like a great
advantage and I miss the argument where BUILD_SHARED_LIBS actually fails to
deliver.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman
/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.

[Peter Dimov via Boost]

Thomas Heller wrote:
> Am 20.06.2017 4:20 nachm. schrieb "Peter Dimov via Boost" <
> ***@lists.boost.org>:
>
> > Thomas Heller wrote:
> >
> > > Err, I tend to highly disagree here. As a library author, I can not
> > > know if my users need a static or shared library.
> >
> >
> > You don't have to know. You provide library::static and library::shared
> > targets, they link to whatever they prefer.
>
> That's problematic​. There are platforms which don't allow for shared
> libraries. Is the implication that I always have two sets of binaries
> lying around? Sometimes, objects need to be built differently, so I'll get
> to build everything twice by default?

I don't understand what you're saying here. Having two targets doesn't mean
that both get built. If the project links to the target, it gets built,
otherwise not.


_______________________________________________
Unsubscribe & other cha

[Thomas Heller via Boost]

Am 20.06.2017 4:31 nachm. schrieb "Peter Dimov via Boost" <
***@lists.boost.org>:

Thomas Heller wrote:

> Am 20.06.2017 4:20 nachm. schrieb "Peter Dimov via Boost" <
> ***@lists.boost.org>:
>
> > Thomas Heller wrote:
> >
> > > Err, I tend to highly disagree here. As a library author, I can not >
> > know if my users need a static or shared library.
> >
> >
> > You don't have to know. You provide library::static and library::shared
> > targets, they link to whatever they prefer.
>
> That's problematic​. There are platforms which don't allow for shared
> libraries. Is the implication that I always have two sets of binaries lying
> around? Sometimes, objects need to be built differently, so I'll get to
> build everything twice by default?
>

I don't understand what you're saying here. Having two targets doesn't mean
that both get built. If the project links to the target, it gets built,
otherwise not.


If I want to distribute my library in compiled form, I need to provide
both, no?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman
/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/

[Thomas Heller via Boost]

Am 20.06.2017 4:47 nachm. schrieb "Thomas Heller" <***@gmail.com>:



Am 20.06.2017 4:31 nachm. schrieb "Peter Dimov via Boost" <
***@lists.boost.org>:

Thomas Heller wrote:

> Am 20.06.2017 4:20 nachm. schrieb "Peter Dimov via Boost" <
> ***@lists.boost.org>:
>
> > Thomas Heller wrote:
> >
> > > Err, I tend to highly disagree here. As a library author, I can not >
> > know if my users need a static or shared library.
> >
> >
> > You don't have to know. You provide library::static and library::shared
> > targets, they link to whatever they prefer.
>
> That's problematic​. There are platforms which don't allow for shared
> libraries. Is the implication that I always have two sets of binaries lying
> around? Sometimes, objects need to be built differently, so I'll get to
> build everything twice by default?
>

I don't understand what you're saying here. Having two targets doesn't mean
that both get built. If the project links to the target, it gets built,
otherwise not.


If I want to distribute my library in compiled form, I need to provide
both, no?


Doesn't make a lot of sense. I have to either way... The difference is that
I have to decide which target to use eventually.

So it's a question which solution puts more burden on the developer, which
I'm not sure about right now...



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman
/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.bo

[Peter Dimov via Boost]

Niall Douglas wrote:

> 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".

The one remaining question I have here is how does a library link to its
dependency. The obvious approach seems to be for filesystem::sl to link to
system::sl and for filesystem::dl to link to system::dl, right? (And a
hypothetical filesystem::hl would probably link to system::sl.)

(Exceptions where the dependency is always ::dl or always ::sl
notwithstanding. The question is about the case where it also supports both,
or all three.)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Niall Douglas via Boost]

>> 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".
>
> The one remaining question I have here is how does a library link to its
> dependency. The obvious approach seems to be for filesystem::sl to link
> to system::sl and for filesystem::dl to link to system::dl, right? (And
> a hypothetical filesystem::hl would probably link to system::sl.)
>
> (Exceptions where the dependency is always ::dl or always ::sl
> notwithstanding. The question is about the case where it also supports
> both, or all three.)

That's the default convention I've always followed in my own code. But I
agree it feels a little wrong, I can see where a dynamic library might
want to use the static library edition of a dependency sometimes if they
are setting -fvisibility=hidden. Because cmake targets propagate their
dependencies to consumers, if the library developer says that the ::dl
edition uses ::dl dependencies, and the end user wants it to use the
::sl dependency, unless the library developer adds a special target for
them then you must resort to monkey patching the properties to change
the hard coded dependency the library developer chose for you.

As much as this might seem important, it isn't as much as it might seem
in practice. Static libraries generally are not compiled to be linked
into DLLs, so they don't mark their symbols as public etc, indeed in
cmake they aren't even compiled with -fPIC by default. So the actual
occasions where you do need to link static library editions into shared
libraries happens less often in practice than you might think.

Still, it leaves me feeling a little uncomfortable. Doing better in
cmake introduces lots of extra custom logic though, you really need
custom functions and macros to ease the pain :(

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

[Peter Dimov via Boost]

Niall Douglas wrote:

> > The one remaining question I have here is how does a library link to its
> > dependency. The obvious approach seems to be for filesystem::sl to link
> > to system::sl and for filesystem::dl to link to system::dl, right? (And
> > a hypothetical filesystem::hl would probably link to system::sl.)
...

> That's the default convention I've always followed in my own code.

It's more complex than that. Even header-only libraries would need all three
subtargets, for several reasons. One, we want the dependency enumeration to
be scripted and therefore not depend on library specifics. Two, we can have
chains pumpkin -> asio -> system, where I want pumpkin::static to propagate
down to system::static, for which I'd need it to link to asio::static.

There's also the question of the "maintainer-preferred" default subtarget.
If plain asio maps to asio::header, as is natural because it _is_ ::header,
this will propagate down to system and switch it into header-only mode, and
I probably don't want that. So the default, even for header-only libraries,
would need to be, f.ex. ::static.

In addition to all that, we want some sort of error to be issued when the
project links to both system::static and system::shared -- not sure how this
is done in CMake.

All in all, I think that if we keep this scheme, we need to drop ::header
and stick to ::static and ::shared. This will eliminate the surprise of
header-only libraries linking to ::header targets downstream.

We may also think about the alternative of giving control of whether system
means system::static or system::shared to root level, and only express
dependencies using the unsuffixed form.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Niall Douglas via Boost]

On 21/06/2017 14:46, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
>
>> > The one remaining question I have here is how does a library link to
>> its > dependency. The obvious approach seems to be for filesystem::sl
>> to link > to system::sl and for filesystem::dl to link to system::dl,
>> right? (And > a hypothetical filesystem::hl would probably link to
>> system::sl.)
> ...
>
>> That's the default convention I've always followed in my own code.
>
> It's more complex than that. Even header-only libraries would need all
> three subtargets, for several reasons. One, we want the dependency
> enumeration to be scripted and therefore not depend on library
> specifics. Two, we can have chains pumpkin -> asio -> system, where I
> want pumpkin::static to propagate down to system::static, for which I'd
> need it to link to asio::static.
>
> There's also the question of the "maintainer-preferred" default
> subtarget. If plain asio maps to asio::header, as is natural because it
> _is_ ::header, this will propagate down to system and switch it into
> header-only mode, and I probably don't want that. So the default, even
> for header-only libraries, would need to be, f.ex. ::static.
>
> In addition to all that, we want some sort of error to be issued when
> the project links to both system::static and system::shared -- not sure
> how this is done in CMake.
>
> All in all, I think that if we keep this scheme, we need to drop
> ::header and stick to ::static and ::shared. This will eliminate the
> surprise of header-only libraries linking to ::header targets downstream.

Before cmake 3.5 you couldn't add dependencies to header only targets on
the basis of your reasoning. So end users had to know what a header only
targets also needed to be linked against.

However, it was fixed. It turns out that end users really like to be
able to target_link_libraries() to some library and not have to care
about what dependencies that library itself has or indeed anything else
for the same reason as they like auto-linking. They don't want to have
to care about that stuff.

In the real world of course, most use of header only libraries is
wrapped into a precompiled header. The number of individual users not
using precompiled headers is probably higher, but in terms of corporate
users it's rare not to see precompiled headers. One little trick I
occasionally do for clients is to replace precompiled headers with
static libraries and I often halve the compile times. People underrate
static libraries.

> We may also think about the alternative of giving control of whether
> system means system::static or system::shared to root level, and only
> express dependencies using the unsuffixed form.

That's another possibility, and I can see the attraction.

But I suspect this is cart before horse, mountain out of molehill stuff.
I think 98% of end users are wholly doing one of these three use cases:

1. All shared Boost libraries.

2. All static Boost libraries.

3. Precompiled headers/Header only Boost libraries.

So keep it simple for now, support those three, see what happens after
an extended beta programme.

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

[Peter Dimov via Boost]

Niall Douglas wrote:
> But I suspect this is cart before horse, mountain out of molehill stuff.
> I think 98% of end users are wholly doing one of these three use cases:
>
> 1. All shared Boost libraries.
>
> 2. All static Boost libraries.
>
> 3. Precompiled headers/Header only Boost libraries.

Even if so, you still need to be able to answer the question "how do I link
to Asio in such a way so that its dependency System is
statically/dynamically linked?"


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Niall Douglas via Boost]

On 21/06/2017 16:53, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
>> But I suspect this is cart before horse, mountain out of molehill stuff.
>> I think 98% of end users are wholly doing one of these three use cases:
>>
>> 1. All shared Boost libraries.
>>
>> 2. All static Boost libraries.
>>
>> 3. Precompiled headers/Header only Boost libraries.
>
> Even if so, you still need to be able to answer the question "how do I
> link to Asio in such a way so that its dependency System is
> statically/dynamically linked?"

I'm saying that ASIO header only users almost certainly will also want
header only Boost.System.

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

[Vinnie Falco via Boost]

On Wed, Jun 21, 2017 at 10:44 AM, Niall Douglas via Boost
<***@lists.boost.org> wrote:
> I'm saying that ASIO header only users almost certainly will also want
> header only Boost.System.

I second that. I would venture a guess that the collective man-hours
wasted by Boost.Asio users wrestling with their build scripts to also
link in Boost.System greatly outweighs the time it would take for one
person to make Boost.System header-only.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Heller via Boost]

Am 21.06.2017 7:44 nachm. schrieb "Niall Douglas via Boost" <
***@lists.boost.org>:

On 21/06/2017 16:53, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
>> But I suspect this is cart before horse, mountain out of molehill stuff.
>> I think 98% of end users are wholly doing one of these three use cases:
>>
>> 1. All shared Boost libraries.
>>
>> 2. All static Boost libraries.
>>
>> 3. Precompiled headers/Header only Boost libraries.
>
> Even if so, you still need to be able to answer the question "how do I
> link to Asio in such a way so that its dependency System is
> statically/dynamically linked?"

I'm saying that ASIO header only users almost certainly will also want
header only Boost.System.


Absolutely not. I'd prefer to link against compiled libraries. If only to
reduce compile times.


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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov via Boost]

Niall Douglas wrote:
> > Even if so, you still need to be able to answer the question "how do I
> > link to Asio in such a way so that its dependency System is
> > statically/dynamically linked?"
>
> I'm saying that ASIO header only users almost certainly will also want
> header only Boost.System.

I don't think so (although now that it has been fixed to use Winapi instead
of <windows.h>, maybe).

But even if true, users of static library A that uses Asio will not
necessarily want a header-only Boost.System, which means that static library
A has to have a way to link to Asio "statically".


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vinnie Falco via Boost]

On Wed, Jun 21, 2017 at 10:58 AM, Thomas Heller via Boost
<***@lists.boost.org> wrote:
> Absolutely not. I'd prefer to link against compiled libraries. If only to
> reduce compile times.

Nothing wrong with the OPTION to link against Boost.System, but
header-only should be the default. Its easier for users and gives a
better experience.

On Wed, Jun 21, 2017 at 11:01 AM, Peter Dimov via Boost
<***@lists.boost.org> wrote:
>> ...ASIO header only users almost certainly will also want
>> header only Boost.System.
>
>
> I don't think so (although now that it has been fixed to use Winapi instead
> of <windows.h>, maybe).
>
> But even if true, users of static library A that uses Asio will not
> necessarily want a header-only Boost.System, which means that static library
> A has to have a way to link to Asio "statically".

For reference, here is the ONE .cpp file which makes Boost.System not
header-only:
https://github.com/boostorg/system/blob/develop/src/error_code.cpp#L14

and here's that one header it includes
https://github.com/boostorg/system/blob/develop/include/boost/system/detail/error_code.ipp#L12

We make people link against Boost.System just for that? Especially
when std::error_code is a built in for C++11 and later? It seems
overkill.

Boost.System should be header-only by default. Then, Asio users will
never need a link dependency.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov via Boost]

Vinnie Falco wrote:
> For reference, here is the ONE .cpp file which makes Boost.System not
> header-only:
> https://github.com/boostorg/system/blob/develop/src/error_code.cpp#L14
>
> and here's that one header it includes
> https://github.com/boostorg/system/blob/develop/include/boost/system/detail/error_code.ipp#L12
>
> We make people link against Boost.System just for that?

No, for that:

https://github.com/boostorg/system/blob/master/include/boost/system/detail/error_code.ipp#L24

Or, in general, we use separate compilation to isolate the users of the
library from the header dependencies required to build (but not use) the
library.

> Boost.System should be header-only by default.

In this case, after the recent fixes, maybe.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Niall Douglas via Boost]

On 21/06/2017 19:01, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
>> > Even if so, you still need to be able to answer the question "how do
>> I > link to Asio in such a way so that its dependency System is >
>> statically/dynamically linked?"
>>
>> I'm saying that ASIO header only users almost certainly will also want
>> header only Boost.System.
>
> I don't think so (although now that it has been fixed to use Winapi
> instead of <windows.h>, maybe).
>
> But even if true, users of static library A that uses Asio will not
> necessarily want a header-only Boost.System, which means that static
> library A has to have a way to link to Asio "statically".

Surely users of static library A that uses ASIO will use the static
library edition of ASIO and the static library edition of System?

AFIO v1 used static library ASIO. Made a huge difference to compile
times, it was my default choice for code development.

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

[Peter Dimov via Boost]

Niall Douglas wrote:
> > But even if true, users of static library A that uses Asio will not
> > necessarily want a header-only Boost.System, which means that static
> > library A has to have a way to link to Asio "statically".
>
> Surely users of static library A that uses ASIO will use the static
> library edition of ASIO and the static library edition of System?

Eh. All right.

Static library A uses header-only library B uses non-header-only library C.
Are we clear now. :-)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Niall Douglas via Boost]

On 21/06/2017 22:51, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
>> > But even if true, users of static library A that uses Asio will not
>> > necessarily want a header-only Boost.System, which means that static
>> > library A has to have a way to link to Asio "statically".
>>
>> Surely users of static library A that uses ASIO will use the static
>> library edition of ASIO and the static library edition of System?
>
> Eh. All right.
>
> Static library A uses header-only library B uses non-header-only library
> C. Are we clear now. :-)

Oh sure. But if that were the case, there is likely a very good reason
for it, so it's desirable to be that way.

The real problem is when the end user doesn't want the specific
combination of hl-sl-dl chosen by the library devs for them. What I was
saying what to supply all-::hl, all-::sl and all-::dl where possible,
and that probably maps onto what 98% of end users will want. The number
which want some weird mashup for ::hl, ::sl and ::dl variants is likely
very low.

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

[Thomas Heller via Boost]

On Thu, Jun 22, 2017 at 12:21 AM, Niall Douglas via Boost <
***@lists.boost.org> wrote:

> On 21/06/2017 22:51, Peter Dimov via Boost wrote:
> > Niall Douglas wrote:
> >> > But even if true, users of static library A that uses Asio will not
> >> > necessarily want a header-only Boost.System, which means that static
> >> > library A has to have a way to link to Asio "statically".
> >>
> >> Surely users of static library A that uses ASIO will use the static
> >> library edition of ASIO and the static library edition of System?
> >
> > Eh. All right.
> >
> > Static library A uses header-only library B uses non-header-only library
> > C. Are we clear now. :-)
>
> Oh sure. But if that were the case, there is likely a very good reason
> for it, so it's desirable to be that way.
>
> The real problem is when the end user doesn't want the specific
> combination of hl-sl-dl chosen by the library devs for them. What I was
> saying what to supply all-::hl, all-::sl and all-::dl where possible,
> and that probably maps onto what 98% of end users will want. The number
> which want some weird mashup for ::hl, ::sl and ::dl variants is likely
> very low.
>

I can only speak for myself here. What my usecases are:
- I don't care whether I got a combination of dynamic and static (which
means I am on a platform supporting dynamic libraries)
- I want a build with everything static

That is, when I configure/run the build, I tell the build system this.
Usually via the command line, in a similar way I set the compiler,
additional flags and paths to dependencies. For CMake, this is, as far as I
am concerned, done by setting specific cache variables, with autotools and
b2, I pass the approrpriate flags. This is then honored by the specific
build scripts.
YMMV, of course. I am still unclear if this is the wrong approach in a
modern, declarative world, or if there's a better approach. If there is
one, which would it be?


>
> 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
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Daniel James via Boost]

On 21 June 2017 at 23:21, Niall Douglas via Boost <***@lists.boost.org> wrote:
>
> The real problem is when the end user doesn't want the specific
> combination of hl-sl-dl chosen by the library devs for them. What I was
> saying what to supply all-::hl, all-::sl and all-::dl where possible,
> and that probably maps onto what 98% of end users will want. The number
> which want some weird mashup for ::hl, ::sl and ::dl variants is likely
> very low.

I guess this might be a stupid question, but what would the 2% of
users who want something different do?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Niall Douglas via Boost]

On 22/06/2017 00:46, Daniel James wrote:
> On 21 June 2017 at 23:21, Niall Douglas via Boost <***@lists.boost.org> wrote:
>>
>> The real problem is when the end user doesn't want the specific
>> combination of hl-sl-dl chosen by the library devs for them. What I was
>> saying what to supply all-::hl, all-::sl and all-::dl where possible,
>> and that probably maps onto what 98% of end users will want. The number
>> which want some weird mashup for ::hl, ::sl and ::dl variants is likely
>> very low.
>
> I guess this might be a stupid question, but what would the 2% of
> users who want something different do?

You can do truly horrible monkey patching in cmake. So, iterating all
targets and doing regex string match and replace on the internal strings
which are built for you by the cmake commands, all of which are just
convenient syntax sugar over the underlying string properties on targets.

If you've seen any real world cmake in use in real world corporations,
you'll likely have seen extended monkey patching logic before. It's
fairly common. That's what the 2% would end up doing I would think. At
least like most advanced cmake, how to do it is well documented on
stackoverflow.

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

[Daniel James via Boost]

On 22 June 2017 at 01:02, Niall Douglas via Boost <***@lists.boost.org> wrote:
>
> You can do truly horrible monkey patching in cmake. So, iterating all
> targets and doing regex string match and replace on the internal strings
> which are built for you by the cmake commands, all of which are just
> convenient syntax sugar over the underlying string properties on targets.
>
> If you've seen any real world cmake in use in real world corporations,
> you'll likely have seen extended monkey patching logic before. It's
> fairly common. That's what the 2% would end up doing I would think. At
> least like most advanced cmake, how to do it is well documented on
> stackoverflow.

Thanks for the explanation. I think I'd be tempted to write my own
build logic. It looks like some of the necessary data can be imported
from your cmake files, and most boost libraries aren't that hard to
build.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[paul via Boost]

On Wed, 2017-06-21 at 18:53 +0300, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
> >
> > But I suspect this is cart before horse, mountain out of molehill stuff.
> > I think 98% of end users are wholly doing one of these three use cases:
> >
> > 1. All shared Boost libraries.
> >
> > 2. All static Boost libraries.
> >
> > 3. Precompiled headers/Header only Boost libraries.
> Even if so, you still need to be able to answer the question "how do I link 
> to Asio in such a way so that its dependency System is 
> statically/dynamically linked?" 

Ultimately, I don't think we should go down this route of providing multiple
targets for the different build variants. This is not the way cmake is setup
to work. Cmake requires different build tree for the different build variants.
This will lead to further complications and frustrations for users.

In the future, we can look for ways to "innovate" cmake to support multiple
build variants, but for now we should stick to the standard cmake workflow if
we are going to support cmake.



_______________________________________________
Unsubscribe & other changes: http://list

[paul via Boost]

On Wed, 2017-06-21 at 16:44 +0100, Niall Douglas via Boost wrote:
> On 21/06/2017 14:46, Peter Dimov via Boost wrote:
> >
> > Niall Douglas wrote:
> >
> > >
> > > >
> > > > The one remaining question I have here is how does a library link to
> > > its > dependency. The obvious approach seems to be for filesystem::sl
> > > to link > to system::sl and for filesystem::dl to link to system::dl,
> > > right? (And > a hypothetical filesystem::hl would probably link to
> > > system::sl.)
> > ...
> >
> > >
> > > That's the default convention I've always followed in my own code.
> > It's more complex than that. Even header-only libraries would need all
> > three subtargets, for several reasons. One, we want the dependency
> > enumeration to be scripted and therefore not depend on library
> > specifics. Two, we can have chains pumpkin -> asio -> system, where I
> > want pumpkin::static to propagate down to system::static, for which I'd
> > need it to link to asio::static.
> >
> > There's also the question of the "maintainer-preferred" default
> > subtarget. If plain asio maps to asio::header, as is natural because it
> > _is_ ::header, this will propagate down to system and switch it into
> > header-only mode, and I probably don't want that. So the default, even
> > for header-only libraries, would need to be, f.ex. ::static.
> >
> > In addition to all that, we want some sort of error to be issued when
> > the project links to both system::static and system::shared -- not sure
> > how this is done in CMake.
> >
> > All in all, I think that if we keep this scheme, we need to drop
> > ::header and stick to ::static and ::shared. This will eliminate the
> > surprise of header-only libraries linking to ::header targets downstream.
> Before cmake 3.5 you couldn't add dependencies to header only targets on
> the basis of your reasoning. So end users had to know what a header only
> targets also needed to be linked against.

Before cmake 3.0. CMake 3.0 introduced interface targets(mainly to support
boost libraries), which allow you to link in usage requirements.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov via Boost]

"P F" wrote:

> - 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.

Niall says that using the global BUILD_SHARED_LIBS is a cmake2ism, and that
explicit targets are preferred nowadays.

> - Doing `if(NOT TARGET boost::assert::hl)` is wrong. A target does not
> have to exists to be able to link against it.

The second sentence has nothing to do with the first. The if is just to
detect if the target has already been declared, in order to avoid declaring
it twice, like an (external) include guard.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Heller via Boost]

On Tue, Jun 20, 2017 at 2:19 PM, Peter Dimov via Boost <
***@lists.boost.org> wrote:

> "P F" wrote:
>
> - 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.
>>
>
> Niall says that using the global BUILD_SHARED_LIBS is a cmake2ism, and
> that explicit targets are preferred nowadays.
>

Niall, can you point me to a reference stating this? Preferably some cmake
documentation telling me what the right(tm) thing to do is.

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.


>
> - Doing `if(NOT TARGET boost::assert::hl)` is wrong. A target does not
>> have to exists to be able to link against it.
>>
>
> The second sentence has nothing to do with the first. The if is just to
> detect if the target has already been declared, in order to avoid declaring
> it twice, like an (external) include guard.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Heller via Boost]

Am 20.06.2017 2:30 nachm. schrieb "Thomas Heller" <***@gmail.com>:



On Tue, Jun 20, 2017 at 2:19 PM, Peter Dimov via Boost <
***@lists.boost.org> wrote:

> "P F" wrote:
>
> - 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.
>>
>
> Niall says that using the global BUILD_SHARED_LIBS is a cmake2ism, and
> that explicit targets are preferred nowadays.
>

Niall, can you point me to a reference stating this? Preferably some cmake
documentation telling me what the right(tm) thing to do is.


https://cmake.org/cmake/help/v3.9/command/add_library.html

The cmake docs still documents BUILD_SHARED_LIBS without giving any
alternative.

Any definite source on what a cmake2ism is or is not would be highly
appreciated.


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.


>
> - Doing `if(NOT TARGET boost::assert::hl)` is wrong. A target does not
>> have to exists to be able to link against it.
>>
>
> The second sentence has nothing to do with the first. The if is just to
> detect if the target has already been declared, in order to avoid declaring
> it twice, like an (external) include guard.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Niall Douglas via Boost]

>> Niall says that using the global BUILD_SHARED_LIBS is a cmake2ism, and
>> that explicit targets are preferred nowadays.
>
> Niall, can you point me to a reference stating this? Preferably some cmake
> documentation telling me what the right(tm) thing to do is.

Any cmake construct which requires you to write an if() in a
non-root-level CMakeLists is a cmake2-ism. There are a very few places
in cmake3 remaining where no good alternative to global variables exist.
BUILD_SHARED_LIBS is definitely not one of those.

Shared libraries usually have different settings to static libs and
again to header only libs. They have different relationships to their
dependencies, different usage requirements for consumers. You can use
generator expressions to encode those differences, but then you've hard
coded them so external cmake no longer can easily override them. You
have just made your non-root CMakeLists hard to reuse by cmake you
didn't write nor design.

Generator expressions are also hard to write and debug, are
overwhelmingly confusing to read, and randomly don't work in some places
depending on which build system generator you are using. So best avoid
all of that complexity - place no complexity at all outside the
rootlevel CMakeLists. Declaration only. Place all custom logic solely in
rootlevel CMakeLists only.

> Any definite source on what a cmake2ism is or is not would be highly
> appreciated.
>
>
> 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.

I believe Stephen Kelly is negotiating a book deal on this. It'll be
some time before that book lands though.

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

[paul via Boost]

On Tue, 2017-06-20 at 16:08 +0100, Niall Douglas via Boost wrote:
> >
> > >
> > > Niall says that using the global BUILD_SHARED_LIBS is a cmake2ism, and
> > > that explicit targets are preferred nowadays.
> > Niall, can you point me to a reference stating this? Preferably some cmake
> > documentation telling me what the right(tm) thing to do is.
> Any cmake construct which requires you to write an if() in a
> non-root-level CMakeLists is a cmake2-ism.

So you mean like this is a cmake2-ism:

if(NOT TARGET boost::assert::hl)
  add_subdirectory("../assert" "boost_assert" EXCLUDE_FROM_ALL)
endif()


> There are a very few places
> in cmake3 remaining where no good alternative to global variables exist.
> BUILD_SHARED_LIBS is definitely not one of those.

You should just write `add_library` and let the clients decide. I find no
reference supporting your claim.

>
> Shared libraries usually have different settings to static libs and
> again to header only libs. They have different relationships to their
> dependencies, different usage requirements for consumers. You can use
> generator expressions to encode those differences,

There is no need to use generator expressions since `BUILD_SHARED_LIBS` is a
cmake variable.

> but then you've hard
> coded them so external cmake no longer can easily override them. You
> have just made your non-root CMakeLists hard to reuse by cmake you
> didn't write nor design.

I do not follow this at all. What I presented does not have these problems.


_______________________________________________
Unsubscribe & other changes: http://lis

[Thomas Heller via Boost]

Am 20.06.2017 5:08 nachm. schrieb "Niall Douglas via Boost" <
***@lists.boost.org>:

>> Niall says that using the global BUILD_SHARED_LIBS is a cmake2ism, and
>> that explicit targets are preferred nowadays.
>
> Niall, can you point me to a reference stating this? Preferably some cmake
> documentation telling me what the right(tm) thing to do is.

Any cmake construct which requires you to write an if() in a
non-root-level CMakeLists is a cmake2-ism. There are a very few places
in cmake3 remaining where no good alternative to global variables exist.
BUILD_SHARED_LIBS is definitely not one of those.


I'll ask again: do you have any reference to those statements? The official
cmake docs seem to disagree about this specific case.

I would even call it non sensical alltogether.

Why should the root cmake be responsible for configuring a specific sub
module. This is asking for cluttering everything into one single entity in
a (almost) totally unrelated place. Why not keep it local to where it
should be used.

One concrete example: I have networking layer which supports different
transports, say tcp, libfabric, MPI and infiniband verbs. The user of my
library doesn't really care about which one is used, so ideally, I would
give him a compiled version of my library with the internal settings I
believe are best for him. In that case, my network layer module would be
configured with one of those options. Naturally, I would think, those
options are defined within this very sub project. The root project really
doesn't care, nor do I want that this implementation detail leaks into the
users CMakeLists.txt.

Would you consider that bad practice to begin with? How would you solve
this?

There are tons of other use cases very similar to that. Having everything
clobbering up in the root Cmakelists.txt doesn't sound appealing to me.


Shared libraries usually have different settings to static libs and
again to header only libs. They have different relationships to their
dependencies, different usage requirements for consumers. You can use
generator expressions to encode those differences, but then you've hard
coded them so external cmake no longer can easily override them. You
have just made your non-root CMakeLists hard to reuse by cmake you
didn't write nor design.

Generator expressions are also hard to write and debug, are
overwhelmingly confusing to read, and randomly don't work in some places
depending on which build system generator you are using. So best avoid
all of that complexity - place no complexity at all outside the
rootlevel CMakeLists. Declaration only. Place all custom logic solely in
rootlevel CMakeLists only.

> Any definite source on what a cmake2ism is or is not would be highly
> appreciated.
>
>
> 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.

I believe Stephen Kelly is negotiating a book deal on this. It'll be
some time before that book lands though.

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Niall Douglas via Boost]

> I'll ask again: do you have any reference to those statements? The
> official cmake docs seem to disagree about this specific case.

The cmake docs are updated on a git pull request basis by volunteers as
and when someone feels they need to be updated. They are, in general,
woefully out of date. And as I mentioned here before, Stephen never
finished the cmake3 documentation effort he began due to changes in
personal circumstance (returning home to Ireland).

> Why should the root cmake be responsible for configuring a specific sub
> module. This is asking for cluttering everything into one single entity
> in a (almost) totally unrelated place. Why not keep it local to where it
> should be used.

I'll repeat myself yet again, but to be honest it'll be for the last
time as I really don't care about this enough to spend more time
repeating myself. I have other stuff to be doing than repeating myself
(specifically, Outcome v2).

In the cmake I mocked up we are separating concerns: "how to build this
library" from "how to configure this library". It is like the intended
difference between the SConstruct and SConscript files in scons: one
file says what needs to be built and how they relate declaratively, the
other file sets flags, optimisation, settings according to the target
system etc imperatively.

In exactly the same way as with scons, the non-root CMakeLists are the
declarative structure describing a build graph. The rootmost CMakeLists
are the imperative commands transforming some subset of that build graph
into a build according to local conditions.

That's the way you ought to be ideally speaking writing your cmake3. I
don't know what else I can explain here. As Peter mentioned, this is 101
elementary build system theory here. It's nothing cmake specific, though
because of how variable scopes usually begin with CMakeLists.txt, it
does strongly encourage the imperative logic to go into the rootmost
layer rather than somewhere more logically placed. But it is what it is.

> One concrete example: I have networking layer which supports different
> transports, say tcp, libfabric, MPI and infiniband verbs. The user of my
> library doesn't really care about which one is used, so ideally, I would
> give him a compiled version of my library with the internal settings I
> believe are best for him. In that case, my network layer module would be
> configured with one of those options. Naturally, I would think, those
> options are defined within this very sub project. The root project
> really doesn't care, nor do I want that this implementation detail leaks
> into the users CMakeLists.txt.
>
> Would you consider that bad practice to begin with? How would you solve
> this?

It depends on if you ever expect unknown third parties to want to do
custom builds of your codebase. If you don't, your approach is fine, and
it's easier. If you do, then you need to separate the declarative stuff
from the imperative stuff. Then unknown third parties can reuse your
declarative stuff, and skip or ignore your imperative stuff as they are
doing a custom build.

> There are tons of other use cases very similar to that. Having
> everything clobbering up in the root Cmakelists.txt doesn't sound
> appealing to me.

You obviously don't place ALL your imperative logic in the very rootmost
CMakeLists. There are natural root points where build config markedly
changes when you go up a directory level. That's where you locate the
imperative logic. If higher level cmake wants to ignore your imperative
logic, it skips over the directory with the CMakeLists with the
imperative logic and adds the subdirectories of the inner directories
directly, thus bringing in only the declarative parts only. So you
"reach in" two directory levels to skip the imperative logic.

Does this make more sense now?

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

[paul via Boost]

On Tue, 2017-06-20 at 22:56 +0100, Niall Douglas via Boost wrote:
> >
> > I'll ask again: do you have any reference to those statements? The
> > official cmake docs seem to disagree about this specific case.
> The cmake docs are updated on a git pull request basis by volunteers as
> and when someone feels they need to be updated. They are, in general,
> woefully out of date. And as I mentioned here before, Stephen never
> finished the cmake3 documentation effort he began due to changes in
> personal circumstance (returning home to Ireland).
>
> >
> > Why should the root cmake be responsible for configuring a specific sub
> > module. This is asking for cluttering everything into one single entity
> > in a (almost) totally unrelated place. Why not keep it local to where it
> > should be used.
> I'll repeat myself yet again, but to be honest it'll be for the last
> time as I really don't care about this enough to spend more time
> repeating myself. I have other stuff to be doing than repeating myself
> (specifically, Outcome v2).

We are not asking to repeat yourself, we are asking for references. As the
references I have for best practices and modern cmake from both Daniel Pfeifer
and Stephen Kelley do not align with what you are saying:

https://www.slideshare.net/DanielPfeifer1/cmake-48475415

http://www.steveire.com/WhatWhyHowCMake.pdf

https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_f
riday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf

Nor does the boost cmake repo they put together align with what you are saying
either:

https://github.com/steveire/BoostCMake

https://github.com/boost-cmake/boost-cmake


>
> In the cmake I mocked up we are separating concerns: "how to build this
> library" from "how to configure this library". It is like the intended
> difference between the SConstruct and SConscript files in scons: one
> file says what needs to be built and how they relate declaratively, the
> other file sets flags, optimisation, settings according to the target
> system etc imperatively.
>
> In exactly the same way as with scons, the non-root CMakeLists are the
> declarative structure describing a build graph. The rootmost CMakeLists
> are the imperative commands transforming some subset of that build graph
> into a build according to local conditions.

Yes, the build scripts should be more declarative, but projects should be
standalone as well, and not require a root cmake. Of course, my approach to
the boost-cmake is fairly declaritive, there is only one conditional in the
top-level cmake, whereas your cmake code is much less delcarative with a lot
of conditionals all over. 



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo

[Peter Dimov via Boost]

paul wrote:

> https://github.com/steveire/BoostCMake

* Latest commit cd85034 on Aug 29 2013
* cmake_minimum_required(VERSION 2.8.11 FATAL_ERROR)

I'd think that even Stephen Kelly can't produce idiomatic CMake 3.5 while
using CMake 2.8. Although who knows.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Paul Fultz II via Boost]

> On Jun 20, 2017, at 6:33 PM, Peter Dimov via Boost <***@lists.boost.org> wrote:
>
> paul wrote:
>
>> https://github.com/steveire/BoostCMake
>
> * Latest commit cd85034 on Aug 29 2013
> * cmake_minimum_required(VERSION 2.8.11 FATAL_ERROR)
>
> I'd think that even Stephen Kelly can't produce idiomatic CMake 3.5 while using CMake 2.8. Although who knows.

This is a lie though because it's using cmake 3 features. It won't build with cmake 2.8 at all.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov via Boost]

Paul Fultz II wrote:
> > On Jun 20, 2017, at 6:33 PM, Peter Dimov via Boost
> > <***@lists.boost.org> wrote:
> >
> > paul wrote:
> >
> >> https://github.com/steveire/BoostCMake
> >
> > * Latest commit cd85034 on Aug 29 2013
> > * cmake_minimum_required(VERSION 2.8.11 FATAL_ERROR)
> >
> > I'd think that even Stephen Kelly can't produce idiomatic CMake 3.5
> > while using CMake 2.8. Although who knows.
>
> This is a lie though because it's using cmake 3 features. It won't build
> with cmake 2.8 at all.

Yes, I looked at the code and it's very similar to what is being suggested
today:

https://github.com/steveire/BoostCMake/blob/master/listsfiles/libs/system/CMakeLists.txt

Header-only libraries don't seem to enumerate dependencies though:

https://github.com/steveire/BoostCMake/blob/master/listsfiles/libs/smart_ptr/CMakeLists.txt


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[paul via Boost]

On Wed, 2017-06-21 at 05:03 +0300, Peter Dimov via Boost wrote:
> Paul Fultz II wrote:
> >
> > >
> > > On Jun 20, 2017, at 6:33 PM, Peter Dimov via Boost 
> > > <***@lists.boost.org> wrote:
> > >
> > > paul wrote:
> > >
> > > >
> > > > https://github.com/steveire/BoostCMake
> > > * Latest commit cd85034  on Aug 29 2013
> > > * cmake_minimum_required(VERSION 2.8.11 FATAL_ERROR)
> > >
> > > I'd think that even Stephen Kelly can't produce idiomatic CMake 3.5 
> > > while using CMake 2.8. Although who knows.
> > This is a lie though because it's using cmake 3 features. It won't build 
> > with cmake 2.8 at all.
> Yes, I looked at the code and it's very similar to what is being suggested 
> today:
>
> https://github.com/steveire/BoostCMake/blob/master/listsfiles/libs/system/CM
> akeLists.txt
>
> Header-only libraries don't seem to enumerate dependencies though:
>
> https://github.com/steveire/BoostCMake/blob/master/listsfiles/libs/smart_ptr
> /CMakeLists.txt

Yes, but I think its evolved since then. At least that is what is seems from
watching Effective Cmake talk at C++Now this year. 

Utlimately, some authors will want to make their cmake standalone, which will
require enumerating the dependencies, but we can't have some cmake scripts
that can be used standalone and others that require being invoked with a root
cmake. We need the build scripts to be consistent, and we need to support both
scenarios.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org

[Niall Douglas via Boost]

>> I'll repeat myself yet again, but to be honest it'll be for the last
>> time as I really don't care about this enough to spend more time
>> repeating myself. I have other stuff to be doing than repeating myself
>> (specifically, Outcome v2).
>
> We are not asking to repeat yourself, we are asking for references. As the
> references I have for best practices and modern cmake from both Daniel Pfeifer
> and Stephen Kelley do not align with what you are saying:

This really is the last time I'll repeat myself. After this I won't
comment further as you are not listening and you keep repeating the same
points after I have already explained why you are mistaken.

Those references of yours regard general purpose cmake in a wide general
purpose use case. In Boost's situation, we have a highly homogeneous
build and configuration, plus lots of end users who do custom builds. So
the use case is different. So we employ a more suitable design.

Those references of yours are also slightly or very out of date. I do
know Stephen personally and I know in detail where he is coming from,
and where he was going with cmake3 before he paused his efforts. His own
public writings and previous Boost cmake efforts are not up to date with
where cmake is now at.

But as I've said here previously, don't take my word for it. If Boost
decides to commit to some approach, Stephen should be hired to consult
on any new design. I think you'll find he greenlights my design over say
your design or indeed his own previous designs because mine is closer to
latest cmake best practice, and it doesn't do so much extra unnecessary
stuff right now, plus it's more more future proof. But that's
speculation on my part.

> Yes, the build scripts should be more declarative, but projects should be
> standalone as well, and not require a root cmake. Of course, my approach to
> the boost-cmake is fairly declaritive, there is only one conditional in the
> top-level cmake, whereas your cmake code is much less delcarative with a lot
> of conditionals all over.

Nobody at any stage has said they wouldn't work standalone. Not all
declared targets within would work, but some would. It's up to
imperative cmake to choose which declarative cmake to use based on
whatever logic it chooses. As I've already explained several times now.

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

[Thomas Heller via Boost]

On 06/20/2017 11:56 PM, Niall Douglas via Boost wrote:
>> I'll ask again: do you have any reference to those statements? The
>> official cmake docs seem to disagree about this specific case.
>
> The cmake docs are updated on a git pull request basis by volunteers as
> and when someone feels they need to be updated. They are, in general,
> woefully out of date. And as I mentioned here before, Stephen never
> finished the cmake3 documentation effort he began due to changes in
> personal circumstance (returning home to Ireland).

To be honest, and forgive my skepticism, I find this to be not a good
sign of something that is to suppose to dominate the industry:
- There is no real documentation available on the "best practices" you
advertise, they are told based on anecdotes
- Kitware is indeed a company who offers support and consulting and
claims to maintain CMake.

Not saying that you (or Stephen Kelly) don't know what you are talking
about...

>
>> Why should the root cmake be responsible for configuring a specific sub
>> module. This is asking for cluttering everything into one single entity
>> in a (almost) totally unrelated place. Why not keep it local to where it
>> should be used.
>
<snip>
>
> In the cmake I mocked up we are separating concerns: "how to build this
> library" from "how to configure this library". It is like the intended
> difference between the SConstruct and SConscript files in scons: one
> file says what needs to be built and how they relate declaratively, the
> other file sets flags, optimisation, settings according to the target
> system etc imperatively.

I can see that and certainly see the benefit of it. I think there is a
great chance to further drive the modularization with that approach. I
guess the consensus would be (each of those file local to the module
being built):
- CMakeLists.txt: Describe targets declaratively
- Dependencies.cmake: Describe dependencies (PUBLIC, PRIVATE,
INTERFACE)
- Install.cmake: Define the install logic
- Setup.cmake: Define Options etc. and eventually call
add_subdirectory to have the CMakeLists.txt being processed

This would seperate concerns, the root CMakeLists.txt would then include
the corresponding Setup.cmake and Install.cmake files. This would be how
the authors envision that the module should be built.
Third parties can either follow that approach or derive their own logic.
The advantage of the advise to have everything clobbered in the root
CMakeLists.txt would be:
- it is scalable (Library authors don't need to ask for permission to
have some options etc. added inside the root)
- the information would be local to the package being built, that is
every user can directly observe which different build options are
available
- Each package can be used standalone or within the super project. The
imperative logic is split, and can be reused on a by need basis
without copy&pasting from one large, central CMakeLists.txt

Does this sound like a suitable approach?

>
> In exactly the same way as with scons, the non-root CMakeLists are the
> declarative structure describing a build graph. The rootmost CMakeLists
> are the imperative commands transforming some subset of that build graph
> into a build according to local conditions.
>
> That's the way you ought to be ideally speaking writing your cmake3. I
> don't know what else I can explain here. As Peter mentioned, this is 101
> elementary build system theory here. It's nothing cmake specific, though
> because of how variable scopes usually begin with CMakeLists.txt, it
> does strongly encourage the imperative logic to go into the rootmost
> layer rather than somewhere more logically placed. But it is what it is.

Interesting that you bring this up ... If you are so much in favor of a
declarative build system, we already have multiple. For example plain
old make or Boost.Build. With that being said, wouldn't it be more
viable to improve Boost.Build with:
- Better Documentation
- More examples
- Tight integration with CMake:
* Have Boost.Build generate XXXConfig.cmake and XXXTargets.cmake
files
* Have a CMake module that drives b2
This would make everyone happy, wouldn't it? People who prefer
declarative builds can stick to Boost.Build. Boost.Build would stop
being "asocial" to CMake based projects.

>
>> One concrete example: I have networking layer which supports different
>> transports, say tcp, libfabric, MPI and infiniband verbs. The user of my
>> library doesn't really care about which one is used, so ideally, I would
>> give him a compiled version of my library with the internal settings I
>> believe are best for him. In that case, my network layer module would be
>> configured with one of those options. Naturally, I would think, those
>> options are defined within this very sub project. The root project
>> really doesn't care, nor do I want that this implementation detail leaks
>> into the users CMakeLists.txt.
>>
>> Would you consider that bad practice to begin with? How would you solve
>> this?
>
> It depends on if you ever expect unknown third parties to want to do
> custom builds of your codebase. If you don't, your approach is fine, and
> it's easier. If you do, then you need to separate the declarative stuff
> from the imperative stuff. Then unknown third parties can reuse your
> declarative stuff, and skip or ignore your imperative stuff as they are
> doing a custom build.
>
>> There are tons of other use cases very similar to that. Having
>> everything clobbering up in the root Cmakelists.txt doesn't sound
>> appealing to me.
>
> You obviously don't place ALL your imperative logic in the very rootmost
> CMakeLists. There are natural root points where build config markedly
> changes when you go up a directory level. That's where you locate the
> imperative logic. If higher level cmake wants to ignore your imperative
> logic, it skips over the directory with the CMakeLists with the
> imperative logic and adds the subdirectories of the inner directories
> directly, thus bringing in only the declarative parts only. So you
> "reach in" two directory levels to skip the imperative logic.
>
> Does this make more sense now?

Thanks for the explanations. It does indeed make more sense now. I hope
I could summarize it correctly and provide a nice consensus.

>
> Niall
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Mateusz Loskot via Boost]

On 21 June 2017 at 10:01, Thomas Heller via Boost <***@lists.boost.org> wrote:
> On 06/20/2017 11:56 PM, Niall Douglas via Boost wrote:
>>> I'll ask again: do you have any reference to those statements? The
>>> official cmake docs seem to disagree about this specific case.
>>
>> The cmake docs are updated on a git pull request basis by volunteers as
>> and when someone feels they need to be updated. They are, in general,
>> woefully out of date. And as I mentioned here before, Stephen never
>> finished the cmake3 documentation effort he began due to changes in
>> personal circumstance (returning home to Ireland).
>
> To be honest, and forgive my skepticism, I find this to be not a good
> sign of something that is to suppose to dominate the industry:
> - There is no real documentation available on the "best practices" you
> advertise, they are told based on anecdotes

I sympathise.

I've been CMake user for almost a decade and the lacking of up to date
documented best practices, idiomatic recipes has been quite frustrating
since day one.

CMake mailing list is actually the only source where one ask for/can find
those [1], but then there is no way to verify that received solutions
actualk present the canonical CMake way
Especially, none of such answers make it to the CMake docs.

[1] eg. https://cmake.org/pipermail/cmake/2010-March/035596.html

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov via Boost]

Thomas Heller wrote:

> People who prefer declarative builds can stick to Boost.Build.

That's missing the point. Declarative build descriptions are preferable in
any build system, and any serious use of one leads inevitably to this same
conclusion. Witness, for instance, how Meson intentionally makes its
language not Python, even though it's very much Python-looking, and how
Bazel also has its own language. This is because if the language is Python,
people are encouraged to program in it, instead of declaring targets.

Target declarations compose, logic that manipulates global environment
doesn't.

Now it's true that the declarative approach is sometimes less convenient.
Imperatively, you just check whether zlib is installed, #define or not
HAVE_ZLIB and build different things based on that. Whereas the alternative
is to have a separate zlib-support library target, which injects a .cpp file
into the main program via usage-requirements, which registers the zlib
support with the main library. But, the upside is that if everyone writes
their build descriptions properly, you just link to the appropriate targets
in the root build file and everything "just works".


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Heller via Boost]

On 06/21/2017 12:58 PM, Peter Dimov via Boost wrote:
> Thomas Heller wrote:
>
>> People who prefer declarative builds can stick to Boost.Build.
>
> That's missing the point. Declarative build descriptions are preferable
> in any build system, and any serious use of one leads inevitably to this
> same conclusion. Witness, for instance, how Meson intentionally makes
> its language not Python, even though it's very much Python-looking, and
> how Bazel also has its own language. This is because if the language is
> Python, people are encouraged to program in it, instead of declaring
> targets.
>
> Target declarations compose, logic that manipulates global environment
> doesn't.
>

I totally get that a declarative build system is superior. The quote was
taken out of context (or I didn't express my intent clearly).
The thing is that we already have a declarative build system
(Boost.Build). People want to interface with CMake though (which is only
very slowly catching up with the declarative stuff), and I assume that
most CMake scripts out in the wild are *not* in the declarative
paradigm, and it takes to get accustomed to it. Yet, there are a lot of
people complaining that Boost is "asocial" because it doesn't interface
well with the predominant build plan generator out there. Since CMake is
moving more and more towards being declarative, the gap seems to close
and we could build a bridge. Or just advertise Boost.Build more
prominently so it isn't seen as the odd one in the block, but the goto
solution.

> Now it's true that the declarative approach is sometimes less
> convenient. Imperatively, you just check whether zlib is installed,
> #define or not HAVE_ZLIB and build different things based on that.
> Whereas the alternative is to have a separate zlib-support library
> target, which injects a .cpp file into the main program via
> usage-requirements, which registers the zlib support with the main
> library. But, the upside is that if everyone writes their build
> descriptions properly, you just link to the appropriate targets in the
> root build file and everything "just works".

FWIW, this is totally doable within CMake. Consider this:

# I guess this if statement has to persist, if someone knows a way
# around it, please fix. Could be placed in another Setup.cmake or so to
# seperate the build logic from this logic.
if (PUMPKIN_WITH_ZLIB)
# This sets ZLIB_FOUND to TRUE if found and exports and gives you the
# ZLIB::ZLIB target.
find_package(ZLIB)
else()
# Workaround to have the target available even when zlib was not
# requested...
add_library(ZLIB::ZLIB INTERFACE IMPORTED)
endif()

# Sets up the zlib dependent target...
add_library(pumpkin_zlib
EXCLUDE_FROM_ALL ${PUMPKIN_ZLIB_SOURCES})
target_compile_definitions(pumpkin_zlib PUMPKIN_HAVE_ZLIB)
target_link_libraries(pumpkin_zlib ZLIB::ZLIB)

# setup the main target.
add_library(pumpkin ${PUMPKIN_SOURCES})
target_link_libraries(pumpkin
PRIVATE $<$<BOOL:${PUMPKIN_WITH_ZLIB}>:pumpkin_zlib>)

And yes, the syntax is horrible ;)
The generator expressions are the way to achieve proper declarative
build logic, I presume. This whole option and find_package thingy is
boilerplate which could be put in a common place to give the impression
on having no if statements in the module CMakeLists.txt :P

>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov via Boost]

Thomas Heller wrote:
> FWIW, this is totally doable within CMake. Consider this:
>
> # I guess this if statement has to persist, if someone knows a way
> # around it, please fix. Could be placed in another Setup.cmake or so to
> # seperate the build logic from this logic.
> if (PUMPKIN_WITH_ZLIB)
> # This sets ZLIB_FOUND to TRUE if found and exports and gives you the
> # ZLIB::ZLIB target.
> find_package(ZLIB)
> else()
> # Workaround to have the target available even when zlib was not
> # requested...
> add_library(ZLIB::ZLIB INTERFACE IMPORTED)
> endif()
>
> # Sets up the zlib dependent target...
> add_library(pumpkin_zlib
> EXCLUDE_FROM_ALL ${PUMPKIN_ZLIB_SOURCES})
> target_compile_definitions(pumpkin_zlib PUMPKIN_HAVE_ZLIB)
> target_link_libraries(pumpkin_zlib ZLIB::ZLIB)
>
> # setup the main target.
> add_library(pumpkin ${PUMPKIN_SOURCES})
> target_link_libraries(pumpkin
> PRIVATE $<$<BOOL:${PUMPKIN_WITH_ZLIB}>:pumpkin_zlib>)

What I had in mind was more like this:

add_library(pumpkin ${PUMPKIN_SOURCES})

add_library(pumpkin_zlib ${PUMPKIN_ZLIB_SOURCES})
target_link_libraries(pumpkin_zlib pumpkin)
target_link_libraries(pumpkin_zlib ZLIB::ZLIB)

with the find_package logic residing in the rootmost CMakeLists, where the
project links or does not link to pumpkin_zlib, as appropriate.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Heller via Boost]

On 06/21/2017 02:11 PM, Peter Dimov via Boost wrote:
> Thomas Heller wrote:
>> FWIW, this is totally doable within CMake. Consider this:
>>
>> # I guess this if statement has to persist, if someone knows a way
>> # around it, please fix. Could be placed in another Setup.cmake or so to
>> # seperate the build logic from this logic.
>> if (PUMPKIN_WITH_ZLIB)
>> # This sets ZLIB_FOUND to TRUE if found and exports and gives you the
>> # ZLIB::ZLIB target.
>> find_package(ZLIB)
>> else()
>> # Workaround to have the target available even when zlib was not
>> # requested...
>> add_library(ZLIB::ZLIB INTERFACE IMPORTED)
>> endif()
>>
>> # Sets up the zlib dependent target...
>> add_library(pumpkin_zlib
>> EXCLUDE_FROM_ALL ${PUMPKIN_ZLIB_SOURCES})
>> target_compile_definitions(pumpkin_zlib PUMPKIN_HAVE_ZLIB)
>> target_link_libraries(pumpkin_zlib ZLIB::ZLIB)
>>
>> # setup the main target.
>> add_library(pumpkin ${PUMPKIN_SOURCES})
>> target_link_libraries(pumpkin
>> PRIVATE $<$<BOOL:${PUMPKIN_WITH_ZLIB}>:pumpkin_zlib>)
>
> What I had in mind was more like this:
>
> add_library(pumpkin ${PUMPKIN_SOURCES})
>
> add_library(pumpkin_zlib ${PUMPKIN_ZLIB_SOURCES})
> target_link_libraries(pumpkin_zlib pumpkin)
> target_link_libraries(pumpkin_zlib ZLIB::ZLIB)
>
> with the find_package logic residing in the rootmost CMakeLists, where
> the project links or does not link to pumpkin_zlib, as appropriate.

What would be the rootmost CMakeLists.txt? The one in boostorg in our
case? The one that our users would write?
I am still having difficulties to see the benefits of having it all in
the rootmost file (since I really have problems grasping what is
actually means).

For reference, I just had a quick glance at the iostreams (which has a
dependency on zlib) Jamfile.v2. Two observations from my side:
1) It looks very imperative
2) The zlib dependency is not handled at the Jamroot but in the
component directly.
That is, it looks very similar to what I proposed earlier.

What do I miss?

>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov via Boost]

Thomas Heller wrote:

> For reference, I just had a quick glance at the iostreams (which has a
> dependency on zlib) Jamfile.v2. Two observations from my side:
> 1) It looks very imperative
> 2) The zlib dependency is not handled at the Jamroot but in the
> component directly.

Yes, which is why your idea that Boost.Build is for declarative people and
CMake is for imperative people is wrong. :-)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[paul via Boost]

On Wed, 2017-06-21 at 15:11 +0300, Peter Dimov via Boost wrote:
> Thomas Heller wrote:
> >
> > FWIW, this is totally doable within CMake. Consider this:
> >
> > # I guess this if statement has to persist, if someone knows a way
> > # around it, please fix. Could be placed in another Setup.cmake or so to
> > # seperate the build logic from this logic.
> > if (PUMPKIN_WITH_ZLIB)
> > # This sets ZLIB_FOUND to TRUE if found and exports and gives you the
> > # ZLIB::ZLIB target.
> >   find_package(ZLIB)
> > else()
> > # Workaround to have the target available even when zlib was not
> > # requested...
> >   add_library(ZLIB::ZLIB INTERFACE IMPORTED)
> > endif()
> >
> > # Sets up the zlib dependent target...
> > add_library(pumpkin_zlib
> >     EXCLUDE_FROM_ALL ${PUMPKIN_ZLIB_SOURCES})
> > target_compile_definitions(pumpkin_zlib PUMPKIN_HAVE_ZLIB)
> > target_link_libraries(pumpkin_zlib ZLIB::ZLIB)
> >
> > # setup the main target.
> > add_library(pumpkin ${PUMPKIN_SOURCES})
> > target_link_libraries(pumpkin
> >     PRIVATE $<$<BOOL:${PUMPKIN_WITH_ZLIB}>:pumpkin_zlib>)
> What I had in mind was more like this:
>
> add_library(pumpkin ${PUMPKIN_SOURCES})
>
> add_library(pumpkin_zlib ${PUMPKIN_ZLIB_SOURCES})
> target_link_libraries(pumpkin_zlib pumpkin)
> target_link_libraries(pumpkin_zlib ZLIB::ZLIB)
>
> with the find_package logic residing in the rootmost CMakeLists, where the 
> project links or does not link to pumpkin_zlib, as appropriate. 

The find_package shouldn't be in the root directory. It should be in the same
project directory as that is what that project needs, and each project should
be standalone. 

This won't prevent the ability to use `add_subdirectory`, but the root cmake
is aware of what dependencies it is adding as a subdirectory and what
dependencies its relying on being prebuilt, so this is where the adjustments
to `find_package` go.

>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boo
> st

_______________________________________________
Unsubscribe & other c

[Peter Dimov via Boost]

paul wrote:
> On Wed, 2017-06-21 at 15:11 +0300, Peter Dimov via Boost wrote:
> > What I had in mind was more like this:
> >
> > add_library(pumpkin ${PUMPKIN_SOURCES})
> >
> > add_library(pumpkin_zlib ${PUMPKIN_ZLIB_SOURCES})
> > target_link_libraries(pumpkin_zlib pumpkin)
> > target_link_libraries(pumpkin_zlib ZLIB::ZLIB)
> >
> > with the find_package logic residing in the rootmost CMakeLists, where
> > the project links or does not link to pumpkin_zlib, as appropriate.
>
> The find_package shouldn't be in the root directory. It should be in the
> same project directory as that is what that project needs, and each
> project should be standalone.

In other words, what I wrote, with find_package(ZLIB) prepended?

How are version conflicts resolved? If library A says find_package(Boost
1.62.0) and later library B says find_package(Boost 1.64.0), can I
find_package(Boost 1.64.0) at root level first to keep them happy?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[paul via Boost]

On Wed, 2017-06-21 at 19:01 +0300, Peter Dimov via Boost wrote:
> paul wrote:
> >
> > On Wed, 2017-06-21 at 15:11 +0300, Peter Dimov via Boost wrote:
> > >
> > > What I had in mind was more like this:
> > >
> > > add_library(pumpkin ${PUMPKIN_SOURCES})
> > >
> > > add_library(pumpkin_zlib ${PUMPKIN_ZLIB_SOURCES})
> > > target_link_libraries(pumpkin_zlib pumpkin)
> > > target_link_libraries(pumpkin_zlib ZLIB::ZLIB)
> > >
> > > with the find_package logic residing in the rootmost CMakeLists, where 
> > > the project links or does not link to pumpkin_zlib, as appropriate.
> > The find_package shouldn't be in the root directory. It should be in the 
> > same project directory as that is what that project needs, and each 
> > project should be standalone.
> In other words, what I wrote, with find_package(ZLIB) prepended?

Yes

>
> How are version conflicts resolved? If library A says find_package(Boost 
> 1.62.0) and later library B says find_package(Boost 1.64.0), can I 
> find_package(Boost 1.64.0) at root level first to keep them happy? 

Yes, although, the root doesn't need to say `find_package` at all since its
getting boost with `add_subdirectory`, right?



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/

[Peter Dimov via Boost]

paul wrote:
> > How are version conflicts resolved? If library A says find_package(Boost
> > 1.62.0) and later library B says find_package(Boost 1.64.0), can I
> > find_package(Boost 1.64.0) at root level first to keep them happy?
>
> Yes, although, the root doesn't need to say `find_package` at all since
> its getting boost with `add_subdirectory`, right?

No, my question here is about a zlib-like dependency, but since nobody
specifies a version for it, I used Boost as a placeholder of a versioned
preinstalled dependency.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Niall Douglas via Boost]

> The thing is that we already have a declarative build system
> (Boost.Build). People want to interface with CMake though (which is only
> very slowly catching up with the declarative stuff), and I assume that
> most CMake scripts out in the wild are *not* in the declarative
> paradigm, and it takes to get accustomed to it. Yet, there are a lot of
> people complaining that Boost is "asocial" because it doesn't interface
> well with the predominant build plan generator out there. Since CMake is
> moving more and more towards being declarative, the gap seems to close
> and we could build a bridge. Or just advertise Boost.Build more
> prominently so it isn't seen as the odd one in the block, but the goto
> solution.

I still like the automated Jamfile.v2 to cmake generator idea. Like the
svn to git transition was done, except you never actually retire the old
system. The generated cmake is for packaging and end users only.

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

[paul via Boost]

On Wed, 2017-06-21 at 13:54 +0200, Thomas Heller via Boost wrote:
> On 06/21/2017 12:58 PM, Peter Dimov via Boost wrote:
> >
> > Thomas Heller wrote:
> >
> > >
> > > People who prefer declarative builds can stick to Boost.Build.
> > That's missing the point. Declarative build descriptions are preferable
> > in any build system, and any serious use of one leads inevitably to this
> > same conclusion. Witness, for instance, how Meson intentionally makes
> > its language not Python, even though it's very much Python-looking, and
> > how Bazel also has its own language. This is because if the language is
> > Python, people are encouraged to program in it, instead of declaring
> > targets.
> >
> > Target declarations compose, logic that manipulates global environment
> > doesn't.
> >
> I totally get that a declarative build system is superior.

This is what I was originally trying to do with BCM:

bcm_boost_package(core
    VERSION 1.61.0
    DEPENDS
        assert
        config
)

This is quite simple and declarative, but then boost is not creating another
build-like system that people are not familiar with. So I think we should try
to use as much vanilla cmake as possible, but I do think using some custom
function can help enumerating the dependencies in other contexts.

> The quote was
> taken out of context (or I didn't express my intent clearly).
> The thing is that we already have a declarative build system
> (Boost.Build). People want to interface with CMake though (which is only
> very slowly catching up with the declarative stuff), and I assume that
> most CMake scripts out in the wild are *not* in the declarative
> paradigm, and it takes to get accustomed to it. Yet, there are a lot of
> people complaining that Boost is "asocial" because it doesn't interface
> well with the predominant build plan generator out there. Since CMake is
> moving more and more towards being declarative, the gap seems to close
> and we could build a bridge. Or just advertise Boost.Build more
> prominently so it isn't seen as the odd one in the block, but the goto
> solution.
>
> >
> > Now it's true that the declarative approach is sometimes less
> > convenient. Imperatively, you just check whether zlib is installed,
> > #define or not HAVE_ZLIB and build different things based on that.
> > Whereas the alternative is to have a separate zlib-support library
> > target, which injects a .cpp file into the main program via
> > usage-requirements, which registers the zlib support with the main
> > library. But, the upside is that if everyone writes their build
> > descriptions properly, you just link to the appropriate targets in the
> > root build file and everything "just works".
> FWIW, this is totally doable within CMake. Consider this:
>
> # I guess this if statement has to persist, if someone knows a way
> # around it, please fix. Could be placed in another Setup.cmake or so to
> # seperate the build logic from this logic.
> if (PUMPKIN_WITH_ZLIB)
> # This sets ZLIB_FOUND to TRUE if found and exports and gives you the
> # ZLIB::ZLIB target.
>   find_package(ZLIB)
> else()
> # Workaround to have the target available even when zlib was not
> # requested...
>   add_library(ZLIB::ZLIB INTERFACE IMPORTED)
> endif()
>
> # Sets up the zlib dependent target...
> add_library(pumpkin_zlib
>     EXCLUDE_FROM_ALL ${PUMPKIN_ZLIB_SOURCES})
> target_compile_definitions(pumpkin_zlib PUMPKIN_HAVE_ZLIB)
> target_link_libraries(pumpkin_zlib ZLIB::ZLIB)
>
> # setup the main target.
> add_library(pumpkin ${PUMPKIN_SOURCES})
> target_link_libraries(pumpkin
>     PRIVATE $<$<BOOL:${PUMPKIN_WITH_ZLIB}>:pumpkin_zlib>)
>
> And yes, the syntax is horrible ;)

The syntax is horrible. It really should just be:

if(PUMPKIN_WITH_ZLIB)
target_link_libraries(pumpkin pumpkin_zlib)
endif()

More people will understand the above than the generator expressions.

> The generator expressions are the way to achieve proper declarative
> build logic, I presume.

The generator expressions are there to handle logic that can't be decided
during configuration.


_______________________________________________
Unsubscribe & other changes: http://lists.boost

[Niall Douglas via Boost]

On 21/06/2017 09:01, Thomas Heller via Boost wrote:
> On 06/20/2017 11:56 PM, Niall Douglas via Boost wrote:
>> The cmake docs are updated on a git pull request basis by volunteers as
>> and when someone feels they need to be updated. They are, in general,
>> woefully out of date. And as I mentioned here before, Stephen never
>> finished the cmake3 documentation effort he began due to changes in
>> personal circumstance (returning home to Ireland).
>
> To be honest, and forgive my skepticism, I find this to be not a good
> sign of something that is to suppose to dominate the industry:
> - There is no real documentation available on the "best practices" you
> advertise, they are told based on anecdotes
> - Kitware is indeed a company who offers support and consulting and
> claims to maintain CMake.
>
> Not saying that you (or Stephen Kelly) don't know what you are talking
> about...

Kitware makes no money from cmake. For them it's a cost of sales. They
support it only in so far as cmake provides build for their money making
products. cmake was always something they just open sourced to enable
the clients of their paid products buy in to their custom build process
without worrying about getting locked in.

Most of the docs and features come from open source contribution as
submitted patchsets. They vary enormously in quality, Kitware only
provides minimum review before merging. Like with most open source build
systems, there is a huge open bug count, many serious bugs unfixed in
eight or more years.

Nobody has ever claimed cmake is great, or even good. Nobody I know who
uses it likes it or thinks it well designed. It's only major claim is
that it isn't flawed with a showstopper failing like say scons or make,
and it lets average devs use their preferred local IDE.

But it has won the great build systems competition. It is the industry
standard, nothing else is remotely close in market share. And that
brings lots of ecosystem benefits which less popular build tools cannot
achieve. There is very good reason that VS2017 can now directly load and
work with cmake projects. Every other major IDE can, so Visual Studio
had to keep up. That speaks volumes as to where the industry is going.

>> In the cmake I mocked up we are separating concerns: "how to build this
>> library" from "how to configure this library". It is like the intended
>> difference between the SConstruct and SConscript files in scons: one
>> file says what needs to be built and how they relate declaratively, the
>> other file sets flags, optimisation, settings according to the target
>> system etc imperatively.
>
> I can see that and certainly see the benefit of it. I think there is a
> great chance to further drive the modularization with that approach. I
> guess the consensus would be (each of those file local to the module
> being built):
> - CMakeLists.txt: Describe targets declaratively
> - Dependencies.cmake: Describe dependencies (PUBLIC, PRIVATE,
> INTERFACE)
> - Install.cmake: Define the install logic
> - Setup.cmake: Define Options etc. and eventually call
> add_subdirectory to have the CMakeLists.txt being processed

One very nice approach which I'd personally prefer, but felt it too
risque to propose here, is that CMakeLists.txt is always auto generated
and library devs cannot customise it. They can customise .cmake files in
a cmake directory very similarly to what you just listed, but you are
only permitted to use a certain whitelist of cmake commands in certain
files, so for example the cmake/targets.cmake file solely allows
declarative targets and no logic. Other files very like the above do
stuff exactly like you suggest like install, setup etc.

This forces library devs to write clean, scalable, reusable cmake. But I
know boost-dev doesn't like their code being enforced via automated
rules, and I think it would count as "cmake innovation", so I didn't
propose that here.

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

[Chris Glover via Boost]

On Wed, 21 Jun 2017 at 04:01 Thomas Heller via Boost <***@lists.boost.org>
wrote:

>
> Interesting that you bring this up ... If you are so much in favor of a
> declarative build system, we already have multiple. For example plain
> old make or Boost.Build. With that being said, wouldn't it be more
> viable to improve Boost.Build with:
> - Better Documentation
> - More examples
> - Tight integration with CMake:
> * Have Boost.Build generate XXXConfig.cmake and XXXTargets.cmake
> files
> * Have a CMake module that drives b2
> This would make everyone happy, wouldn't it? People who prefer
> declarative builds can stick to Boost.Build. Boost.Build would stop
> being "asocial" to CMake based projects.
>
>
For what it's worth, I would vote for this approach. I think it would solve
all or most of the end user problems for those that want plug and play with
cmake.

-- chris

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Egor Pugin via Boost]

Hi,

I've developed package manager based on cmake with declarative format
and custom cmake insertions (for imperative purposes). Declarative
format is generated into CMakeLists.txt.
And now I think that declarative approach does not scale well. With
increasing complexity of conditions of build system
instructions/settings/configurations, declarative format becomes
unmaintainable. Also it involves repetition of common constructions.
So you need to be careful with it.
Of course in simple cases when a library follows default rules,
declarative config for it can be just empty.

Some examples with comments:

1. https://cppan.org/projects/pvt.cppan.demo.boost
pvt.cppan.demo.boost project page. Most of the libraries has their
dependencies set correctly based on #includes. (Still boost deps are
the plate of spaghetti with header only deps.)

2. https://cppan.org/pvt.cppan.demo.boost.filesystem/version/1.64.0/specification
pvt.cppan.demo.boost.filesystem-1.64.0 specification.

3. https://pastebin.com/h4DB9tNj
Full declarative config of boost with all libraries. Again, boost deps
are not granular and look ugly.

4. https://pastebin.com/XPwW7ZHx
LLVM project specification. Exactly on this level I think declarative
approach got it drawbacks. There are a lot of similar targets that
differ only with their name, so they can be wrapped into functions or
macros as it's done in LLVM's cmake configs.

ps. I'm not proposing to use cppan in boost. It's only FYI, maybe you
find some useful ideas.
https://cppan.org/ - package manager page itself.

--
Egor Pugin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Robert Ramey via Boost]

On 6/21/17 6:47 AM, Chris Glover via Boost wrote:
> On Wed, 21 Jun 2017 at 04:01 Thomas Heller via Boost <***@lists.boost.org>
> wrote:
>
>>
>> Interesting that you bring this up ... If you are so much in favor of a
>> declarative build system, we already have multiple. For example plain
>> old make or Boost.Build. With that being said, wouldn't it be more
>> viable to improve Boost.Build with:
>> - Better Documentation
>> - More examples

Boost build has been hampered by a number of design decisions which have
never been revisited.

a) It is "too smart". It tries to infer the toolset by looking around
the file system. If one has more than one compiler set there is really
know way to know which one is going to pick. So then one is forced to
go into the workings of boost build to figure out how to over ride this
behavior.

b) It is driven by "side effects" that is the environment. It searches
the local file system starting from the current directory and up the
tree for a "special" Jamroot file. So if you move your project to
another directory, there is no guarantee that it will work the same.
This was seen by the original designers as a feature - it's smart enough
to know what you really want.

c) It has non-obvious dependencies on other files which one generally
doesn't know about: user-config.jam (in the users home directory),
project-config.jam (hmmm I'm not sure where this supposed to be), etc.

All these are fruit of the idea that - we, the developers of bjam can
figure out what you need so the build will be really simple. To fix
bjam this idea has to be set aside. All of the linkages to other stuff
in the file system should be replaced by either data in the jamfile or
if not in the jamfile better yet runtime switches so the command syntax
would look like

b3 toolset="asfasfa" variant="12321" etc.

Which would respond with:
build failed, errors found:
toolset "asdfasdf" not found
variant must be either "debug" or "release"
no jamroot specified in either jamfile or command line
...

So now the user is sent to look for the specific piece of information he
has to add.

users who couldn't put stuff in the Jamfile who are tired of putting the
stuff on the command line would address this as we always to - a oneline
local script -

Of course this would be coupled with the manual which would describe
this stuff. Actually, the text for this stuff is already in boost build
docs. It's just that no one knows what part he needs to read to get it
right. So compiling this document and code reorganization to support
the above would have to go hand in hand.

Bjam is much, much better than is generally appreciated. Its' just that
the designers were/are too clever and presume we are also.

Robert Ramey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Edward Diener via Boost]

On 6/21/2017 11:23 AM, Robert Ramey via Boost wrote:
> On 6/21/17 6:47 AM, Chris Glover via Boost wrote:
>> On Wed, 21 Jun 2017 at 04:01 Thomas Heller via Boost
>> <***@lists.boost.org>
>> wrote:
>>
>>>
>>> Interesting that you bring this up ... If you are so much in favor of a
>>> declarative build system, we already have multiple. For example plain
>>> old make or Boost.Build. With that being said, wouldn't it be more
>>> viable to improve Boost.Build with:
>>> - Better Documentation
>>> - More examples
>
> Boost build has been hampered by a number of design decisions which have
> never been revisited.
>
> a) It is "too smart". It tries to infer the toolset by looking around
> the file system. If one has more than one compiler set there is really
> know way to know which one is going to pick. So then one is forced to
> go into the workings of boost build to figure out how to over ride this
> behavior.

The solution, of course, is always to pass toolset=xxx to the b2 command
line. In my own use of b2 I always do this.

snipped...
>
> Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Robert Ramey via Boost]

On 6/21/17 10:01 AM, Edward Diener via Boost wrote:
>> Boost build has been hampered by a number of design decisions which
>> have never been revisited.
>>
>> a) It is "too smart". It tries to infer the toolset by looking around
>> the file system. If one has more than one compiler set there is
>> really know way to know which one is going to pick. So then one is
>> forced to go into the workings of boost build to figure out how to
>> over ride this behavior.
>
> The solution, of course, is always to pass toolset=xxx to the b2 command
> line. In my own use of b2 I always do this.

Right and so do I.

I also pass the other switches. This re-enforces my point that bjam
could my made much better and easier to use with huge changes by
altering it's user interface philosophy. If I were required to pass all
the switches either on the command line or in the local jamfile itself,
then I would only get helpful error messages rather than inexplicable
behavior. I believe that evolving the bjam user interface to his
phisophy wouldn't be a huge project.

Robert Ramey

>
> snipped...
>>
>> Robert Ramey
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Steven Watanabe via Boost]

AmDG

On 06/21/2017 09:23 AM, Robert Ramey via Boost wrote:
>
> All these are fruit of the idea that - we, the developers of bjam can
> figure out what you need so the build will be really simple. To fix
> bjam this idea has to be set aside. All of the linkages to other stuff
> in the file system should be replaced by either data in the jamfile or
> if not in the jamfile better yet runtime switches so the command syntax
> would look like
>
> b3 toolset="asfasfa" variant="12321" etc.
>
> Which would respond with:
> build failed, errors found:
> toolset "asdfasdf" not found

ERROR: rule "asdfasdf.init" unknown in module "toolset".
(Okay, I admit that's quite cryptic)

> variant must be either "debug" or "release"

error: "12321" is not a known value of feature <variant>
error: legal values: "debug" "release" "profile" "debug-python"

> no jamroot specified in either jamfile or command line
> ...
>

error: no Jamfile in current directory found, and no target references
specified.
-------
error: Could not find parent for project at '.'
error: Did not find Jamfile.jam or Jamroot.jam in any parent directory.

Also: 'b3' is not recognized as an internal or external command,
operable program or batch file.

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov via Boost]

Steven Watanabe wrote:

> Also: 'b3' is not recognized as an internal or external command, operable
> program or batch file.

No wonder Boost is dying, we haven't even released b3 yet.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stefan Seefeld via Boost]

On 21.06.2017 18:01, Peter Dimov via Boost wrote:
> Steven Watanabe wrote:
>
>> Also: 'b3' is not recognized as an internal or external command,
>> operable program or batch file.
>
> No wonder Boost is dying, we haven't even released b3 yet.

Well, a while ago I started an effort to write a new Python frontend to
Boost.Build, naming it 'b3' (wrongly believing that the '2' in 'b2'
represented a version).
This is now morphed into 'faber'
(https://github.com/stefanseefeld/faber,
https://stefanseefeld.github.io/faber/doc/html/index.html), which I'm
intending to present here soon, as a Python frontend to Boost.Build. Not
sure whether that will prevent Boost from dying, though. ;-)

Stefan

--

...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Robert Ramey via Boost]

On 6/21/17 2:57 PM, Steven Watanabe via Boost wrote:
> AmDG
>
> On 06/21/2017 09:23 AM, Robert Ramey via Boost wrote:
>>
>> All these are fruit of the idea that - we, the developers of bjam can
>> figure out what you need so the build will be really simple. To fix
>> bjam this idea has to be set aside. All of the linkages to other stuff
>> in the file system should be replaced by either data in the jamfile or
>> if not in the jamfile better yet runtime switches so the command syntax
>> would look like
>>
>> b3 toolset="asfasfa" variant="12321" etc.
>>
>> Which would respond with:
>> build failed, errors found:
>> toolset "asdfasdf" not found
>
> ERROR: rule "asdfasdf.init" unknown in module "toolset".
> (Okay, I admit that's quite cryptic)

LOL
>
>> variant must be either "debug" or "release"
>
> error: "12321" is not a known value of feature <variant>
> error: legal values: "debug" "release" "profile" "debug-python"

OK
>
>> no jamroot specified in either jamfile or command line
>> ...

>>
>
> error: no Jamfile in current directory found, and no target references
> specified.
> -------
> error: Could not find parent for project at '.'

that's pretty cryptic

> error: Did not find Jamfile.jam or Jamroot.jam in any parent directory.


>
> Also: 'b3' is not recognized as an internal or external command,
> operable program or batch file.
Of course, I was refering to the next bjam version

Note that my post made the complaint that if you leave the options
unspecified, the system just fills them from .... = who knows were.

It would be better to not do this and just print the error message:

need to specify root with -?
need to specify toolset
need to specify variant
need to specify linkage
etc.

Of course if the user then specifies the optiones erroneously as I did
above, the error messages are sort of OK and he knows what to look into.

The current sitation is that he gets some sort of message and WTF?
Worse, he changes the environment slightly - such as user login which
points to a differnt user-config.jam or some environmental variable he
doesn't remember, or removes some file he doesn't remember he gets
different behavior and has no clue why. These are effectively hidden
global variables affecting the build system. It can take days to track
down the source of errors like this.

Maybe as an experiment one might consider adding yet another switch -
-no_defaults and see how that works out.

Robert Ramey

>
> In Christ,
> Steven Watanabe
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Paul A. Bristow via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-***@lists.boost.org] On Behalf Of Robert Ramey via Boost
> Sent: 21 June 2017 16:23
> To: Chris Glover via Boost
> Cc: Robert Ramey
> Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
>
> On 6/21/17 6:47 AM, Chris Glover via Boost wrote:
> > On Wed, 21 Jun 2017 at 04:01 Thomas Heller via Boost <***@lists.boost.org>
> > wrote:
> >
> >>
> >> Interesting that you bring this up ... If you are so much in favor of a
> >> declarative build system, we already have multiple. For example plain
> >> old make or Boost.Build. With that being said, wouldn't it be more
> >> viable to improve Boost.Build with:
> >> - Better Documentation
> >> - More examples
>
> Boost build has been hampered by a number of design decisions which have
> never been revisited.

<snip>

> Of course this would be coupled with the manual which would describe
> this stuff. Actually, the text for this stuff is already in boost build
> docs. It's just that no one knows what part he needs to read to get it
> right. So compiling this document and code reorganization to support
> the above would have to go hand in hand.
>
> Bjam is much, much better than is generally appreciated. Its' just that
> the designers were/are too clever and presume we are also.

I've just returned from holiday to plough through all this discussion :-( I wish I hadn't!

It feels like there are two groups, one with a spanner who think everything is a nut, and another group with loads of hammers, and
think everything is a nail.

The hammers are made of plastic, and the spanners are adjustable, but come without a manual.

I have been pleading and begging for much more *effective* documentation with far more examples for bjam and the build system for
15 years, and still believe that this is root cause of the current mess.

(The daft syntax, incomprehensible error messages, and failure to deal with windows file names with spaces also factors).

I use two IDE, VS and CodeBlocks and using Boost header-only is entirely painless. Quite why there is so much opposition, I find
difficult to understand. Libraries are much, much more troublesome, and I very much like auto-linking. Sadly, there are a few
essential libraries like system, chrono, filesystem and test that work nicer with libraries, so I can see how people need more than
Boost header-only.

So personally, I am now fairly happy using bjam/b2, after years of swearing and gnashing of teeth.
Compared to the creators, I'm oligoneuronic (just like most users), but the real cause was nearly all a massive communication
failure. The documentation just does not work.

(And, if I am honest, I just wanted not to need to know so much, especially when it didn't Just Work, as promised. The torrent of
plaintive emails on Stackoverflow and Boost say that I am not alone. I'd like to live in the blissful ignorance that Daniela's team
enjoy.)

If a cmake that called b2 to install would make cmake_2.5_rs happy, I think this might be a good first step, but only a feeble
band-aid.

I fear we are about to get into a similar mess with ill-documented cmake 3.5, especially with an army of 2.5 mindset users.
Personally, I don't wish to know about cmake - my brain is full ;-)

I'm encouraged by Niall producing a working cmake 3.5 example - it even includes some comments explaining what is happening !

But it's doing the whole of Boost that is the elephant. For example, there are 591 files in boost/math/test and hundreds of tests
in each file. The jamfile is not just a simple list of targets to build and run, there are many options and variants, depending on
many Boost and several external libraries. So there is a BIG mountain ahead...

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]






















_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Edward Diener via Boost]

On 6/22/2017 7:06 AM, Paul A. Bristow via Boost wrote:
>
>
>> -----Original Message-----
>> From: Boost [mailto:boost-***@lists.boost.org] On Behalf Of Robert Ramey via Boost
>> Sent: 21 June 2017 16:23
>> To: Chris Glover via Boost
>> Cc: Robert Ramey
>> Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
>>
>> On 6/21/17 6:47 AM, Chris Glover via Boost wrote:
>>> On Wed, 21 Jun 2017 at 04:01 Thomas Heller via Boost <***@lists.boost.org>
>>> wrote:
>>>
>>>>
>>>> Interesting that you bring this up ... If you are so much in favor of a
>>>> declarative build system, we already have multiple. For example plain
>>>> old make or Boost.Build. With that being said, wouldn't it be more
>>>> viable to improve Boost.Build with:
>>>> - Better Documentation
>>>> - More examples
>>
>> Boost build has been hampered by a number of design decisions which have
>> never been revisited.
>
> <snip>
>
>> Of course this would be coupled with the manual which would describe
>> this stuff. Actually, the text for this stuff is already in boost build
>> docs. It's just that no one knows what part he needs to read to get it
>> right. So compiling this document and code reorganization to support
>> the above would have to go hand in hand.
>>
>> Bjam is much, much better than is generally appreciated. Its' just that
>> the designers were/are too clever and presume we are also.
>
> I've just returned from holiday to plough through all this discussion :-( I wish I hadn't!
>
> It feels like there are two groups, one with a spanner who think everything is a nut, and another group with loads of hammers, and
> think everything is a nail.
>
> The hammers are made of plastic, and the spanners are adjustable, but come without a manual.
>
> I have been pleading and begging for much more *effective* documentation with far more examples for bjam and the build system for
> 15 years, and still believe that this is root cause of the current mess.
>
> (The daft syntax, incomprehensible error messages, and failure to deal with windows file names with spaces also factors).
>
> I use two IDE, VS and CodeBlocks and using Boost header-only is entirely painless. Quite why there is so much opposition, I find
> difficult to understand. Libraries are much, much more troublesome, and I very much like auto-linking. Sadly, there are a few
> essential libraries like system, chrono, filesystem and test that work nicer with libraries, so I can see how people need more than
> Boost header-only.
>
> So personally, I am now fairly happy using bjam/b2, after years of swearing and gnashing of teeth.
> Compared to the creators, I'm oligoneuronic

No definition in my "Webster's Third New International Dictionary", I
don't have the OED, don't recall the word in literature, find only
'Oligoneuron' on the web about a genus of flowering plants, so a
definition would be appreciated as my own neurons are not firing enough
connections to understand it. Perhaps it means an oligarchy of neurons,
whatever that is supposed to be.

> (just like most users), but the real cause was nearly all a massive communication
> failure. The documentation just does not work.

I tend to agree but on the basis that the Boost Build doc probably has
most everything but not organized in ways that the C++ programmer can
easily understand.

>
> (And, if I am honest, I just wanted not to need to know so much, especially when it didn't Just Work, as promised. The torrent of
> plaintive emails on Stackoverflow and Boost say that I am not alone. I'd like to live in the blissful ignorance that Daniela's team
> enjoy.)
>
> If a cmake that called b2 to install would make cmake_2.5_rs happy, I think this might be a good first step, but only a feeble
> band-aid.
>
> I fear we are about to get into a similar mess with ill-documented cmake 3.5, especially with an army of 2.5 mindset users.
> Personally, I don't wish to know about cmake - my brain is full ;-)

rotfl

>
> I'm encouraged by Niall producing a working cmake 3.5 example - it even includes some comments explaining what is happening !
>
> But it's doing the whole of Boost that is the elephant. For example, there are 591 files in boost/math/test and hundreds of tests
> in each file. The jamfile is not just a simple list of targets to build and run, there are many options and variants, depending on
> many Boost and several external libraries. So there is a BIG mountain ahead...

+1

What I am really afraid of is not that Boost end-users do not like
CMake, because obviously most programmers appear to love it, but that
Boost will just be substituting one build system under its own control,
which few really understand, for another build system controlled
elsewhere, which more evidently understand but whose usage even more
people disagree about.

However if we can provide CMake for end-users from our bjam files,
without tortuous work, I am all for it as long as I personally don't
have to understand it. I find reading the CMake docs, such as they are,
much more incomprehensible than the Boost Build docs.

>
> Paul
>
> ---
> Paul A. Bristow
> Prizet Farmhouse
> Kendal UK LA8 8AB
> [phone]


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Paul A. Bristow via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-***@lists.boost.org] On Behalf Of Edward Diener via Boost
> Sent: 22 June 2017 17:05
> To: ***@lists.boost.org
> Cc: Edward Diener
> Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
>
> On 6/22/2017 7:06 AM, Paul A. Bristow via Boost wrote:
> >
> >
> >> -----Original Message-----
> >> From: Boost [mailto:boost-***@lists.boost.org] On Behalf Of Robert Ramey via Boost
> >> Sent: 21 June 2017 16:23
> >> To: Chris Glover via Boost
> >> Cc: Robert Ramey
> >> Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
<snip>

> > So personally, I am now fairly happy using bjam/b2, after years of swearing and gnashing of teeth.
> > Compared to the creators, I'm oligoneuronic
>
> No definition in my "Webster's Third New International Dictionary", I
> don't have the OED, don't recall the word in literature, find only
> 'Oligoneuron' on the web about a genus of flowering plants, so a
> definition would be appreciated as my own neurons are not firing enough
> connections to understand it. Perhaps it means an oligarchy of neurons,
> whatever that is supposed to be.

OK - I confess - made that up ;-)

oligo - few

neuronic - neurons

(with the benefit of dimly remembered Latin - I was extruded forcibly though O level by my Mother who had a Classics degree -
oligarchy - rule by a few people, and chemistry - oligomers - polymers with a few mers)

But it seems a useful term of (self-)abuse?

> What I am really afraid of is not that Boost end-users do not like
> CMake, because obviously most programmers appear to love it, but that
> Boost will just be substituting one build system under its own control,
> which few really understand, for another build system controlled
> elsewhere, which more evidently understand but whose usage even more
> people disagree about.

+1

> However if we can provide CMake for end-users from our bjam files,
> without tortuous work, I am all for it as long as I personally don't
> have to understand it. I find reading the CMake docs, such as they are,
> much more incomprehensible than the Boost Build docs.

What should I be reading?

https://cmake.org/cmake/help/v3.9/ dumps me in at the deep end and leaves me at "Huh?"

should I invest in

Mastering CMake Paperback - January 16, 2015 by Ken Martin (Author), Bill Hoffman (Author) $50

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov via Boost]

Paul A. Bristow wrote:
> OK - I confess - made that up ;-)
>
> oligo - few
>
> neuronic - neurons
>
> (with the benefit of dimly remembered Latin - I was extruded forcibly
> though O level by my Mother who had a Classics degree - oligarchy - rule
> by a few people, and chemistry - oligomers - polymers with a few mers)

cf. oligophrenia


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Edward Diener via Boost]

On 6/22/2017 12:35 PM, Paul A. Bristow via Boost wrote:
>> -----Original Message-----
>> From: Boost [mailto:boost-***@lists.boost.org] On Behalf Of Edward Diener via Boost
>> Sent: 22 June 2017 17:05
>> To: ***@lists.boost.org
>> Cc: Edward Diener
>> Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
>>
>> On 6/22/2017 7:06 AM, Paul A. Bristow via Boost wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Boost [mailto:boost-***@lists.boost.org] On Behalf Of Robert Ramey via Boost
>>>> Sent: 21 June 2017 16:23
>>>> To: Chris Glover via Boost
>>>> Cc: Robert Ramey
>>>> Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
> <snip>
>
>>> So personally, I am now fairly happy using bjam/b2, after years of swearing and gnashing of teeth.
>>> Compared to the creators, I'm oligoneuronic
>>
>> No definition in my "Webster's Third New International Dictionary", I
>> don't have the OED, don't recall the word in literature, find only
>> 'Oligoneuron' on the web about a genus of flowering plants, so a
>> definition would be appreciated as my own neurons are not firing enough
>> connections to understand it. Perhaps it means an oligarchy of neurons,
>> whatever that is supposed to be.
>
> OK - I confess - made that up ;-)

I suspected that <g>.

>
> oligo - few
>
> neuronic - neurons
>
> (with the benefit of dimly remembered Latin - I was extruded forcibly though O level by my Mother who had a Classics degree -
> oligarchy - rule by a few people, and chemistry - oligomers - polymers with a few mers)

Well 'oligo' is Greek, not that I know Greek. I did take Latin also in
an American prep school, but I do not remember very much any more. A
prep school in the US is a private school, since in Britain I believe
the terminology is different.

>
> But it seems a useful term of (self-)abuse?
>
>> What I am really afraid of is not that Boost end-users do not like
>> CMake, because obviously most programmers appear to love it, but that
>> Boost will just be substituting one build system under its own control,
>> which few really understand, for another build system controlled
>> elsewhere, which more evidently understand but whose usage even more
>> people disagree about.
>
> +1
>
>> However if we can provide CMake for end-users from our bjam files,
>> without tortuous work, I am all for it as long as I personally don't
>> have to understand it. I find reading the CMake docs, such as they are,
>> much more incomprehensible than the Boost Build docs.
>
> What should I be reading?
>
> https://cmake.org/cmake/help/v3.9/ dumps me in at the deep end and leaves me at "Huh?"

I have the exact same reaction.

>
> should I invest in
>
> Mastering CMake Paperback - January 16, 2015 by Ken Martin (Author), Bill Hoffman (Author) $50
>
> Paul
>
> ---
> Paul A. Bristow
> Prizet Farmhouse
> Kendal UK LA8 8AB
> [phone]


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[paul via Boost]

On Thu, 2017-06-22 at 17:35 +0100, Paul A. Bristow via Boost wrote:
> >
> > -----Original Message-----
> > From: Boost [mailto:boost-***@lists.boost.org] On Behalf Of Edward
> > Diener via Boost
> > Sent: 22 June 2017 17:05
> > To: ***@lists.boost.org
> > Cc: Edward Diener
> > Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
> >
> > On 6/22/2017 7:06 AM, Paul A. Bristow via Boost wrote:
> > >
> > >
> > >
> > > >
> > > > -----Original Message-----
> > > > From: Boost [mailto:boost-***@lists.boost.org] On Behalf Of Robert
> > > > Ramey via Boost
> > > > Sent: 21 June 2017 16:23
> > > > To: Chris Glover via Boost
> > > > Cc: Robert Ramey
> > > > Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
> <snip>
>
> >
> > >
> > > So personally, I am now fairly happy using bjam/b2, after years of
> > > swearing and gnashing of teeth.
> > > Compared to the creators, I'm oligoneuronic
> > No definition in my "Webster's Third New International Dictionary", I
> > don't have the OED, don't recall the word in literature, find only
> > 'Oligoneuron' on the web about a genus of flowering plants, so a
> > definition would be appreciated as my own neurons are not firing enough
> > connections to understand it. Perhaps it means an oligarchy of neurons,
> > whatever that is supposed to be.
> OK - I confess - made that up ;-)
>
> oligo - few
>
> neuronic - neurons
>
> (with the benefit of dimly remembered Latin - I was extruded forcibly though
> O level by my Mother who had a Classics degree -
> oligarchy - rule by a few people, and chemistry - oligomers - polymers with
> a few mers)
>
> But it seems a useful term of (self-)abuse? 
>
> >
> > What I am really afraid of is not that Boost end-users do not like
> > CMake, because obviously most programmers appear to love it, but that
> > Boost will just be substituting one build system under its own control,
> > which few really understand, for another build system controlled
> > elsewhere, which more evidently understand but whose usage even more
> > people disagree about.
> +1
>  
> >
> > However if we can provide CMake for end-users from our bjam files,
> > without tortuous work, I am all for it as long as I personally don't
> > have to understand it. I find reading the CMake docs, such as they are,
> > much more incomprehensible than the Boost Build docs.
> What should I be reading?
>
> https://cmake.org/cmake/help/v3.9/ dumps me in at the deep end and leaves me
> at "Huh?"
>
> should I invest in
>
> Mastering CMake Paperback - January 16, 2015 by Ken Martin (Author), Bill
> Hoffman (Author) $50

There is this:

https://cmake.org/cmake-tutorial/



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mai

[Edward Diener via Boost]

On 6/22/2017 1:18 PM, paul via Boost wrote:
> On Thu, 2017-06-22 at 17:35 +0100, Paul A. Bristow via Boost wrote:
>>>
>>> -----Original Message-----
>>> From: Boost [mailto:boost-***@lists.boost.org] On Behalf Of Edward
>>> Diener via Boost
>>> Sent: 22 June 2017 17:05
>>> To: ***@lists.boost.org
>>> Cc: Edward Diener
>>> Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
>>>
>>> On 6/22/2017 7:06 AM, Paul A. Bristow via Boost wrote:
>>>>
>>>>
>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Boost [mailto:boost-***@lists.boost.org] On Behalf Of Robert
>>>>> Ramey via Boost
>>>>> Sent: 21 June 2017 16:23
>>>>> To: Chris Glover via Boost
>>>>> Cc: Robert Ramey
>>>>> Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
>> <snip>
>>
>>>
>>>>
>>>> So personally, I am now fairly happy using bjam/b2, after years of
>>>> swearing and gnashing of teeth.
>>>> Compared to the creators, I'm oligoneuronic
>>> No definition in my "Webster's Third New International Dictionary", I
>>> don't have the OED, don't recall the word in literature, find only
>>> 'Oligoneuron' on the web about a genus of flowering plants, so a
>>> definition would be appreciated as my own neurons are not firing enough
>>> connections to understand it. Perhaps it means an oligarchy of neurons,
>>> whatever that is supposed to be.
>> OK - I confess - made that up ;-)
>>
>> oligo - few
>>
>> neuronic - neurons
>>
>> (with the benefit of dimly remembered Latin - I was extruded forcibly though
>> O level by my Mother who had a Classics degree -
>> oligarchy - rule by a few people, and chemistry - oligomers - polymers with
>> a few mers)
>>
>> But it seems a useful term of (self-)abuse?
>>
>>>
>>> What I am really afraid of is not that Boost end-users do not like
>>> CMake, because obviously most programmers appear to love it, but that
>>> Boost will just be substituting one build system under its own control,
>>> which few really understand, for another build system controlled
>>> elsewhere, which more evidently understand but whose usage even more
>>> people disagree about.
>> +1
>>
>>>
>>> However if we can provide CMake for end-users from our bjam files,
>>> without tortuous work, I am all for it as long as I personally don't
>>> have to understand it. I find reading the CMake docs, such as they are,
>>> much more incomprehensible than the Boost Build docs.
>> What should I be reading?
>>
>> https://cmake.org/cmake/help/v3.9/ dumps me in at the deep end and leaves me
>> at "Huh?"
>>
>> should I invest in
>>
>> Mastering CMake Paperback - January 16, 2015 by Ken Martin (Author), Bill
>> Hoffman (Author) $50
>
> There is this:
>
> https://cmake.org/cmake-tutorial/

I am one of those people who find tutorials a completely hopeless way
for me to understand any piece of software. I will buy some book
instead, but I really want CMake to actually provide documentation which
gives me a thorough overview of how CMake works and explains the
parts/concepts of CMake as part of this overview. The style of
documentation which so many people employ and so many people seem to
love, a tutorial and then a mass of largely undifferentiated detail,
makes me nauseous.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stefan Seefeld via Boost]

On 22.06.2017 12:04, Edward Diener via Boost wrote:
>
> What I am really afraid of is not that Boost end-users do not like
> CMake, because obviously most programmers appear to love it, but that
> Boost will just be substituting one build system under its own
> control, which few really understand, for another build system
> controlled elsewhere, which more evidently understand but whose usage
> even more people disagree about.

Exactly. The Fact that we are having this discussion is ample
demonstration that a move to "idiomatic" CMake is not a good idea, at
least not for the stated reason.

And to add that: Being among those who complained about the existing
build system, as I'm unable to fix related issues when people file
Boost.Python issues that are about its build logic, I'd love to move to
a system that *I* understand and can help fix. But CMake is not that, so
I'm not supportive of the move.

> However if we can provide CMake for end-users from our bjam files,
> without tortuous work, I am all for it as long as I personally don't
> have to understand it.

Really ? What about those end users who submit bug reports (to your
library) originating from issues they encounter with cmake ? How will
you support them ?

Stefan

--

...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Edward Diener via Boost]

On 6/22/2017 1:04 PM, Stefan Seefeld via Boost wrote:
> On 22.06.2017 12:04, Edward Diener via Boost wrote:
>>
>> What I am really afraid of is not that Boost end-users do not like
>> CMake, because obviously most programmers appear to love it, but that
>> Boost will just be substituting one build system under its own
>> control, which few really understand, for another build system
>> controlled elsewhere, which more evidently understand but whose usage
>> even more people disagree about.
>
> Exactly. The Fact that we are having this discussion is ample
> demonstration that a move to "idiomatic" CMake is not a good idea, at
> least not for the stated reason.
>
> And to add that: Being among those who complained about the existing
> build system, as I'm unable to fix related issues when people file
> Boost.Python issues that are about its build logic, I'd love to move to
> a system that *I* understand and can help fix. But CMake is not that, so
> I'm not supportive of the move.
>
>> However if we can provide CMake for end-users from our bjam files,
>> without tortuous work, I am all for it as long as I personally don't
>> have to understand it.
>
> Really ? What about those end users who submit bug reports (to your
> library) originating from issues they encounter with cmake ? How will
> you support them ?

Punt ? <g>

I am assuming that any conversion of my library's bjam code to CMake
should "just work", ie. there is somne sort of conversion facility ( or
easy recipe ) from bjam to CMake that I can just run each time I make a
change to the bjam files. If that is not the case, and I am expected to
manually change CMake each time, I probably will not like such CMake
support for end-users.

>
> Stefan
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stefan Seefeld via Boost]

On 22.06.2017 13:52, Edward Diener via Boost wrote:
> I am assuming that any conversion of my library's bjam code to CMake
> should "just work",

haha !

> ie. there is somne sort of conversion facility ( or easy recipe ) from
> bjam to CMake that I can just run each time I make a change to the
> bjam files. If that is not the case, and I am expected to manually
> change CMake each time, I probably will not like such CMake support
> for end-users.

What I'm worrying about isn't so much whether any bjam->cmake conversion
can be automated or not, but how I will be able to help end-uses who
report error messages stemming from cmake. They will be as cryptic to me
as the b2 error messages, and require me to run the very command the end
user was using to attempt to reproduce and fix the issue. In other
words, it would require me to debug the cmake-based build system, not
the original one this was created from.

Don't fool yourself: whatever build system you hand your users, you
better be comfortable with yourself.

Stefan

--

...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[paul via Boost]

On Thu, 2017-06-22 at 12:06 +0100, Paul A. Bristow via Boost wrote:
>
> >
> > -----Original Message-----
> > From: Boost [mailto:boost-***@lists.boost.org] On Behalf Of Robert
> > Ramey via Boost
> > Sent: 21 June 2017 16:23
> > To: Chris Glover via Boost
> > Cc: Robert Ramey
> > Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
> >
> > On 6/21/17 6:47 AM, Chris Glover via Boost wrote:
> > >
> > > On Wed, 21 Jun 2017 at 04:01 Thomas Heller via Boost <***@lists.boost.
> > > org>
> > > wrote:
> > >
> > > >
> > > >
> > > > Interesting that you bring this up ... If you are so much in favor of
> > > > a
> > > > declarative build system, we already have multiple. For example plain
> > > > old make or Boost.Build. With that being said, wouldn't it be more
> > > > viable to improve Boost.Build with:
> > > >    - Better Documentation
> > > >    - More examples
> > Boost build has been hampered by a number of design decisions which have
> > never been revisited.
> <snip>
>  
> >
> > Of course this would be coupled with the manual which would describe
> > this stuff.  Actually, the text for this stuff is already in boost build
> > docs.  It's just that no one knows what part he needs to read to get it
> > right.  So compiling this document and code reorganization to support
> > the above would have to go hand in hand.
> >
> > Bjam is much, much better than is generally appreciated.  Its' just that
> > the designers were/are too clever and presume we are also.
> I've just returned from holiday to plough through all this discussion :-
> (    I wish I hadn't!
>
> It feels like there are two groups, one with a spanner who think everything
> is a nut, and another group with loads of hammers, and
> think everything is a nail.
>
> The hammers are made of plastic, and the spanners are adjustable, but come
> without a manual.
>
> I have been pleading and begging for much more *effective* documentation
> with far more examples for bjam  and the build system for
> 15 years, and still believe that this is root cause of the current mess.

Yes, that is why moving to cmake which has a larger community that already
provides lots of these materials. Plus, we can get support from this larger
community to help improve boost build infrastructure.

>
>  (The daft syntax, incomprehensible error messages, and failure to deal with
> windows file names with spaces also factors).

And after users spend many hours debugging these issues, they usually
abanonded it:

https://github.com/boostorg/build/issues/106

>
> I use two IDE, VS and CodeBlocks and using Boost header-only is entirely
> painless. Quite why there is so much opposition, I find
> difficult to understand. Libraries are much, much more troublesome, and I
> very much like auto-linking.  Sadly, there are a few
> essential libraries like system, chrono, filesystem and test that work nicer
> with libraries, so I can see how people need more than
> Boost header-only.
>
> So personally, I am now fairly happy using bjam/b2, after years of swearing
> and gnashing of teeth. 
> Compared to the creators, I'm oligoneuronic (just like most users), but the
> real cause was nearly all a massive communication
> failure.  The documentation just does not work.
>
> (And, if I am honest, I just wanted not to need to know so much, especially
> when it didn't Just Work, as promised.  The torrent of
> plaintive emails on Stackoverflow and Boost say that I am not alone. I'd
> like to live in the blissful ignorance that Daniela's team
> enjoy.)
>
> If a cmake that called b2 to install would make cmake_2.5_rs happy, I think
> this might be a good first step, but only a feeble
> band-aid.
>
> I fear we are about to get into a similar mess with ill-documented cmake 3.5

Daniel Pfeifer's "Effective CMake" does a wonderful job explaining cmake and
how to stucture it:

https://www.youtube.com/watch?v=bsXLMQ6WgIk

I also put together a wiki that goes over the best practices and guidelines:

https://github.com/boost-cmake/bcm/wiki/Cmake-best-practices-and-guidelines

> , especially with an army of 2.5 mindset users.

What army of cmake 2.5 users? I don't see anyone advocating for cmake 2.8
style of cmake.

> Personally, I don't wish to know about cmake - my brain is full ;-)
>
> I'm encouraged by Niall producing a working cmake 3.5 example - it even
> includes some comments explaining what is happening !

There is also my example, which follows the "effective cmake" structure:

https://github.com/pfultz2/boost-cmake-demo

It also supports both the `add_subdirectory` and `find_package` workflow,
something that Niall's example does not.

>
> But it's doing the whole of Boost that is the elephant.  For example, there
> are 591 files in boost/math/test and hundreds of tests
> in each file.  The jamfile is not just a simple list of targets to build and
> run, there are many options and variants, depending on
> many Boost and several external libraries.  So there is a BIG mountain
> ahead...

There are the tests. For some libraries they are simple to add, for others,
they are more complicated. There really should be a look at the testing
infrastrucutre as well.



_______________________________________________
Unsubscribe & other chang

[Peter Dimov via Boost]

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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Heller via Boost]

Am 20.06.2017 4:21 nachm. schrieb "Peter Dimov via Boost" <
***@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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.or

[P F via Boost]

> On Jun 20, 2017, at 9:20 AM, Peter Dimov via Boost <***@lists.boost.org> wrote:
>
> 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.

But Daniel Pfeifer’s presentations go over more than use target_*.

>
> 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.

Yes, in fact, with BCM it was written like this:

bcm_boost_package(core
VERSION 1.61.0
DEPENDS
assert
config
)

So its very declarative, however, using custom functions like this is discouraged. So, I am planning to at least refactor it to say:

add_library(boost_core INTERFACE)
bcm_boost_depends(boost_core INTERFACE boost::assert boost::config)

And it can take care of calling find_package and linking. Plus, this looks more cmakey.

Although, I think the trend with cmake is moving away from subproject builds and towards standalone builds. This is why it supports exporting its targets so it can be consumed after installation.

>
> 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.

A library may want to compile differently if a dependency isn't there, or even use completly different set of dependencies, which is best expressed imperatively the declaratively.

> So we get "best practice" hacks like redefining find_package. I'm sorry, this doesn't feel right.

Redefining `find_package` is one way. Another way is to provide Find modules that override the behavior as well. Cmake also provides a `CMAKE_DISABLE_FIND_PACKAGE_<PackageName>` to disable certain packages, but its really only for optional dependencies. Ideally, there should be way in cmake to skip over these packages, that is to tell cmake that the package was already provided by another project in the build. For now, the easiest way, is overloading `find_package`.




_______________________________________________
Unsubscribe & other changes: http://list

[Niall Douglas via Boost]

On 20/06/2017 15:55, P F via Boost wrote:
>
>> On Jun 20, 2017, at 9:20 AM, Peter Dimov via Boost
>> <***@lists.boost.org> wrote:
>>
>> 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.
>
> But Daniel Pfeifer’s presentations go over more than use target_*.

He was also addressing an audience with existing legacy cmake systems.
If you are in the very fortunate position of starting from a completely
clean sheet like we are, you'd do differently.

You know you could just drop Daniel a line and ask for a bit of his
time. He used to be on boost-dev, indeed he and I and Dave worked on the
git conversion.

> Although, I think the trend with cmake is moving away from subproject
> builds and towards standalone builds. This is why it supports
> exporting its targets so it can be consumed after installation.

That trend exists only because so much existing cmake is a very bad
neighbour to other cmake, so you need to ring fence cmake-innovations
away from one another as they trample on one another.

Purely declarative cmake examines no global state and so isn't affected
by other people's modifications of global state. It also changes no
global state, so it is always a good neighbour. Therefore, unlike most
existing cmake, it is always safe to use in subproject builds.

I again reiterate that nobody is stopping anyone writing their own
installation logic in a rootlevel CMakeLists. You can go ahead and
implement target export and anything else you like on your own if that's
what suits you.

But most will simply do subproject builds. It's painfree and works
without surprises on Windows. It also inherits the consumer's
optimisation and build settings. End users will be delighted.

>> 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.
>
> A library may want to compile differently if a dependency isn't
> there, or even use completly different set of dependencies, which is
> best expressed imperatively the declaratively.

You declare alternative targets for those situations and leave the
rootlevel CMakeLists decide what is wanted. Non-rootlevel CMakeLists
cannot be enforcing choices of how to best detect presence of
dependencies on end users, they might have a custom build of some
dependency in a custom path for example.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost

[paul via Boost]

On Tue, 2017-06-20 at 16:51 +0100, Niall Douglas via Boost wrote:
> On 20/06/2017 15:55, P F via Boost wrote:
> >
> >
> > >
> > > On Jun 20, 2017, at 9:20 AM, Peter Dimov via Boost
> > > <***@lists.boost.org> wrote:
> > >
> > > 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.
> > But Daniel Pfeifer’s presentations go over more than use target_*.
> He was also addressing an audience with existing legacy cmake systems.
> If you are in the very fortunate position of starting from a completely
> clean sheet like we are, you'd do differently.

I am not sure who he is addressing, but what he suggest is how you should
write cmake period. He never discussed any of things you are doing in his
talk.

>
> You know you could just drop Daniel a line and ask for a bit of his
> time. He used to be on boost-dev, indeed he and I and Dave worked on the
> git conversion.

Actually, a lot of what I wrote follow very closely follows to how he wrote it
here:

https://github.com/boost-cmake/boost-cmake/blob/master/listsfiles/libs/system/
CMakeLists.txt

And this relies on `BUILD_SHARED_LIBS`.

>
> >
> > Although, I think the trend with cmake is moving away from subproject
> > builds and towards standalone builds. This is why it supports
> > exporting its targets so it can be consumed after installation.
> That trend exists only

The trend exists because this is what works for large-scale building,
especially for 10000+ libraries.

> because so much existing cmake is a very bad
> neighbour to other cmake, so you need to ring fence cmake-innovations
> away from one another as they trample on one another.

But what you are suggesting will be a bad neighbor. As I will not be able to
build a library standalone. 

>
> Purely declarative cmake examines no global state and so isn't affected
> by other people's modifications of global state.

None of my project examine global state, whereas your example does by
inspecting the existenct of targets, which is global state.

> It also changes no
> global state, so it is always a good neighbour. Therefore, unlike most
> existing cmake, it is always safe to use in subproject builds.

Yes, and what I presented does this.

>
> I again reiterate that nobody is stopping anyone writing their own
> installation logic in a rootlevel CMakeLists.

But that doesn't make the project work standalone, which is an important best
practice for cmake.

> You can go ahead and
> implement target export and anything else you like on your own if that's
> what suits you.
>
> But most will simply do subproject builds.

I don't know about most. Most places I worked at built and installed boost,
even on windows.

> It's painfree and works
> without surprises on Windows.

I have found no problems using `find_package` on windows.

> It also inherits the consumer's
> optimisation and build settings. End users will be delighted.

I don't think so when we say you must use boost as `add_subdirectory` and if
you want to use `find_package` you are own your own. A lot of cmake users want
the `find_package` support. 

Ultimately, we need to support both scenarios, what I presented does that. You
can use it as `add_sudirectory`, you can build each project standalone, and
you can use `find_package`. What you presented doesn't do those.

>
> >
> > >
> > > 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.
> > A library may want to compile differently if a dependency isn't
> > there, or even use completly different set of dependencies, which is
> > best expressed imperatively the declaratively.
> You declare alternative targets for those situations and leave the
> rootlevel CMakeLists decide what is wanted. Non-rootlevel CMakeLists
> cannot be enforcing choices of how to best detect presence of
> dependencies on end users,

Using `find_package` doesn't as it is up to the clients to decide how it will
find the dependencies through `CMAKE_PREFIX_PATH` and `<package>_DIR`
variables that can be defined by the clients.

> they might have a custom build of some
> dependency in a custom path for example.

Yes, which is what `mylib_DIR` is for.

>
> Niall
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mai

[Peter Dimov via Boost]

paul wrote:

> The trend exists because this is what works for large-scale building,
> especially for 10000+ libraries.

This is what works when your build system is deficient, so it takes it a few
hours to see that 9999 libraries haven't changed. Large-scale building done
right is called Ninja.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[paul via Boost]

On Tue, 2017-06-20 at 20:26 +0300, Peter Dimov via Boost wrote:
> paul wrote:
>
> >
> > The trend exists because this is what works for large-scale building, 
> > especially for 10000+ libraries.
> This is what works when your build system is deficient, so it takes it a
> few 
> hours to see that 9999 libraries haven't changed. Large-scale building done 
> right is called Ninja.

At 10000+ you are dealing with at least 5 different buildsystems: autotools,
cmake, b2, meson, and qmake. Its not feasible to maintain build scripts for
10000 dependencies. Nor is it reasonable to rebuild the same dependencies for
every project.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailm

[Peter Dimov via Boost]

paul wrote:

> At 10000+ you are dealing with at least 5 different buildsystems:
> autotools, cmake, b2, meson, and qmake.

Absolutely not. Everyone on this scale builds everything with a single
(usually in-house) build system. The alternative is completely
unmaintainable, and errors are irreproducible.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[paul via Boost]

On Tue, 2017-06-20 at 20:58 +0300, Peter Dimov via Boost wrote:
> paul wrote:
>
> >
> > At 10000+ you are dealing with at least 5 different buildsystems: 
> > autotools, cmake, b2, meson, and qmake.
> Absolutely not. Everyone on this scale builds everything with a single 
> (usually in-house) build system.

I have not worked at a place that used a single build system. Nor do distros
build like that. I am not saying it isn't done, just that it is not so common
as you say.

> The alternative is completely 
> unmaintainable,

Well, I guess I should switch from my "unmaintainable" OS to windows.

> and errors are irreproducible. 

This has not been my experience. I have found "irreproducible" errors(ie it
shows on one machine but not the other), but this was due to differnt kernel
versions, which a single in-house build would've not fixed or helped either.

Furthermore, tools like conan provide reproducible builds, but does not use a
single build system either. So I dont think a single build system is always
required for reproducible builds.


_______________________________________________
Unsubscribe & other changes:

[Peter Dimov via Boost]

paul wrote:
> On Tue, 2017-06-20 at 20:58 +0300, Peter Dimov via Boost wrote:
> > paul wrote:
> >
> > >
> > > At 10000+ you are dealing with at least 5 different buildsystems:
> > > autotools, cmake, b2, meson, and qmake.
> >
> > Absolutely not. Everyone on this scale builds everything with a single
> > (usually in-house) build system.
>
> I have not worked at a place that used a single build system. Nor do
> distros build like that.

Ah, we're talking about different things then. You're talking about building
and shipping 10,000 libraries. I thought we're talking about building a
project with 10,000 dependencies.

> Well, I guess I should switch from my "unmaintainable" OS to windows.

That's just nonsense. The OS doesn't matter.

> > and errors are irreproducible.
>
> This has not been my experience. I have found "irreproducible" errors(ie
> it shows on one machine but not the other), but this was due to differnt
> kernel versions, which a single in-house build would've not fixed or
> helped either.

Reproducible here refers to you get a bug report about build number 49121,
but you're already on 56192 internally. You need to be able to rewind back
to 49121. The entire state of the project is a unit, you can't treat
dependencies as their own separate kingdoms which you build, "install", and
forget about.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[paul via Boost]

On Tue, 2017-06-20 at 21:58 +0300, Peter Dimov via Boost wrote:
> paul wrote:
> >
> > On Tue, 2017-06-20 at 20:58 +0300, Peter Dimov via Boost wrote:
> > >
> > > paul wrote:
> > >
> > > >
> > > >
> > > > At 10000+ you are dealing with at least 5 different buildsystems: 
> > > > autotools, cmake, b2, meson, and qmake.
> > > Absolutely not. Everyone on this scale builds everything with a single 
> > > (usually in-house) build system.
> > I have not worked at a place that used a single build system. Nor do 
> > distros build like that.
> Ah, we're talking about different things then. You're talking about
> building 
> and shipping 10,000 libraries. I thought we're talking about building a 
> project with 10,000 dependencies.

Well, of course, projects are work on, I need to ship them.

>
> >
> > Well, I guess I should switch from my "unmaintainable" OS to windows.
> That's just nonsense. The OS doesn't matter.

My OS is a large-scale build, which does not use a single build system.

>
> >
> > >
> > > and errors are irreproducible.
> > This has not been my experience. I have found "irreproducible" errors(ie 
> > it shows on one machine but not the other), but this was due to differnt 
> > kernel versions, which a single in-house build would've not fixed or 
> > helped either.
> Reproducible here refers to you get a bug report about build number 49121, 
> but you're already on 56192 internally. You need to be able to rewind back 
> to 49121. The entire state of the project is a unit, you can't treat 
> dependencies as their own separate kingdoms which you build, "install", and 
> forget about. 

If the dependencies are different between build 49121 and 56192, I would've
update CI scripts in the repo with the different requirements. Otherwise the
CI has no idea how to build it correctly. When I rollback to 49121, I just use
the CI scripts for that commit.



_______________________________________________
Unsubscribe & other changes: http://lis

[Peter Dimov via Boost]

paul wrote:

> My OS is a large-scale build, which does not use a single build system.

Good. I don't have an OS, so I can't relate.

> > Reproducible here refers to you get a bug report about build number
> > 49121, but you're already on 56192 internally. You need to be able to
> > rewind back to 49121. The entire state of the project is a unit, you
> > can't treat dependencies as their own separate kingdoms which you build,
> > "install", and forget about.
>
> If the dependencies are different between build 49121 and 56192, I
> would've update CI scripts in the repo with the different requirements.
> Otherwise the CI has no idea how to build it correctly. When I rollback to
> 49121, I just use the CI scripts for that commit.

It's not entirely clear to me how just using the CI scripts for that commit
would give you the build for that commit. The point of the install model is
that the build of the project doesn't rebuild the dependencies, it uses the
prebuilt ones.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[paul via Boost]

On Tue, 2017-06-20 at 22:38 +0300, Peter Dimov via Boost wrote:
> paul wrote:
>
> >
> > My OS is a large-scale build, which does not use a single build system.
> Good. I don't have an OS, so I can't relate.
>
> >
> > >
> > > Reproducible here refers to you get a bug report about build number 
> > > 49121, but you're already on 56192 internally. You need to be able to 
> > > rewind back to 49121. The entire state of the project is a unit, you 
> > > can't treat dependencies as their own separate kingdoms which you
> > > build, 
> > > "install", and forget about.
> > If the dependencies are different between build 49121 and 56192, I 
> > would've update CI scripts in the repo with the different requirements. 
> > Otherwise the CI has no idea how to build it correctly. When I rollback
> > to 
> > 49121, I just use the CI scripts for that commit.
> It's not entirely clear to me how just using the CI scripts for that commit 
> would give you the build for that commit.

It gives the build environmnent to build it the same way. 

> The point of the install model is 
> that the build of the project doesn't rebuild the dependencies, it uses the 
> prebuilt ones. 

Yes, the project does use the installed dependencies, and the dependencies are
built during the setup of the build environment which of course is part of the
CI scripts, which of course is checked into source control.

>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boo
> st

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/m

[Peter Dimov via Boost]

paul wrote:

> Yes, the project does use the installed dependencies, and the dependencies
> are built during the setup of the build environment which of course is
> part of the CI scripts, which of course is checked into source control.

So it rebuilds everything from scratch? All 10,000 of it?

The alternative here is, you have build 56192 checked out and built, someone
says hey, take a look at this bug, you checkout build 49121, ./build, and
the build system reliably rebuilds everything that has changed, and doesn't
rebuild anything that hasn't, with the end result reliably being the same as
the one you would have got had you rebuilt everything from scratch.

It is no coincidence that such systems tend to come out of Google.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Niall Douglas via Boost]

On 20/06/2017 15:20, Peter Dimov via Boost wrote:
> 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.

A perfect summary. Thank you Peter.

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

[P F via Boost]

> On Jun 19, 2017, at 6:42 PM, Niall Douglas via Boost <***@lists.boost.org> wrote:
>
> I've finished the mockup which can be studied at:
>
> https://github.com/ned14/boost-bmv-cmake

So I setup a repo to build and install Boost.System as well, here:

https://github.com/pfultz2/boost-cmake-demo

This is following the best practices as explained in Daniel Pfeifer’s “Effective Cmake” talk(except the globbing subdirectories, I did that just to save time). It also very similar to the boost cmake repo written by Daniel Pfeifer and Stephen Kelley.

This example can be used to build and install modular or in the superproject. Plus, it produces the find_package files, so you can do `find_package(boost_system)`.



_______________________________________________
Unsubscribe & other ch

[Niall Douglas via Boost]

>> I've finished the mockup which can be studied at:
>>
>> https://github.com/ned14/boost-bmv-cmake
>
> So I setup a repo to build and install Boost.System as well, here:
>
> https://github.com/pfultz2/boost-cmake-demo
>
> This is following the best practices as explained in Daniel Pfeifer’s
> “Effective Cmake” talk(except the globbing subdirectories, I did that
> just to save time). It also very similar to the boost cmake repo
> written by Daniel Pfeifer and Stephen Kelley.

Half the stuff in your CMakeLists is non-mandatory configuration and can
be relocated to the rootmost CMakeLists where it belongs.

> This example can be used to build and install modular or in the
> superproject. Plus, it produces the find_package files, so you can do
> `find_package(boost_system)`.

"Installation" is non-mandatory configuration and will vary from end
user to end user. It should be implemented in the rootmost CMakeLists.
Not in library-level CMakeLists where it needlessly duplicates logic.

My bare minimum cmake actually implements the bare minimum for
installation, so it tells cmake what would need to be installed per
project and does nothing more. Rootmost CMakeLists can then do whatever
custom installation logic they choose.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinf

[Peter Dimov via Boost]

"P F" wrote:

> So I setup a repo to build and install Boost.System as well, here:
>
> https://github.com/pfultz2/boost-cmake-demo

You're listing the dependencies three times in three separate locations,
which will be error-prone and is harder to automate (unless the whole
CMakeLists.txt is generated with boostdep.)

You should be able to have dependencies.cmake with

some_macro(dep1)
some_macro(dep2)

(or some_function) and then use that appropriately in CMakeLists.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[P F via Boost]

> On Jun 20, 2017, at 7:16 AM, Peter Dimov via Boost <***@lists.boost.org> wrote:
>
> "P F" wrote:
>
>> So I setup a repo to build and install Boost.System as well, here:
>>
>> https://github.com/pfultz2/boost-cmake-demo
>
> You're listing the dependencies three times in three separate locations, which will be error-prone and is harder to automate (unless the whole CMakeLists.txt is generated with boostdep.)

I agree, which is why I wrote BCM to take care of this part. Especially, since without it, there would be another list of dependencies to support pkgconfig.

>
> You should be able to have dependencies.cmake with
>
> some_macro(dep1)
> some_macro(dep2)
>
> (or some_function) and then use that appropriately in CMakeLists.

Ideally, I can just create a list with dependencies and then iterate over them. I’ll try to add that to the repo.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/m