Boost dependency under Windows

[Philippe Payant]

Under Windows, meson will auto-detect Boost if it is placed under `C:\local\boost_*` and the first match of those is selected.  Failing this, `C:\` is tried.  Setting the `BOOST_ROOT` environment variable causes the Boost on Windows auto detection to be skipped.

I have my boost installed in `C:\dev\boost_1_64_0` and I would like to set `BOOST_ROOT` and pick up Boost like that.  

I am ready to code this up in meson.  Would that be a welcomed patch to meson?

[Jussi Pakkanen]

That is what it should already be doing. If it does not work then it's
a bug, patches are welcome.

[Philippe Payant]

I took a closer look and the following message proposes significant changes to how Boost is used under Windows. Not on Unixes, I am sure that works very well, but Windows…

I am checking with the community because obviously somebody coded it this way and is probably relying on the current rules coded in meson. I do not want to submit a pull request that is going to get rejected right away.

The meson documentation says to use BOOST_ROOT, BOOST_INCLUDEDIR and/or BOOST_LIBRARYDIR environment variables if Boost is in a non-standard location.

Under Windows, there is no standard location, so meson has codified default places where it looks for Boost (in order):

• C:\local\boost_*
• C:\

There are problems with this. Assuming an installation in the root of C: makes no sense. C:\ would have the following entries: boost, doc, libs, status, tools, INSTALL, etc. Nobody would do this.

C:\local\boost_* is OK, if the meson documentation mentioned it and the user is willing and able to re/locate the boost installation to C:\local. As a minor point, I am not sure which directory would be picked up if there were multiple matches.

For Windows users then, the best course of action is to set BOOST_ROOT. But then meson computes that the include directory for the headers is $BOOST_ROOT/include. This is wrong, the include directory is simply $BOOST_ROOT. This is my first “unsolvable” issue.

The other thing meson need is to find the libraries. There is no standard location for them on the system, but there is a standard location within $BOOST_ROOT if the user followed the Boost Getting Started on Windows guide. This location is $BOOST_ROOT/stage/lib. To my knowledge, there is no other established default or standard location for the libraries.

Sadly, meson is not looking there. It searches for the first directory that matches $BOOST_ROOT/lib64* or $BOOST_ROOT/lib32* (depending on the compiler’s address model). On the other hand, this is a nice feature for Windows users who need cross-compilation. This is my second issue with the Boost dependency. This is not where my libraries are and BOOST_LIBRARYDIR is only used if you have not set BOOST_ROOT (which I did to get around the other problem)

My proposition is this. Under Windows, one must define BOOST_ROOT since there is no standard location. In a non-cross compile, meson looks for libraries in $BOOST_ROOT/stage/lib. In a cross compile, meson looks in $BOOST_ROOT/stage/lib64 or lib32 (no wildcard here). If BOOST_LIBRARYDIR is set, it wins. If BOOST_INCLUDEDIR is set, it becomes the include directory to add. We add documentation to explain all this.

[Adam Foltzer]

I would point out that the official Windows binary distributions for Boost put the installation in C:\local\boost_* with the directory structure that is ending up failing for your source build. If you use these distributions rather than building Boost yourself, then everything Just Works(tm), and I'd really rather not change this.

I support the changes you propose to make BOOST_LIBRARYDIR and BOOST_INCLUDEDIR both 1) work at all when BOOST_ROOT is set and 2) override the default directory layout Meson assumes beneath BOOST_ROOT, but I would not support changing that default directory layout to something incompatible with the binary distributions.

Regards,

Adam

--
You received this message because you are subscribed to the Google Groups "The Meson Build System" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mesonbuild+...@googlegroups.com.
To post to this group, send email to meson...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mesonbuild/3aec7a02-78b7-4b05-a868-e9796f7b61bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jussi Pakkanen]

On Wed, Aug 23, 2017 at 11:45 PM, Adam Foltzer <acfo...@galois.com> wrote:

> I would point out that the official Windows binary distributions for Boost
> put the installation in C:\local\boost_* with the directory structure that
> is ending up failing for your source build. If you use these distributions
> rather than building Boost yourself, then everything Just Works(tm), and I'd
> really rather not change this.

Is the directory/file layout different for official releases vs
self-built ones? In other words, is the difference only in the
directory prefix that is used?

As far as BOOST_ROOT goes, we should behave the same as other build
systems (in practice probably CMake) do. If we do something
differently then we could probably change it to be consistent.

[Philippe Payant]

I never knew that there was an installer for a fully compiled Boost!  Thanks for this.

This changes everything for me for now I understand the Boost detection logic in Meson better. 

M. Pakkanen, to answer your question "Is the directory/file layout different for official releases vs self-built ones?", they are not significantly different.  A self built Boost will place the libraries in $BOOST_ROOT/stage/lib.  A binary distribution places them in $BOOST_ROOT/lib64-msvc-8.0.  One can assume the person building the distribution is running a manual build per configuration and moving them from stage/lib to libXX-CONFIG.

I thought my self-built Boost procedure was the norm, while in fact prebuilt binaries may be the norm.  Hence my confusion.  If I would have been like most people, Meson would have picked up Boost in C:\local right away.

Still, if one were to require to use $BOOST_ROOT to pick up a Boost installation in a non-standard directory, then the headers would not be found (because of the $BOOST_ROOT/include bug I mentioned in the August 22nd post). 

Then, we can expect that the standard layout is under $BOOST_ROOT, so libraries should be picked up under $BOOST_ROOT/libXX-CONFIG. 

For users with a manual build of Boost, it is possible for them to set BOOST_LIBRARYDIR too in order to point to their libraries.  I guess we would rarely see the need to use BOOST_INCLUDEDIR.

I will switch to a binary distribution and save me some trouble...

--

Philippe