Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: paul (pfultz2_at_[hidden])
Date: 2017-06-19 18:02:36

On Mon, 2017-06-19 at 18:43 +0200, Olaf van der Spek wrote:
> On Mon, Jun 19, 2017 at 5:14 PM, P F <pfultz2_at_[hidden]> wrote:
> > 
> > 
> > > 
> > > On Jun 19, 2017, at 3:58 AM, Olaf van der Spek via Boost <boost_at_[hidden]
> > > ost.org> wrote:
> > > 
> > > On Sat, Jun 17, 2017 at 3:36 PM, P F via Boost <boost_at_[hidden]>
> > > wrote:
> > > > 
> > > > It would be nice to not just support cmake, but pkgconfig as well.
> > > > There are many times I need to use boost in non-cmake projects, so
> > > > having pkgconfig would be helpful as well.
> > > I don't really get find_package and pkgconfig etc.
> > > 
> > > I use package management to install the dependencies I need.
> > > I then include and link to the stuff I need. It'd be nice if the
> > > linking was automatic like it is on MSVC but okay.
> > > 
> > > Why does one need all kinds of extra complexity in every single make
> > > file for things like find_package or pkgconfig?
> > I find writing something like `g++ $(pkgconfig boost_asio --cflags —libs)
> > foo.cpp` much easier to write. In fact, I would need some investigating to
> > know what flags I need. Other users would like boost to support pkgconfig
> > as well as there are tickets open for this. Almost the same applies for
> > `find_package` in cmake as well.
> `g++ foo.cpp` would be even easier.. but Linux still doesn't support
> auto-linking like GCC AFAIK.

Even if auto-link would work, it would fail to find the headers for user
installations. I could hard-code the include path, but this makes the build
not-relocatable to another machine. I could add a custom variable like
`BOOST_ROOT` but this complicates the build environment. 

For proprietary builds, you can get away with a lot. You can require the
developers to put the dependency in a certain folder or set all these build
flags. 

However, for open-source it is very different because the users will be
building the product as well. They may have different build envirnomnents,
they may put all their dependencies in /opt/foo or they may spread it out
among different folders, or they may be cross-compiling so they need to ignore
the host dependencies. 

Boost should definitely support these open-source workflows, as many other
open-source libraries do.