Skip to content

Boost Conan 2.0 compatibility #16222

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 8 commits into from
Closed

Boost Conan 2.0 compatibility #16222

Show file tree
Hide file tree
Changes from 7 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
a36619b
Boost Conan 2.0 compatibility
System-Arch Feb 22, 2023
4eb23a2
Use b2 install to copy files to package folder
System-Arch Feb 24, 2023
98d43cd
Restore headers_only package support
System-Arch Feb 26, 2023
6cfab6c
Merge branch 'master' into System-Arch-boost-1
System-Arch Mar 14, 2023
d843e39
Bumped required_conan_version
System-Arch Mar 14, 2023
47aac44
Bump required_conan_version
System-Arch Mar 24, 2023
8e0ff5a
Merge branch 'master' into System-Arch-boost-1
System-Arch May 12, 2023
d7fdf5d
boost: restore test_package
jcar87 May 19, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 20 additions & 11 deletions recipes/boost/all/conanfile.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@
import sys
import yaml

required_conan_version = ">=1.53.0"
required_conan_version = ">=1.57.0"


# When adding (or removing) an option, also add this option to the list in
Expand Down Expand Up @@ -876,8 +876,7 @@ def build(self):
full_command = f"{self._b2_exe} {b2_flags}"
# -d2 is to print more debug info and avoid travis timing out without output
sources = os.path.join(self.source_folder, self._bcp_dir) if self._use_bcp else self.source_folder
full_command += f' --debug-configuration --build-dir="{self.build_folder}"'
self.output.warning(full_command)
full_command += f' --debug-configuration --build-dir="{self.build_folder}" stage'

# If sending a user-specified toolset to B2, setting the vcvars
# interferes with the compiler selection.
Expand Down Expand Up @@ -1147,8 +1146,6 @@ def add_defines(library):
flags.extend(shlex.split(str(self.options.extra_b2_flags)))

flags.extend([
"install",
f"--prefix={self.package_folder}",
f"-j{build_jobs(self)}",
"--abbreviate-paths",
f"-d{self.options.debug_level}",
Expand Down Expand Up @@ -1375,13 +1372,25 @@ def _toolset_tag(self):
####################################################################

def package(self):
# This stage/lib is in source_folder... Face palm, looks like it builds in build but then
# copy to source with the good lib name
copy(self, "LICENSE_1_0.txt", src=self.source_folder, dst=os.path.join(self.package_folder, "licenses"))
rmdir(self, os.path.join(self.package_folder, "lib", "cmake"))
if self.options.header_only:
copy(self, "*", src=os.path.join(self.source_folder, "boost"),
dst=os.path.join(self.package_folder, "include", "boost"))

if not self.options.header_only:
# Use b2 install to move files to package folder
b2_flags = " ".join(self._build_flags)
full_command = f"{self._b2_exe} {b2_flags}"
full_command += f' --debug-configuration --build-dir="{self.build_folder}" install --prefix="{self.package_folder}"'

sources = os.path.join(self.source_folder, self._bcp_dir) if self._use_bcp else self.source_folder
with chdir(self, sources):
# To show the libraries *1
# self.run("%s --show-libraries" % b2_exe)
self.run(full_command)
rmdir(self, os.path.join(self.package_folder, "lib", "cmake"))
else:
# b2 doesn't appear to support a header-only installation so explcitly copy header files
for pattern in [ "*.h", "*.hpp", "*.inc", "*.ipp" ]:
copy(self, pattern, src=os.path.join(self.source_folder, "boost"),
dst=os.path.join(self.package_folder, "include", "boost"))

if self.settings.os == "Emscripten" and not self.options.header_only:
self._create_emscripten_libs()
Expand Down
9 changes: 5 additions & 4 deletions recipes/boost/all/test_package/conanfile.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,8 @@ def test(self):
# system libraries that are incompatible with Conan-provided ones.
# When `conanrun` is enabled, DYLD_LIBRARY_PATH will also apply
# to ctest itself. Given that CMake already embeds RPATHs by default,
# we can bypass this by using the `conanbuild` environment on
# non-Windows platforms, while still retaining the correct behaviour.
env = "conanrun" if self.settings.os == "Windows" else "conanbuild"
self.run(f"ctest --output-on-failure -C {self.settings.build_type}", env=env)
# we can bypass this by using the `conanbuild` environment. Similarly,
# "conanbuild" is needed if Conan is being used to manage the build
# toolchain such that CMake is a tool_requires and is not otherwise
# available on the host machine.
self.run(f"ctest --output-on-failure -C {self.settings.build_type}")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

env="conanrun" must not be removed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

env="conanrun" must not be removed

Hi @SpaceIm,
Please see the conversation with @memsharded (conan-io/conan#13138) where he explains why it should be removed when using Conan to manage the toolchain. In particular, if one is using a host profile to specify the GCC version via a [tool_requires]. we need both the runtime and buildtime environments for dynamically-linked tests to find the G++ runtine (libstdc++.so).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, but I think test() @memsharded is referring on (CMake.test()?) is totally different than test() of test package and self.run() command we are running.
So I don't say there is not also an issue here when someone has cmake in tool_requires, but by default a raw self.run is executed in build scope, so I don't see how it couldn't lead to a regression. What you want is to inject env vars of cmake into run scope, or inject both build & run scope into this self.run

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @spacelm,
I agree the circumstances in the thread with @memsharded were slightly different, but they are, in fact, a subset of what we have here. In both instances, the test_package test() method is calling ctest, so we need to be able to find that, which may be provided as part of a Conan-managed toolchain via [tool_requires]. The second issue, and it perhaps suggests that we really do need a [test_requires] feature in the host profile, is that the tests that use dynamic linking need to be able to see the runtime shared libraries provided by the compiler (GCC in this case) but those appear to not be part of the runtime environment when GCC is a [tool_requires]. I will add this new use case to the Conan issue thread to see what insights @memsharded can provide. Thanks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The removal of the env altogether will cause the tests to fail on Windows when shared=True, CI will fail in this instance:


The following tests FAILED:
	  1 - boost_random (Exit code 0xc0000135
)
	  3 - boost_test (Exit code 0xc0000135
)
	  4 - coroutine_test (Exit code 0xc0000135
)
	  5 - chrono_test (Exit code 0xc0000135
)
	  6 - boost_fiber (Exit code 0xc0000135
)
	  7 - boost_json (Exit code 0xc0000135
)
	  8 - boost_nowide (Exit code 0xc0000135
)
	  9 - boost_locale (Exit code 0xc0000135

where the exit code matches STATUS_DLL_NOT_FOUND

Based on what you are describing, I believe the changes introduced in #16348 should handle the case where you are expecting the gcc runtime libraries from a tool_requires. with an interest of moving forward with this PR, I'll restore this to how it is on master currently, and if there are still issues running tests in this instance, we han investigate separately - as it's something that is not specific to the boost test_package.