[boost] Moving CMake forward

[John Maddock via Boost]

Man but there's been a lot of hot air expanded on this subject.... guys
if we're going to do this, just do it. We're empiricists around here:
lets see what the proponents of CMake can come up with, yes I know there
are straw man proposals, but I want something that demonstrates it can
fully handle the complex cases at least as well as Boost.Build, and be
maintainable by CMake ignorants like myself, because lets face it, once
the transition is over, library authors will have to do the maintenance
grunt work as before: and if we can't easily see how to do that, then
the project probably fails.

As a minimal first step, what I would like to see come up for review
(yes a review folks!) is a system that:

* Provides users with a way to build those libraries with source via
CMake. All of them together, or just some subset.

* Provides an install option for all of Boost.

* Is trivially easy for non-CMakers like myself to maintain.
Documentation should be provided (Boost/CMake best practice is...).

* Is fully compatible with current auto-linking naming on Windows (plus
whatever else comes along later like address-model and architecture name
mangling that's in the works and has long been requested).

* Supports libraries with non-trivial build requirements (regex, locale,
what others?).

* Is usable by end users to be able to easily reference Boost libraries
from their own CMake projects (note, might be limited to libraries with
source, since header only libraries are kind of trivial). An example,
and how to documentation should be provided.

* It would be nice if generated VS projects were reference-able from our
own solutions as well, but I accept that may not be possible.

* Is at a minimum, no worse than what we have now.


What else?

Takers?

BTW, I don't see a need for this to encompass every Boost library with
source before some kind of mini-review to iron out the warts...

Just hoping to move things along, John.



---
This email has been checked for viruses by AVG.
http://www.avg.com


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

[Raffi Enficiaud via Boost]

Post by John Maddock via Boost
Man but there's been a lot of hot air expanded on this subject.... guys
lets see what the proponents of CMake can come up with, yes I know there
are straw man proposals, but I want something that demonstrates it can
fully handle the complex cases at least as well as Boost.Build, and be
maintainable by CMake ignorants like myself, because lets face it, once
the transition is over, library authors will have to do the maintenance
grunt work as before: and if we can't easily see how to do that, then
the project probably fails.
As a minimal first step, what I would like to see come up for review
* Provides users with a way to build those libraries with source via
CMake. All of them together, or just some subset.
* Provides an install option for all of Boost.
* Is trivially easy for non-CMakers like myself to maintain.
Documentation should be provided (Boost/CMake best practice is...).
* Is fully compatible with current auto-linking naming on Windows (plus
whatever else comes along later like address-model and architecture name
mangling that's in the works and has long been requested).
* Supports libraries with non-trivial build requirements (regex, locale,
what others?).
* Is usable by end users to be able to easily reference Boost libraries
from their own CMake projects (note, might be limited to libraries with
source, since header only libraries are kind of trivial). An example,
and how to documentation should be provided.
* It would be nice if generated VS projects were reference-able from our
own solutions as well, but I accept that may not be possible.
* Is at a minimum, no worse than what we have now.
What else?
Takers?

I am in. I have several things in mind, such as

* to work on an component that describes the dependencies between
libraries in order to add then in a topological sort order from the main
project
* port the documentation generation, focus quickbook+doxygen at first
* think/design/adapt/deploy regression runners and a possibly new
regression dashboard

How do you want to interact?
Raffi


PS: for the record, I am not a proponent/opponent of cmake/b2, I am
proficient in cmake though.



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

[John Maddock via Boost]

Post by Raffi Enficiaud via Boost
I am in. I have several things in mind, such as
* to work on an component that describes the dependencies between
libraries in order to add then in a topological sort order from the
main project
* port the documentation generation, focus quickbook+doxygen at first
* think/design/adapt/deploy regression runners and a possibly new
regression dashboard

All nice to have, but too advanced for me right now given that we have a
working system for those already... the priority is to improve the end
users experience, and keep the initial step focused enough that we can
review it and polish it up for release without getting bogged down
and/or acrimonious about it.

Post by Raffi Enficiaud via Boost
How do you want to interact?

To repeat, I have zero knowledge of CMake and am rather happy with what
we have. However, as a born-again-empiricist-scientist type I am open
to being proved wrong. So I'm more than happy to test whatever folks
come up with, but maybe before even that point, I'd like to be able to
read the equivalent of Boost's current getting started docs written for
a CMake port of the build/install process. After that, some getting
started docs for library authors too. I guess that's what I'm missing
from the current discussion - it's either too technical for me to follow
because I'm not familiar with CMake's internals, or else too
advocacy-based and substance free. I'm looking for something that can be
fed to a willing guinea pig so we can see if he prospers or not ;)

John.

Post by Raffi Enficiaud via Boost
Raffi
PS: for the record, I am not a proponent/opponent of cmake/b2, I am
proficient in cmake though.
_______________________________________________
http://lists.boost.org/mailman/listinfo.cgi/boost
.

---
This email has been checked for viruses by AVG.
http://www.avg.com


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

[Raffi Enficiaud via Boost]

Post by John Maddock via Boost

Post by Raffi Enficiaud via Boost
I am in. I have several things in mind, such as
* to work on an component that describes the dependencies between
libraries in order to add then in a topological sort order from the
main project
* port the documentation generation, focus quickbook+doxygen at first
* think/design/adapt/deploy regression runners and a possibly new
regression dashboard

All nice to have, but too advanced for me right now given that we have a
working system for those already... the priority is to improve the end
users experience, and keep the initial step focused enough that we can
review it and polish it up for release without getting bogged down
and/or acrimonious about it.

mmm... ok.

Post by John Maddock via Boost

Post by Raffi Enficiaud via Boost
How do you want to interact?

To repeat, I have zero knowledge of CMake and am rather happy with what
we have. However, as a born-again-empiricist-scientist type I am open
to being proved wrong. So I'm more than happy to test whatever folks
come up with, but maybe before even that point, I'd like to be able to
read the equivalent of Boost's current getting started docs written for
a CMake port of the build/install process. After that, some getting
started docs for library authors too. I guess that's what I'm missing
from the current discussion - it's either too technical for me to follow
because I'm not familiar with CMake's internals, or else too
advocacy-based and substance free. I'm looking for something that can be
fed to a willing guinea pig so we can see if he prospers or not ;)
John.

I understand your points. I however feel like this is a bit of a
"chicken and egg" situation: for instance, I fail to understand how one
can write an how-to for library authors, without even having a tiny set
of representative libraries that have proven the concept (or cmake API).

Also, it is not like you (personally) know nothing about build system.
Even though you have no experience with cmake, you have some (even good)
with b2, and you understand the problems those build system address.
This makes me wonder what is the level of assumptions we can make in
order to write a guide.

So, what I suggest is this:

1. we take one/two good developers as a target, including you for
instance. You are the user in this case, and a group of cmake developers
should provide you with a way to express your build requirements for a
set of libraries of your choice. The library should not be trivial to
port though (for instance should not be header only and should have
other dependencies), otherwise this would be useless for most of us.
2. you review and interact with the cmake port developers, trying to
port eg. another library with the tools that were developed in the first
stage. If this is too complicated/difficult/error prone, then we go back
to 1.
3. once everybody is happy (or not) we write one tentative how-to and
report back to the ML.

On my side, I will mostly try to do what is being done with b2 for
boost.test. (Although some people do not like it) it is a central
library I believe, and its integration to other project will raise a lot
of issues.

What do you think?

Raffi


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

[John Maddock via Boost]

Post by Raffi Enficiaud via Boost
1. we take one/two good developers as a target, including you for
instance. You are the user in this case, and a group of cmake
developers should provide you with a way to express your build
requirements for a set of libraries of your choice. The library should
not be trivial to port though (for instance should not be header only
and should have other dependencies), otherwise this would be useless
for most of us.
2. you review and interact with the cmake port developers, trying to
port eg. another library with the tools that were developed in the
first stage. If this is too complicated/difficult/error prone, then we
go back to 1.
3. once everybody is happy (or not) we write one tentative how-to and
report back to the ML.

Sounds reasonable to me.

Post by Raffi Enficiaud via Boost
On my side, I will mostly try to do what is being done with b2 for
boost.test. (Although some people do not like it) it is a central
library I believe, and its integration to other project will raise a
lot of issues.
What do you think?
Raffi
_______________________________________________
http://lists.boost.org/mailman/listinfo.cgi/boost

---
This email has been checked for viruses by AVG.
http://www.avg.com


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

[Andrey Semashev via Boost]

Post by John Maddock via Boost
Man but there's been a lot of hot air expanded on this subject.... guys
lets see what the proponents of CMake can come up with, yes I know there
are straw man proposals, but I want something that demonstrates it can
fully handle the complex cases at least as well as Boost.Build, and be
maintainable by CMake ignorants like myself, because lets face it, once
the transition is over, library authors will have to do the maintenance
grunt work as before: and if we can't easily see how to do that, then
the project probably fails.
As a minimal first step, what I would like to see come up for review
* Provides users with a way to build those libraries with source via
CMake. All of them together, or just some subset.
* Provides an install option for all of Boost.
* Is trivially easy for non-CMakers like myself to maintain.
Documentation should be provided (Boost/CMake best practice is...).
* Is fully compatible with current auto-linking naming on Windows (plus
whatever else comes along later like address-model and architecture name
mangling that's in the works and has long been requested).
* Supports libraries with non-trivial build requirements (regex, locale,
what others?).

Boost.Log, please. :) It has quite a lot of configuration and autodetection.

Post by John Maddock via Boost
* Is usable by end users to be able to easily reference Boost libraries
from their own CMake projects (note, might be limited to libraries with
source, since header only libraries are kind of trivial). An example,
and how to documentation should be provided.
* It would be nice if generated VS projects were reference-able from our
own solutions as well, but I accept that may not be possible.
* Is at a minimum, no worse than what we have now.
What else?
Takers?
BTW, I don't see a need for this to encompass every Boost library with
source before some kind of mini-review to iron out the warts...
Just hoping to move things along, John.

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

[Edward Diener via Boost]

Post by John Maddock via Boost
Man but there's been a lot of hot air expanded on this subject.... guys
lets see what the proponents of CMake can come up with, yes I know there
are straw man proposals, but I want something that demonstrates it can
fully handle the complex cases at least as well as Boost.Build, and be
maintainable by CMake ignorants like myself, because lets face it, once
the transition is over, library authors will have to do the maintenance
grunt work as before: and if we can't easily see how to do that, then
the project probably fails.
As a minimal first step, what I would like to see come up for review
* Provides users with a way to build those libraries with source via
CMake. All of them together, or just some subset.
* Provides an install option for all of Boost.
* Is trivially easy for non-CMakers like myself to maintain.
Documentation should be provided (Boost/CMake best practice is...).
* Is fully compatible with current auto-linking naming on Windows (plus
whatever else comes along later like address-model and architecture name
mangling that's in the works and has long been requested).
* Supports libraries with non-trivial build requirements (regex, locale,
what others?).
* Is usable by end users to be able to easily reference Boost libraries
from their own CMake projects (note, might be limited to libraries with
source, since header only libraries are kind of trivial). An example,
and how to documentation should be provided.
* It would be nice if generated VS projects were reference-able from our
own solutions as well, but I accept that may not be possible.
* Is at a minimum, no worse than what we have now.
What else?

Testing and documentation with CMake. This covers nearly all libraries
which test, as well as a large subset of libraries which use b2 to
create the library documentation.

Post by John Maddock via Boost
Takers?
BTW, I don't see a need for this to encompass every Boost library with
source before some kind of mini-review to iron out the warts...
Just hoping to move things along, John.

Exactly. CMake as the required build system for Boost is a done deal and
we are wasting much hot air arguing about, even if we understand the
reasons for that hot air. I fully support settings practical use cases
and moving forward addressing those use cases for the people who
understand CMake and can make things happen.


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

[Nana Sakisaka via Boost]

(snip)

As a minimal first step, what I would like to see come up for review (yes a

(snip)
* Is usable by end users to be able to easily reference Boost libraries
from their own CMake projects (note, might be limited to libraries with
source, since header only libraries are kind of trivial). An example, and
how to documentation should be provided.

You can create a virtual target called INTERFACE then users can reference
that target to get all the dependencies for the header files:

set(BOOST_INCLUDE_DIR "${PROJECT_SOURCE_DIR}/include")

add_library(boost_all_headers INTERFACE)
file(GLOB_RECURSE BOOST_ALL_HEADERS "${BOOST_INCLUDE_DIR}/include" "*.hpp")
target_include_directories(boost_all_headers INTERFACE
"${BOOST_INCLUDE_DIR}")
target_sources(boost_all_headers INTERFACE ${BOOST_ALL_HEADERS})
install(TARGETS boost_all_headers EXPORT boost_all_headers_export)
export(
EXPORT boost_all_headers_export
FILE "Boost-config.cmake"
)

Basically you put this kind of script to the root CMakeLists.txt (of Boost).
The steps for the user could be something like:
- Clone the boost library (or its components).
- Run the initial `cmake` for boost.
- Run `make install` - when you have provided some specific options to
CMake, this won't actually *install*; it does the EXPORTing and creates the
Boost-config.cmake on the Boost root.

So if you need only the header-only library, then you can just generate the
exported target without building the libs.

Referencing the exported target should also correctly add the Boost include
directory (pointing to your local installation) to your program.
Sometimes you need the BEFORE PUBLIC property to get it included before the
system-wide dirs.

The script above is a rough sketch, but I hope this helps..

Nana.

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