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.
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
New modernized recipes for zlib and bzip2 #6474
New modernized recipes for zlib and bzip2 #6474
Conversation
|
||
|
||
class TestPackageConan(ConanFile): | ||
settings = "os", "compiler", "arch", "build_type" | ||
generators = "cmake", "cmake_find_package" | ||
generators = "CMakeDeps", "CMakeToolchain", "VirtualRunEnv" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This VirtualRunEnv
, we could discuss if we want it explicit or implicit.
Its goal is to be able to run with shared libraries, the conan create . -o lib:shared=True
works with this.
There is [conf] to automatically use it without explicit instantiation, but the invocation self.run("%s --help" % cmd, env=["conanrunenv"])
still needs to specify conanrunenv
, and this is not injected by default.
@memsharded Can you split this pr into one for bzip2 and one for zlib? |
tools.get(**self.conan_data["sources"][self.version], destination=self.source_folder, strip_root=True) | ||
# FIXME: this is failing after the export export to "src" in local folder | ||
try: | ||
os.rename("CMakeLists.txt", "src/CMakeLists.txt") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
os.rename("CMakeLists.txt", "src/CMakeLists.txt") | |
tools.rename("CMakeLists.txt", "src/CMakeLists.txt") |
Is it capable of moving files ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but only when the target directory is already created.
self.cpp_info.builddirs.append(self._module_subfolder) | ||
self.cpp_info.build_modules["cmake_find_package"] = [os.path.join(self._module_subfolder, self._module_file)] | ||
self.cpp_info.libs = ["bz2"] | ||
|
||
if self.options.build_executable: | ||
bin_path = os.path.join(self.package_folder, "bin") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got appending the path implicit somehow? If yes, through what?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We expect the consumers to use the VirtualRunEnv
when need it instead of filling the PATH by default with stuff with might never need.
|
||
required_conan_version = ">=1.33.0" | ||
required_conan_version = ">=1.38.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First, we need to update the CI. I think we are running 1.37.2
def configure(self): | ||
del self.settings.compiler.libcxx | ||
|
||
def layout(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems to be unused (e.g. never called), it is needed? if so, why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is the new layout()
built-in Conan method to define the package layout, it is called internally by Conan, like other methods: https://docs.conan.io/en/latest/reference/conanfile/methods.html#layout
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reading about feature, I don't get why is it needed for test package?
You can declare a layout() method in the recipe to describe the package contents, not only the final package in the
cache but also the package while developing. As the package will have the same structure in the cache and in our
local directory, the recipe development becomes easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not "needed" but nice to use always the same layout, more clear, and easy to explore the build files in case you need.
@memsharded the current CI system will not allow to build PR for several recipes (zlib + bzip2) |
def test(self): | ||
if not tools.cross_building(self.settings): | ||
bin_path = os.path.join("bin", "test_package") | ||
self.run("%s --help" % bin_path, run_environment=True) | ||
cmd = os.path.join(self.cpp.build.bindirs[0], "test_package") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if it's safe, e.g. if bindirs is an empty
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a bindir of the current package. As you are declaring the layout(), you know there is always a bindir. Actually were always a bindir unless you remove it from the cppinfo.
@madebr @SSE4 @uilianries lets wait until @davidsanfal comes up with some CI for this new |
Co-authored-by: ericLemanissier <ericLemanissier@users.noreply.github.com>
The split thing is not only due CCI restriction, but also to keep a better. 1 recipe is easier to review than 2. I don't like the idea supporting multiple recipes on same PR, but as this PR is a conception, it's okay keeping all together. |
It would have been nice to see c3i succeed/fail on this 😄 |
@@ -1,8 +1,10 @@ | |||
import os | |||
import textwrap | |||
from conans import ConanFile, CMake, tools | |||
from conans import ConanFile, tools |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we start to try to replace all the tools.xxx
also? (in general all the conans imports)
tools.patch(**patch) | ||
with tools.chdir(".."): # FIXME: This need to go to parent folder is not very nice. | ||
for patch in self.conan_data["patches"][self.version]: | ||
tools.patch(**patch, base_path=self.source_folder) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See conan-io/conan#9361
apply_conandata_patches
can be used to follow the layout automatically.
(Same comment for all these PRs) I totally support to start testing new toolchains and build-helpers... but this is not the way/repository to do it. If we want to test them using the current Conan version in ConanCenter then we can open drafts to With this approach, we only get notifications with errors in the backend because it is not using |
Proposing changes for zlib and bzip2