Skip to content
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

Conversation

memsharded
Copy link
Member

Proposing changes for zlib and bzip2



class TestPackageConan(ConanFile):
settings = "os", "compiler", "arch", "build_type"
generators = "cmake", "cmake_find_package"
generators = "CMakeDeps", "CMakeToolchain", "VirtualRunEnv"
Copy link
Member Author

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.

@madebr
Copy link
Contributor

madebr commented Jul 23, 2021

@memsharded Can you split this pr into one for bzip2 and one for zlib?
Current c3i can only build one recipe per pr.

recipes/bzip2/all/conanfile.py Outdated Show resolved Hide resolved
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")
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
os.rename("CMakeLists.txt", "src/CMakeLists.txt")
tools.rename("CMakeLists.txt", "src/CMakeLists.txt")

Is it capable of moving files ?

Copy link
Member

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")
Copy link
Contributor

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?

Copy link
Contributor

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"
Copy link
Member

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):
Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Contributor

@SSE4 SSE4 Jul 26, 2021

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.

Copy link
Contributor

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.

@SSE4
Copy link
Contributor

SSE4 commented Jul 24, 2021

@memsharded the current CI system will not allow to build PR for several recipes (zlib + bzip2)
maybe you can split into 2 PRs?
another thing, which should make reviews easier, as there are lots of changes in lots of files: can you isolate only modernizing changes and leave cosmetic changes out (like, removing conan topic)
and yes, we don't have 1.38 yet, so it will not pass for a while.

@SSE4 SSE4 closed this Jul 24, 2021
@SSE4 SSE4 reopened this Jul 24, 2021
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")
Copy link
Contributor

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

Copy link
Contributor

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.

@memsharded
Copy link
Member Author

@madebr @SSE4 @uilianries lets wait until @davidsanfal comes up with some CI for this new new-cmake-toolchain branch, to split it or not. At the moment this is just a preview of things that could be modernized, NO intent to merge this yet in master branch

Co-authored-by: ericLemanissier <ericLemanissier@users.noreply.github.com>
@uilianries
Copy link
Member

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.

@madebr
Copy link
Contributor

madebr commented Jul 26, 2021

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
Copy link
Contributor

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)
Copy link
Contributor

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.

@jgsogo jgsogo deleted the branch conan-io:new-cmake-toolchain August 2, 2021 14:11
@jgsogo jgsogo closed this Aug 2, 2021
@jgsogo
Copy link
Contributor

jgsogo commented Aug 3, 2021

(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 master with a warning about the experimental level (we can also keep up-to-date Conan version in CCI if needed). If we want to test them using Conan HEAD version then we can use a fork and different CI. Maybe we can connect it to a branch in the tribe repository or in Conan repository, which are the places where development around these new features is taking place.

With this approach, we only get notifications with errors in the backend because it is not using master branch, and the output from some of the jobs running behind the scenes is not visible to reviewers... so they cannot even know if the recipe is valid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants