Subject: Re: [boost] [CMake] what to do now?
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-15 20:47:10
On Friday, April 15, 2016 at 7:01:27 PM UTC-5, Robert Ramey wrote:
>
> On 4/15/16 3:45 PM, Paul Fultz II wrote:
> >
> >
> > On Friday, April 15, 2016 at 1:33:10 PM UTC-5, Robert Ramey wrote:
> >>
> >> On 4/15/16 10:13 AM, Paul Fultz II wrote:
>
> >> If I want to just build part of the library - like the docs it's very
> >> convenient to just create a local CMake project (in a separate
> directory
> >> tree) from <library>/docs/boostbook.
> >
> >
> > And whats the difference between creating a local directory and running
> > `cmake --build <some_dir> --target doc`?
>
> right - no difference. So you don't need the CMakeList.txt in the
> library root directory. That's my whole point.
> >
> >
> >> Similarly, if I want to just build
> >> the library without testing, it's convenient to just create a local
> >> CMake project which does this.
> >
> >
> > And you should be able to:
> >
> > mkdir build && cd build
> > cmake --build .
> >
>
> right - no difference. So you don't need the CMakeList.txt in the
> library root directory. That's my whole point.
>
> >
> >> If you want test using this approach,
> >> you'll create a separate build of the library which would be redundant.
> >> But it's not the end of the world. I'm guessing that boost
> developers
> >> would not be uncomfortable with all this.
> >>
> >
> > But why deal with redundant builds? If you create your cmake like other
> > libraries, you wouldn't have this problem. I don't see any advantage to
> your
> > way, only disadvantages.
>
> I don't see any difference.
>
Redundant builds is a big difference.
>
> The standard CMake way has a CMakelists.txt in each subdir
>
This is common but not necessary. Zlib doesn't put a cmake in each
directory,
neither does the Fit library.
>
> >> Now boost users.
> >>
> >> Moving to boost users - some might find it convenient to have a library
> >> level CMakeList.txt file which includes add-directory. It it included
> >> much else, it might break the ability to make part of the library. I
> >> doubt most boost developers would be happy with this.
> >>
> >> Actually, the CMake vision is that normal users install a "Package"
> >> which doesn't do any testing at all. So they are not in this game.
> >>
> >
> > What? Any packaging system should allow the ability to run the tests as
> > well.
>
> Hmmm - then wouldn't have to presume that all the boost libraries that
> the libraries and tests that the library depends upon would have to be
> included? So then one would have to couple all the libraries together
> via some convention. Wouldn't that suggest we have to address the
> problem of dependencies which are different depending upon whether one
> is just building the library or building an testing the library or
> building a particular application which uses the library?
>
Yes, of course, it will need to track test dependencies separate from the
build
dependencies. Cget already does that, I don't see that as problematic.
>
> >> On the other hand, If a library level CMakeLists.txt were required and
> >> the subdirectory level CMakeLists.txt could not function independently
> >> of this, then a user would have to build / test all or nothing.
> >
> > This is not true at all. You can tell cmake what targets you want to
> built.
>
> Actually I wasn't really aware of this. If that's true, then there is
> really no difference. In any case you have to have CMakeLists.txt in
> each subdirectory. Regardless of whether you use your --build syntax or
> cd to the subdirectory and invoke CMake you'll get the same result.
>
Except as a user I would need to figure out the folder structure of your
library before building, instead of invoking the standard `all` or `install`
target.
>
> The only time one needs the library root is when one want's to build all
> the targets.
>
> > Furthermore, all targets that are not part of the library or application
> > should
> > use the `EXCLUDE_FROM_ALL` property. For example, building hana doesn't
> > build
> > any tests, only when I build the `check` target, which will build and
> run
> > the
> > tests. The same is true for llvm/clang. This convention is quite common
> not
> > just for cmake projects, but for autoconf projects as well.
>
> Arrrrggggghhhh
> >
> >> I've
> >> always wanted to require library users to run all the tests and post
> the
> >> results to a common place. CDash supposedly supports this, but has a
> >> number of issues.
> >>
> >> To summarize, I believe that the only issue here is having a
> >> CMakeList.txt in the library root directory. And I don't think it's a
> >> huge issue in the scheme of things. My view would be that if someone
> >> want's to do it - OK - but I think they getting the benefit they think
> >> they are.
> >>
> >
> > The benefits of following the conventions makes it familiar for people
> who
> > use cmake and autoconf tools. No one would think that they would need to
> cd
> > into a directory to build a target.
>
> This would not apply to boost build users.
Which is very few users of boost, as most boost users use some form of
autotools, cmake, make, visual studio, etc.
>
>
> > Also, it makes it easier to integrate with other tools. For example, I
> can
> > build and install hana with just `cget install boostorg/hana`. I can
> also
> > run the tests as well before installing by using `cget install --test
> > boostorg/hana`. The same works for Boost.Compute,
>
> > however, this won't work for serialization(and won't ever).
>
> Hmmmm - why not?
>
Because it doesn't have a CMakeLists.txt in the root directory.
>
>
> Robert Ramey
>
> _______________________________________________
> Unsubscribe & other changes:
> http://listarchives.boost.org/mailman/listinfo.cgi/boost
>