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

Use different build type values to search required dependencies (requires attribute) #4097

Closed
HerbertKoelman opened this issue Dec 10, 2018 · 5 comments
Assignees

Comments

@HerbertKoelman
Copy link

Here is recipe that I use to create packages this way:

$ conan create ./conanfile.py TSI/28.0.0@rcs/testing --profile pc_x86_ubuntu16_5.4.0 -s build_type=Debug

I use the -s build_type=Debug to tell conan to consider that TSI/28.0.0@rcs/testing is of build type.

The problem here is that this command searches for the required Artefacts (POCO, ...) using the build_type that I passed. In this case Debug, it therefore is not finding my dependencies.

But what if I want to use Release artefact to build my Debug version of TSI ?

Is there a way to set the TSI build_type to Debug and still let conan search dependencies without taking this criteria into account. Ending up with this

  1. Produce TSI using build_type=Debug
  2. Tell CONAN to search for
    1. POCO/1.9.0-M2@rcs/stable build_type=Release
    2. OpenSSL/1.0.2l-M0@rcs/stable build_type=Release
    3. CSC/1.17.0@rcs/stable build_type=Release

I use conan 1.9.2 on Linux:x86_64 (Ubuntu 16).

--- conanfile.py ------------------------------------

from conans import ConanFile, tools

class RecipeConan(ConanFile):
    name = "TSI"
    version = "28.0.0"
    topics = ("c++", "CXX", "interface", "ticketing")
    settings = "os", "compiler", "build_type", "arch"

    generators = ("cmake_find_package","cmake_paths")

    requires = (
            "POCO/1.9.0-M2@rcs/stable",
            "OpenSSL/1.0.2l-M0@rcs/stable",
            "CSC/1.17.0@rcs/stable"
            )

    def package(self):
        self.copy("*.h",   dst="include", src="/home/dev/c++/TSI/include")
        self.copy("*.hpp", dst="include", src="/home/dev/c++/TSI/include")

        self.copy("*.dll", dst="bin",     src="/home/dev/c++/TSI/build", keep_path=False)
        self.copy("*.so",  dst="lib",     src="/home/dev/c++/TSI/build", keep_path=False)
        self.copy("*.a",   dst="lib",     src="/home/dev/c++/TSI/build", keep_path=False)

    def package_info(self):
        self.cpp_info.libs = tools.collect_libs(self)

To help us debug your issue please explain:

@memsharded
Copy link
Member

Hi @HerbertKoelman

I think you could do it with per-package settings:

$ conan create ./conanfile.py TSI/28.0.0@rcs/testing --profile pc_x86_ubuntu16_5.4.0 -s build_type=Release -s TSI:build_type=Debug

This is possible, but just to make sure and for other readers, it is something that might fail because of ABI compatibility. There is no guarantee that the ABI between Debug and Release packages in C++ is maintained, so the final application might fail to link, or fail at runtime. In Windows/VS it typically refuses to link, mainly to different in the runtime MD/MDd. In Linux it normally works.

Please tell me if the above works for your case. Thanks!

@HerbertKoelman
Copy link
Author

Oups I didn't see your reply until now 8-)

Ok, this is cool.

Can I use this syntax (I mean ... -s TSI:build_type=Debug) in a profile file ? Or is this only available as command line argument ?

@memsharded
Copy link
Member

Yes, yes, you can also use it in profiles:

[settings]
build_type=Release
TSI:build_type=Debug

This should work with your conan create. Beware that it might have a bug and might not work for the local flow (conan install + build in user space), but that is most likely going to be fixed for next release.

Please try the above and tell me, thanks!

@HerbertKoelman
Copy link
Author

Thanks for this detailed answer.

Best wishes for the festive season :-)

@ghost ghost removed the stage: triaging label Dec 21, 2018
@memsharded
Copy link
Member

Thanks to you for following up.

Best wishes to you too! :) :) :)

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

No branches or pull requests

2 participants