Conan 1.19.0 can break static library compilation when using visual_studio generator
See original GitHub issueHi there,
Conan 1.19.0 has introduced changes to the visual_studio
generator via this PR: https://github.com/conan-io/conan/pull/5564
However the decision to add the following code to the generated props file can break compilation of static libraries that reference other static libraries, but are not expecting to be linked against them (in our case this is done later when being consumed by a shared library or executable).
<Lib>
<AdditionalLibraryDirectories>$(ConanLibraryDirectories)%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
<AdditionalDependencies>{libs}%(AdditionalDependencies)</AdditionalDependencies>
</Lib>
Our organisation has been using Conan since the 0.28.0 release and now have over 400 private Conan packages, several of which are static libraries that reference other internal static libraries. We do not wish for our static libraries to be combined together by default. As it stands, the visual_studio
generator is broken for us (multiple projects fail to build) and would require us to explicitly update all our affected projects to reset the the <Lib>
configuration at the project level - not exactly what I would call a backwards-compatible change.
I do understand the core requirement of the PR in question. Looking into it, wouldn’t an alternative (backwards-compatible) solution have been to, instead of adding the <Lib>
section to the generated props file, add another custom property that end users could then use in their project files if they desire that static libraries be combined?
<PropertyGroup Label="ConanVariables">
...
<ConanLibraries>{libs}</ConanLibraries>
</PropertyGroup>
I think this is further backed up by the comment in the PR that questioned whether it was safe to add the <AdditionalLibraryDirectories>
section in the first place.
https://github.com/conan-io/conan/pull/5564#issuecomment-521548338
Thanks,
Sam
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (6 by maintainers)
Thanks very much for the rapid response on this guys, it is much appreciated!
Yeah, I agree. The original pull request btw didn’t add
<AdditionalDependencies>
in<Lib>
, it was added based on additional suggestion.