Create package & push to registry a C++ library I made w/ Conan + CMake (Conan 1)

[jreich218]

Hi,

I have to use Conan 1 right now because we have to store our remote registries in GitLab which only has Conan 1 support for the time being.

I'm having some doubt around how to transition...

From:

• Wrapping up a library I created w/ CMake and Conan (I used conanfile.py for the 3rd party dependencies my library depends on).

To:

• Creating a Conan package holding said library that I can push to a remote registry and share with the team (this implies I need know enough about building packages to be able to confidently tell the team what to write in CMake's "find_package" and "target_link_libraries", along with what to have them type in C++ "#include ..." statements when using my library).

Here are my questions:

1. Is it normal/encouraged to use the same conanfile.py for both tasks (i.e. the same conanfile.py for both for gathering third party dependencies during development and for creating the final package after development is finished)?
2. Regarding creating the package after development is finished: Is there a place in the documentation that focuses on how I can know what users should write in CMake's "find_package" and "target_link_libraries", along with what to type in C++ "#include ..." statements when using my libarary/Conan package? I know that, in general, doing an install with CMake can be tricky; is the expectation that package creators master CMake install ideas first and then "just know" how to wire everything up when making a Conan package? (I know that's a strange question... I'm just trying to get some intuition on expectations and resources).

Thanks...

[memsharded]

Hi @jason-m-reich

Thanks for your questions.
First, if Gitlab is still not that ready, I'd recommend filing them a ticket or upvoting + commenting existing ones, so they make sure to implement Conan 2.0 API, the API itself has been there for many years, it would be necessary soon, as the community keeps upgrading things to 2.0.

s it normal/encouraged to use the same conanfile.py for both tasks (i.e. the same conanfile.py for both for gathering third party dependencies during development and for creating the final package after development is finished)?

Yes, absolutely, using the same conanfile.py for both things is the recommended approach

I know that, in general, doing an install with CMake can be tricky; is the expectation that package creators master CMake install ideas first and then "just know" how to wire everything up when making a Conan package?

The filename and the targets would be by default the package name. So if requires = "somepkg/version", then it will be find_package(somepkg) and target_link_libraries(..... somepkg::somepkg).
Only the open source libraries from ConanCenter that have some "upstream" default name, that is, the name that appears in their "official" documentation and examples, then the recipe will use it. Like requires = "zlib/1.2.13, but find_package(ZLIB) and target_link_libraries(... ZLIB::ZLIB) for example. In Conan recipes you can find it in the package_info() method of the dependency (the code itself can be seen in conan-center-index repo, or directly inspected in the cache with conan cache path zlib/1.2.13). But for your own packages, you shouldn't be customizing those names, so the default will always the package name, and that will be straightforward.

[jreich218]

@memsharded,

Thanks for the helpful answer! May I show you how I did what we were discussing? What I did works, but it feels a little hacky so I'm wondering if I missed something.

It's been a few weeks... so just a reminder: I'm making a proprietary library in C++ that uses Conan for its 3rd party dependencies. Then, as we discussed above, I'm using the same conanfile.py that I used all along for the library... in order to "turn around" and build a Conan Package out of my library. Ultimately, other people on my team are working on a separate C++ project that needs my library... so they will pull the package I'm making [after I push it to our Conan Package Registry]. And, for now, I have to use Conan 1.

Here is what I added to the conanfile.py to make the package:

    exports_sources = ("CMakeLists.txt", "<directory holding all of my library's code>/*")

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def package(self):
        cmake = CMake(self)
        cmake.install()

    def package_info(self):
        self.cpp_info.libs = ["<name of my library>"]

And here is what I did in CMakeLists.txt on account of preparations to build the package:

target_sources(<name of my library>
  PUBLIC FILE_SET HEADERS
  BASE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/include   # This is the target_include_directories path for my library's .h files
  FILES  # Here I list every header file (with the local path prefixed to each file name)

# Note that the list of every single header file that is placed where the above comment was written is a place where I feel like I might be doing something hacky/wrong
)

include(GNUInstallDirs)

install(TARGETS <name of my library>
    FILE_SET HEADERS
)

Finally (and I should mention that before I ran the following commands I had successfully built the library locally and connected to our remote Conan registry) I run these commands:

# Create release package
cd build/Release && \
conan export-pkg ../../conanfile.py -pr:b=default --force

# Create debug package
cd build/Debug && \
conan export-pkg ../../conanfile.py --settings=build_type=Debug -pr:b=default --force

# Push to registry
conan upload <name of my library>/0.1@_/_ --all -r=<name of remote>

Like I said, this does work when the people using my library list it as a dependency and include it in their project. But the fact that I had such a long list of headers in my CMakeLists.txt file, and the fact that my use of conan export-pkg seems like a "side show" and not the normal way the Conan docs suggest making a package¹ both made me want to check in.

Footnotes

1. I tried making the package for quite a while using the Conan docs instructions for making packages... but was only able to get things to where I could create something usable for the users of my library/package when I adopted the export-pkg command (I seem to recall that anything I tried without export-pkg command made packages that didn't have my library's header files, or something like that). ↩

[memsharded]

Hi @jason-m-reich

There should be definitely something else, this scenario is expected to work.
Maybe if you share the full output of the 2 conan export-pkg commands, that could have some useful hints of what could be happening or missing.

It would be equally important to inspect the "package" folders in the cache. If you read the output logs you will see those folders, and then having a look inside, they should contain the include/your-headers files. Please check that.

Then also, before the conan upload you should be able to execute a conan search mylibrary/0.1@ and see there 2 different binaries that you "export-packaged".

Please share with use those details. Thanks!