-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Define a target per library when multiple libraries in a package #1323
Comments
The thing to achieve this is that you force the package creator to define the full model of dependencies inside the package. In this case, the boost package should contain a complete dependency graph of the internal relations of boost libraries, to be able to define such targets properly. As you know, this is not a simple task, there are even tools like bcp to analyze such dependencies. Besides that, the true issue is that having a package for the whole boost is not the proper approach. Implementing a dependency manager internal to packages is an unnecessary complexity. The good one would be to have one package per library, and let the package manager handle it, this is exactly the reason of a package manager. I think we should start considering modularizing Boost in this way, though it can take some time. |
Hmm, you are right, I did not realize this would push the burden of maintaining dependencies to the package. So if the proper way is to modularize boost there it would be extremely helpful to be able to create multiple packages from the same souce/build. Because boost sources are distributed as monolithic, building one boost library would require downloading the sources multiple times, one for each dependency. My specific case requires using boost's bcp tool to rename the boost namespace, in order to avoid symbol conflicts. This causes the sources to be copied from the build folder to the sources folder, then to the bcp folder with the new namespace. Since boost is comprised of a lot of header files, this operation is quite costly on windows machines. Another way to do it would then be to create a single 'master' package that contains the whole set of boost libraries, and then create conan packages that contain each one single lib, with the dependencies graph. Is this better in your opinion ? Thanks |
You might be interested in: http://docs.conan.io/en/latest/packaging/package_info.html#build-once-package-many This is not possible to create different packages (with different names, versions, user, channel), but to create different binaries. Yes, my opinion is definitely the second one, basically create conan packages, one for each library, let the package and dependency management resolve them, and yes, using a "project" master package that require all of them to be able to fire complete builds, or to depend on it as a whole, seems the way to go. The only problem with it is that it requires a large investment, as Boost is large. But we are analyzing it, might try to make a proof of concept. |
Thanks a lot ! |
I have a cmake library project, lets call it libA The project contains two targets:
The test suite that is part of the project links both targets Another cmake library project (libB) requires libA. Now we are switching to conan and i can't see a way to maintain this separation since a conan package only exports one cmake target. I can't see a way to resolve this without the ability to export multiple cmake targets from a conan package. |
Hi! Finally, conan now create targets: Also, it is important to know which version are you running, these later changes are in 0.29. Please tell me, thanks! |
Great to hear, is this new feature somewhere jn the docs? |
Nope, the truth is that it was supposed to be an internal implementation detail, mostly transpared to users. Added it as an issue to the docs: conan-io/docs#389 |
thank you! We plan to have rather big packages with lots ob libs, at least in the first place, so its nice to have that feature. |
@memsharded Thanks for the quick response. I'm using version 0.29.
The test suite of libB uses gtest-matchers and mocks defined in libA-testutils. E.g. libA defines a class
I tried the feature that you mentioned above and it almost does what i need:
However, since the
Thats better than before, but it would be nice to have the |
Ah, ok, that makes sense, I thought it was only used for testing LibA, because of its name
But this is almost impossible, because you don't know which include directories belong to each target. Adding all include directories, like include dirs for LibA and Liba-testutils, to both CONAN_LIB::LibA and CONAN_LIB::LibA-testutils would be very confusing, because they will have unrelated include directories. There is no way conan can know which include directories belong to each library, that is why all include directories are associated to the CONAN_PKG target, not to the libs. Does this make sense? Maybe another possibility would be to package LibA-testutils in its own package, it sounds good to me. So, for example, when you deploy the final application, there is no such testing library there. |
Yes it does Would it be possible to extend/change the package_info method so that one can define includedirs per lib (without breaking compatibility with the current way of defining includedirs)?
The problem is that the test suite of LibA uses the matchers/mocks as well. If i put LibA-testutils into its own package i would have to move the tests of LibA into that package as well, which i find a bit weird. However; i'm not sure yet how to do the test+CI part with conan. Any suggestions/best practices? |
The "multi-config" system is not restricted to build-types only, you can do something like: def package_info(self):
self.cpp_info.includedirs = ["include"] # as they are common, no need to sefl.cpp_info.libA
self.cpp_info.libAtestutils.includedirs = ["testutils/include"] This will generate in conanbuildinfo.cmake, some extra variables, one of them being From your feedback I would say that a possible configuration would be:
|
Thanks for the "multi-config" hint. It works perfectly. If I understand you correctly you would put the testutils into their own conan-package but still have the tests suite as a part of the library-package. The test suite is only built when build_requires is set (e.g. build_requires=gtest). |
Oh, I wasn't aware that LibA-testutils depended on LibA, I thought they were mocks/matchers, but were actually a replacement, without a dependency to LibA. If they depend, then, you are right, that would be a cyclic dependency, which is impossible, and they should live in the same package. |
@memsharded: Are there plans to address this issue? It would be nice if we could just link against targets and not have to manually add include directories. By the way, my use case is for the gtest package which creates multiple libraries (e.g., |
Hi @JobNoorman Not sure what you mean. The cmake generator already generates targets, for each package. So you can specify to link targets, no need to manually add include directories. Actually, it was never necessary to manually add include directories, as the The package level targets are called |
I was referring to the
By having Conan set the |
I see. But the problem is that there is no way to know what would be the include directories for each individual library. Conan could set the CONAN_LIB::xxx include directories to the CONAN_PKG::xxx package include directories, but it feels a bit dirty, isn't it? |
From the example you gave above, I gathered that a CMake variable called |
@JobNoorman That is an interesting idea. The "multi-configurations" nested in I think this is very related to the issue of #2387. Maybe the best would be to follow information there. Please check. Thanks! |
I am using a Boost conan package, and I'd like to specify against which libraries I link, while still benefiting from using CMake targets.
Ideally, I'd like to have a global target as it stands today (e.g.
CONAN_PKG::Boost
) and one additional target per library defined (e.g.CONAN_PKG::Boost_thread
)This would require the generated
conanbuildinfo.cmake
to create more targets, but would allow for much more flexibility when using the package.Best
The text was updated successfully, but these errors were encountered: