<build>no on a library prevents installing/staging other libraries

[Lastique]

Make sure you completed the following tasks

• I searched the discussions
• I searched the closed and open issues
• I read the contribution guidelines

Environment and version details

• Operating System+version: Ubuntu 21.04
• Compiler+version: GCC 10.3
• Shell: Bash
• B2 Version: 4.7

Problem description

When one of the libraries in a project has <build>no feature attached in requirements, other libraries in the same project are no longer installed in the stage/install directory, even if built. Here's an example Jamfile:

import project ;
import feature ;
import configure ;

project boost/foobar
    : source-location ../src
    ;

lib boost_foo
    : ## sources ##
      foo.cpp
    ;

lib boost_bar
    : ## sources ##
      bar.cpp
    : ## requirements ##
      <build>no
    ;

boost-install boost_foo boost_bar ;

Full project is here, place in $BOOST_ROOT/libs:
foobar.tar.gz

Running b2 -j8 --with-foobar stage or b2 -j8 --prefix="<install_prefix>" --with-foobar link=shared install only installs CMake files but no headers or libraries. In bin.v2 libboost_foo.so.1.78.0 is actually built though.

<build>no should only affect boost_bar and not boost_foo.

[Lastique]

This is now affecting Boost.Stacktrace installation on Linux in Boost 1.78 - no headers or libraries are installed for Boost.Stacktrace, ever. This is a major regression from 1.77.

[Lastique]

Reverting both #97 and #81 fixes this, at least for Boost.Stacktrace.

cc @grisumbras

[grisumbras]

It is very unfortunate that I see this issue just now. Can you check if #113 fixes this issue?

[Lastique]

Yes, at least Boost.Stacktrace installs with #113 applied. Thanks.

[pdimov]

Looks like this also affects Fiber: boostorg/fiber#290.

[ncook-hxgn]

the patch for 1.78 wrt boost atomic.. stopped working? Surely not. Surely I broke it. Surely I should just look at 1.79.
It's got a patch for a known issue too

I wish boost would release patched versions. What's so scary about 1.78.1 or 1.79.1?

[grisumbras]

Are you saying the issue isn't fixed for you?

[ncook-hxgn]

It was, then it wasn't. So it's definitely us (or some LTSC Visual Studio upgrade has scuppered something but I don't think that's what this is this time, because the patch+build are completing without error).

It would just be nice if the patches were rolled into a patched release, so I didn't have to fret about my patching process falling over when e.g. my coworkers rearrange our nuget package builds rep. I had to modify the patch to work with our particular situation, and while it looks like the patch is still applying correctly since my colleague shuffled the repo folders about, I am now missing the boost-atomic mt gd x64 lib again :(

[grafikrobot]

@ncook-hxgn you could at least use the latest B2 instead of the one from the Boost distribution. But perhaps the extra, and separate, B2 build & install is a problem with your build process?

[ncook-hxgn]

I'm using the b2 from the 1.78.0 distribution as far as I am aware, which was reliable enough for me to merge our boost nuget packaging pipeline to main. I can try the latest, but I'm not sure it will help. The bundled one used to work. I'm going to rule out some it-was-me scenarios first..

[ncook-hxgn]

@grafikrobot I have some facts. I don't got no reasons, but I got me some facts:

if the source archive is extracted to X:\repos\<org>\<project>\<repo>\boost\src\boost_1.78_0, it does build*
if the source archive is extracted to X:\repos\<org>\<project>\<repo>\s\boost\src\boost_1.78_0, it does build
if the source archive is extracted to X:\repos\<org>\<project>\<repo>\shared\boost\src\boost_1.78_0, it no build
if the source archive is extracted to X:\repos\<org>\<project>\<repo>\common\boost\src\boost_1.78_0, it no build

.. Trying to not give away too much about the exact contents of my computer, but X:\repos\<org>\<project>\<repo> is 47 characters. That is to say, D:\repos\<org>\<project>\<repo>\boost\src\boost_1.78_0 is 70 chars.

• it does build: that is, all permutations of static/shared/32/64 configs under msvc (vc143) produce libraries and those libraries are where my nuspec scripts expect them to be, and all my nugets pack (which to me means everything built, because I package everything).

Is there some sort of known issue for path length when building boost?

[pdimov]

There is, yes. It's a Windows limitation. See https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd

You can pass the --hash option or the --abbreviate-paths option to b2 to work around it. See https://www.bfgroup.xyz/b2/manual/main/index.html#bbv2.overview.invocation.options

[ncook-hxgn]

@pdimov aha - now I did consider MAX_PATH. the path of the libboost_type_erasure-mt-gd-32.lib (~name) was 170 chars, including the filename.. so I kind of figured it likely wasn't that.

However, on my old kit, I had enabled the long win32 paths option in GPO. I'm pretty sure it's enabled on our build machines too.. but it might not be on some newer ones..

I just threw something into my build to try some madness with a subst, but --abbreviate-paths is more appealing and/or this GPO option are much more appealing. I'll give it a go and come back with more info.

[ncook-hxgn]

Well, --abbreviate-paths seemed to work for a bit, but now it doesn't again. I'll try --hash instead