Conan: Private requirements wrong if used with new CMake IMPORT

[d-schiffner]

Hi,

I have been using conan for a while now and was very excited using the "modern" CMake syntax

However, in my scenario, I generated several libraries, where one (A) is using lib C as a private requirement.

This library is then used within another lib (B) that also uses the same lib A

The CMake generator, however, wrongly identifies this as a necessary requirement for A as it should only be a dependency for B. This then breaks the compile step, as the order of libs is being inverted, resulting in unresolved dependencies (gcc).

I already found the code issue, but currently there is no "easy" solution to this. The cmake generator uses the existing dependencies to identify, whether the libs need to be introduced as CONAN_PKG targets.

Here it would be necessary, to identify "private" dependencies, as they are all being propageted during the generation step.

I would offer my help here, but have no idea where actually to start and how to implement it.

Best regards,

d-schiffner

[memsharded]

Yes, it is true, most likely it is a bug, as transitivity of targets is not considering private packages. Lets try to find a fix for it (I still don't know how either yet), I am scheduling it for 0.18. We will tell you after checking for a fix, in case you could try and test things with your projects. Thanks for reporting!

[memsharded]

Hi @d-schiffner !

I have been playing a bit with conan tests, those containing private dependencies, trying to make them fail with the modern cmake targets, but I haven't been able to make it fail.

I am using like a tree A->B->(private)->Cv0.1, and A->D->(private)->Cv0.2, which is a bit more complex of the setup you describe, and seems it should fail too.

I will keep investigating, but just in case, do you have any public (or private, by email), failing example that you could share with me? Thanks!

[memsharded]

I have spent a couple of hours more, trying different compilers and doing more tests, but still not able to reproduce it, if you could please provide a reproducible error, that would be great.

[d-schiffner]

Hi @memsharded,

I'm going to produce a minimal working example. Maybe its due to the fact, that in my scenario mainly static libs are being used. With dynamic linking, I don't think this bug will appear. But I will look into this as well.

And sorry for the late answer, have been kept busy during christmas and - as well - haven't been notified. Going to change this ;)

Best regards

[d-schiffner]

Hi @memsharded,

with the small test files in the conan project i'm also not able to reproduce the linker error. However, if you inspect the conanbuildinfo.cmake, you will find a link dependency on a private (statically linked) lib, which should not be present.

Cmake will drop those link targets, if the targeted library is also a static lib, but conan is currently only using the INTERFACE import.

I'll report back, once i found the issue in my larger project, can't tell, why the linker is going nuts (g++ 6)

[memsharded]

Hi @d-schiffner, no worries at all, thanks very much for your feedback, never late :)

I have been using mostly static linking too, because I also thought that it was more problematic, but didn't fail.

I will check the contents of conanbuildinfo.cmake, trying to find what you point out, will keep you updated. Also waiting for your feedback, but yeah, linking errors, specially about wrong ordering are quite annoying, difficult to debug and reproduce, so good luck!

Cheers

[memsharded]

I have been checking this, but in the conanbuildinfo.cmake everything seems fine. I am trying a Hello2->Hello1->(private)->Hello0. And I am getting this:

set(CONAN_PACKAGE_NAME Hello2)
set(CONAN_PACKAGE_VERSION 0.1)
set(CONAN_DEPENDENCIES Hello1)
set(CONAN_INCLUDE_DIRS "F:/tmpmqyf3cconans/path with spaces/.conan/data/Hello1/0.1/lasote/stable/package/ae3331b1280b2aee027ddffe1108ef3691d09ba5/include" ${CONAN_INCLUDE_DIRS})
set(CONAN_LIB_DIRS "F:/tmpmqyf3cconans/path with spaces/.conan/data/Hello1/0.1/lasote/stable/package/ae3331b1280b2aee027ddffe1108ef3691d09ba5/lib" ${CONAN_LIB_DIRS})
set(CONAN_BIN_DIRS "F:/tmpmqyf3cconans/path with spaces/.conan/data/Hello1/0.1/lasote/stable/package/ae3331b1280b2aee027ddffe1108ef3691d09ba5/bin" ${CONAN_BIN_DIRS})

So Hello2->Hello1 but is free of any reference to Hello0.
I keep investigating.

[d-schiffner]

Hi @memsharded,

this only happens, if You create the scenario i depicted.
Example:
Hello2 -> Hello1 and Hello 0 and Hello1 -> (private) Hello 0

Actual Example:
LibA using Glew (private)
ExampleApp uses LibA and Glew
->
LibA has dependency on Glew

    add_library(CONAN_PKG::gf INTERFACE IMPORTED)
    set_property(TARGET CONAN_PKG::gf PROPERTY INTERFACE_LINK_LIBRARIES ${CONAN_FULLPATH_LIBS_GF} CONAN_PKG::glew CONAN_PKG::glm CONAN_PKG::libpng CONAN_PKG::zlib)
    set_property(TARGET CONAN_PKG::gf PROPERTY INTERFACE_INCLUDE_DIRECTORIES ${CONAN_INCLUDE_DIRS_GF})
    set_property(TARGET CONAN_PKG::gf PROPERTY INTERFACE_COMPILE_DEFINITIONS ${CONAN_COMPILE_DEFINITIONS_GF})
    set_property(TARGET CONAN_PKG::gf PROPERTY INTERFACE_COMPILE_OPTIONS ${CONAN_CFLAGS_GF} ${CONAN_CXX_FLAGS_GF})
    set_property(TARGET CONAN_PKG::gf PROPERTY INTERFACE_LINK_FLAGS ${CONAN_SHARED_LINKER_FLAGS_GF} ${CONAN_EXE_LINKER_FLAGS_GF}

Where as gf is has following requirements (conanfile.py)
requires = (("glm/0.9.8.3@dschiffner/stable"), ("glew/2.0.0@dschiffner/stable", "private")

Edit:
The libpng requirement on gf is ok, as it is added during config by a flag

[memsharded]

Spotted a possible problem of re-building same package binary, because being private: https://github.com/conan-io/conan/pull/809 Probably it failed only in Windows, due to resource-handling, but the fact is that it is trying to rebuild the private package binary, even if the package ID (hash) is the same as the public. It shouldn't.

Can you confirm that in your case, the "Hello0" package si being built from source twice?

[d-schiffner]

Yep, it actually tries to compile it twice, but fails as it does not get the lock of the file. I can force it by building it explicitly, but still get the linker error.

Maybe this is a bug from CMake, i can't tell for sure. Because both glew's are referenced, but only one is inserted into the linker process. I'll track this down in this direction.

[memsharded]

I think is some file resource/handle that is not closed, and the second time the package is to be built, it tries first to clean and cannot do it because the resources is busy. So it is another bug. It can be solved by analyzing the packages to build and making sure that they are not built twice, even if private. This is what I am trying to do in my PR#809. Will try to fix this first, and then we will proceed to check the linkage.

Thanks again for your help, really helpful to improve this.

[d-schiffner]

Don't worry about this bug.
The current workaround is to remove one hello lib in the cmake targets and everything compiles fine.

I'll provide a MWE as soon as i found the reason why the linker fails in this very scenario.

[d-schiffner]

Hi @memsharded,

finally got back to the issue.
It seems, that cmake treats the libs differently based on how the imported type is defined.

Here some excerpts from my findings:

# Import with current state of conan
# Target : target_link_libraries(ImGuiTets CONAN_PKG::glew CONAN_PKG::gf CONAN_PKG::imgui)
# Link FAILS
  LINK_LIBRARIES = C:/Users/Daniel/.conan/data/glew/2.0.0/dschiffner/stable/package/105fcc8e32550403cc8f9386cee506e4701eda0d/lib/libglew32.a 
  -lopengl32 
  C:/Users/Daniel/.conan/data/gf/1.6.4/dschiffner/stable/package/e8b0dff25c5caae34575b8aa8b5e848d7ff9978a/lib/libgfs.a 
  -lgdiplus 
  C:/Users/Daniel/.conan/data/libpng/1.6.26/dschiffner/stable/package/b894d73ff3d3034410dc83296af009eec0761ef4/lib/libpng16.a 
  C:/Users/Daniel/.conan/data/zlib/1.2.8/dschiffner/stable/package/105fcc8e32550403cc8f9386cee506e4701eda0d/lib/libzlibstatic.a 
  C:/Users/Daniel/.conan/data/imgui/1.49/dschiffner/stable/package/105fcc8e32550403cc8f9386cee506e4701eda0d/lib/libimgui.a 
  -limm32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

# Manual fix using STATIC IMPORTED targets
# target_link_libraries(ImGuiTest CONAN_PKG:glew CONAN_PKG::gf CONAN_PKG::imgui)
# Link SUCCEEDS
  LINK_LIBRARIES = C:/Users/Daniel/.conan/data/glew/2.0.0/dschiffner/stable/package/105fcc8e32550403cc8f9386cee506e4701eda0d/lib/libglew32.a 
  C:/Users/Daniel/.conan/data/gf/1.6.4/dschiffner/stable/package/e8b0dff25c5caae34575b8aa8b5e848d7ff9978a/lib/libgfs.a 
  C:/Users/Daniel/.conan/data/glew/2.0.0/dschiffner/stable/package/105fcc8e32550403cc8f9386cee506e4701eda0d/lib/libglew32.a 
  -lopengl32 
  -lgdiplus 
  C:/Users/Daniel/.conan/data/libpng/1.6.26/dschiffner/stable/package/b894d73ff3d3034410dc83296af009eec0761ef4/lib/libpng16.a 
  C:/Users/Daniel/.conan/data/zlib/1.2.8/dschiffner/stable/package/105fcc8e32550403cc8f9386cee506e4701eda0d/lib/libzlibstatic.a 
  C:/Users/Daniel/.conan/data/imgui/1.49/dschiffner/stable/package/105fcc8e32550403cc8f9386cee506e4701eda0d/lib/libimgui.a 
  -limm32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

# Workaround for current solution
# target_link_libraries(ImGuiTest CONAN_PKG::gf CONAN_PKG::imgui)
# LINK SUCCEEDS
  LINK_LIBRARIES = C:/Users/Daniel/.conan/data/gf/1.6.4/dschiffner/stable/package/e8b0dff25c5caae34575b8aa8b5e848d7ff9978a/lib/libgfs.a 
  -lgdiplus 
  C:/Users/Daniel/.conan/data/glew/2.0.0/dschiffner/stable/package/105fcc8e32550403cc8f9386cee506e4701eda0d/lib/libglew32.a 
  -lopengl32 
  C:/Users/Daniel/.conan/data/libpng/1.6.26/dschiffner/stable/package/b894d73ff3d3034410dc83296af009eec0761ef4/lib/libpng16.a 
  C:/Users/Daniel/.conan/data/zlib/1.2.8/dschiffner/stable/package/105fcc8e32550403cc8f9386cee506e4701eda0d/lib/libzlibstatic.a 
  C:/Users/Daniel/.conan/data/imgui/1.49/dschiffner/stable/package/105fcc8e32550403cc8f9386cee506e4701eda0d/lib/libimgui.a 
  -limm32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

Note that in the first scenario only one glew is present. This was the reasoning behind hiding one static lib as private, because i tried to _move_ the glew32 behind the gf, so that it would link. Thus i added private to the gf dependency on glew, but it is still present (thus filiing the bug)

The correct way would be to create STATIC or SHARED imported libraries, but I know this is kinda hard, as you have to identify each import seperately.

I had a working solution back for conan 0.10, but it was necessary to add the static/shared info to the conanfiles (all of them). Not very convincing for me, though.

I tracked down, why the lib is being added, despite being private:
The conan cmake generator uses in line 101 existing_deps and generates in line 109 the individual targets.

The gf package (in my scenario) has a dependency on glew andglewis in the list of theexisting_deps, thusglewis added to theCONAN_PKG::gfdespite being private. This info is not present in thedep_info.deps` on line 110, as it only lists the libraries, but not their requirement state

So far my findings.

If you want, I can try to add the required info there, but I would ask for a place to start (looked into DepsGraphBuilder ...), but couldn't find a good starting point.

Thx and greetings (Sorry for the long post)

[memsharded]

Thanks very much for detailed feedback. Will carefully read it now.

I had a working solution back for conan 0.10, but it was necessary to add the static/shared info to the conanfiles (all of them). Not very convincing for me, though.

The problem is that packages cannot be defined as only static or shared. Some are header only. Some are just data resources, some are python helpers to be reused, some are generators. Even for C/C++ libs, there are packages that have several libs inside, and even some of them mixed (some shared and some static). What is internal in a package, is difficult to be managed from the outside. Maybe the underlying issue is that those libraries should be in different inter-dependents packages, but that is another story.

[memsharded]

Just curiosity, why your LibA has a private dependency to Glew? Private dependencies in C/C++ can be defined only in a few situations (shared lib linking static, without exposing public interface, or static linking header-only without exposing public interface). Also, it is very important to be sure that data objects moving accross boundaries do not break compatibility, for example between different versions of the same library. Note that private paths can take to different instances of binary code in the application, which can be equal, different but compatible or even incompatible.

[d-schiffner]

Hi @memsharded,

I know right, regarding both statements. To the former:
It would introduce a strong dependency on cmake, which was fine for my/our solution, as we're only using those. Header Only Libraries are the INTEFRACE targets. I restructured all my packages to be include only one lib, otherwise they are split into different packages.

Regarding the second topic:
You're right, and it is more like stumpling upon the bug. All libraries are indeed public, but as I mentioned before, is was trying to "move" the dependency of glew farther behind (after libgfs), to satisfy the linker. Then I noticed that the package with private glew was still introducing the dependency to glew, which should not happen -> hence the issue.

[memsharded]

BTW, I am handling this issue here: https://github.com/conan-io/conan/pull/809

[memsharded]

I continue working on this, @d-schiffner reviewing the thread I have one question: are you then using private dependencies trying to workaround the dependencies order? If the first example the dependencies were: ImGuiTets CONAN_PKG::gf CONAN_PKG::glew CONAN_PKG::imgui would it work? In that case, we should focus on solving the wrong order issue first, then we could revisit the private one. What is the full graph of dependencies (-> depends on)?

ImGuiTests -> ?
gf->glew
gf->imgui

I have been trying several configurations more, and cannot reproduce a wrong order in link targets, also the private ones are conveniently hidden.
Another way could be if you send me your recipes (zipped, by email), and I will replicate here your full project. Also, it could be useful to be able to do some more interactive (chat) debugging, if you want access to our experimental slack channel, please tell.

[memsharded]

Good news, I have been able to replicate a wrong order, using a private dependency. Actually I have realized that it kind of makes sense, because the issue is that it cannot be a private dependency if we are linking statically. Private dependencies can only be properly defined for really private dependencies, like:

• Shared library linking static or header only without public interface
• Static library linking header only without public interface

Looking forward your feedback regarding the above. We might move the release forward, this potential bug might not be included, but if we are able to properly solve it, we will consider releasing a minor.

[d-schiffner]

Hi @memsharded,

actually the first thing i tried was to reorder in CMake. But i seems that CMake does not honor the order of INTERFACE dependencies.

You are totally right, you cannot statically link AND use private dependencies, as you need to link to the static lib. However, due to the wrong order, i tried to reorder (mentioned above), but i didn't work.

Here the full deps list:

Dependencies:

ImGuiTest ->glew
ImGuiTest -> basic
ImGuiTest -> gf
ImGuiTest -> glm (header only)
ImGuiTest -> f5
ImGuiTest -> imgui
gf -> glew
gf -> glm (header only)
gf -> libpng
libpng -> zlib

This wrong order can (only?) be solved by 2 approaches:

First:
Add info of static lib to the cpp_info (its a cpp info which actually knows what a static or dynamic or header only lib is)

Second: (Current working solution)
Remove the double dependency from the combining lib (ImGuiTest in this case). Then it won't be reordered and is placed after libgf in the compiler process, allowing correct linking.

As I said before, I am more than willing to provide the first solution to the reorder bug. But this should be discussed in a different thread.

[memsharded]

Mi PR fixing the issue of re-building twice the same package (for private dependencies) has been merged, and is already in develop, will be released in today 0.18 release.

I am still having some issues to fully understand what is happening, so I propose using some tests to figure out partial issues, and move forward. No problem that it is not on time for today release, if we are able to solve it, we will consider a minor.

So my first test would be this one:
https://github.com/conan-io/conan/blob/develop/conans/test/integration/private_deps_test.py#L39

The test is not really building, so it is fast, but I have also tried to build and link basic "hello" static libraries and algo works (mingw gcc 4.9)

It is using public dependencies, and a dependency graph resembling your dependencies (I just removed those that shouldn't affect, like f5 and basic). From what is defined in the test, the order of dependencies is defined as:

 set_property(TARGET CONAN_PKG::ImGuiTest PROPERTY INTERFACE_LINK_LIBRARIES 
                      ${CONAN_FULLPATH_LIBS_IMGUITEST} CONAN_PKG::gf CONAN_PKG::imgui
                      CONAN_PKG::glew CONAN_PKG::glm CONAN_PKG::libpng CONAN_PKG::zlib)

It seems good to me. Is this ordering of dependencies wrong?

[d-schiffner]

It looks correct so far.

I'm going to pull the current development version on tomorrow and have a more indepth look.

[memsharded]

We have released this in conan 0.18, in case you want to test the latest release. Keeping the issue open, until we solve it completely.

[d-schiffner]

Thx, i just pulled it.

The dependencies look out of the box very promising. I played around a bit, and noticed, that the dependencies are always ordered by alphabet. You actually cannot change the order within a conanfile

The current test for me looks like:

self._export("gf", "0.1", deps=["glm/0.1@lasote/stable",
                                "libpng/0.1@lasote/stable",
                                "glew/0.1@lasote/stable"
                                ])
self._export("ImGuiTest", "0.1", deps=["glew/0.1@lasote/stable",
                                       "gf/0.1@lasote/stable",
                                       "glm/0.1@lasote/stable",
                                       "imgui/0.1@lasote/stable"])


self.assertIn("CONAN_PKG::gf PROPERTY INTERFACE_LINK_LIBRARIES "
              "${CONAN_FULLPATH_LIBS_GF} CONAN_PKG::glm CONAN_PKG::glew "
              "CONAN_PKG::libpng CONAN_PKG::zlib", conanbuildinfo_cmake)
self.assertIn("CONAN_PKG::ImGuiTest PROPERTY INTERFACE_LINK_LIBRARIES "
              "${CONAN_FULLPATH_LIBS_IMGUITEST} CONAN_PKG::gf CONAN_PKG::imgui "
              "CONAN_PKG::glm CONAN_PKG::glew CONAN_PKG::libpng CONAN_PKG::zlib",
              conanbuildinfo_cmake)

And it thows an assertion error as the generated conanbuildinfo.cmake contains the followin:

set_property(TARGET CONAN_PKG::ImGuiTest PROPERTY INTERFACE_LINK_LIBRARIES ${CONAN_FULLPATH_LIBS_IMGUITEST} CONAN_PKG::gf CONAN_PKG::imgui CONAN_PKG::glew CONAN_PKG::glm CONAN_PKG::libpng CONAN_PKG::zlib)   
...
set_property(TARGET CONAN_PKG::gf PROPERTY INTERFACE_LINK_LIBRARIES ${CONAN_FULLPATH_LIBS_GF} CONAN_PKG::glew CONAN_PKG::glm CONAN_PKG::libpng CONAN_PKG::zlib)

If I do add the private dep in gf to any lib (here to be more static link friendly, I exclude the glm header only lib)

self._export("gf", "0.1", deps=[("glm/0.1@lasote/stable", "private"),
                                "libpng/0.1@lasote/stable",
                                "glew/0.1@lasote/stable"
                                ])

I do get the issue in the generated conanbuildinfo.cmake:

set_property(TARGET CONAN_PKG::gf PROPERTY INTERFACE_LINK_LIBRARIES ${CONAN_FULLPATH_LIBS_GF} CONAN_PKG::glew CONAN_PKG::glm CONAN_PKG::libpng CONAN_PKG::zlib)
...
set_property(TARGET CONAN_PKG::ImGuiTest PROPERTY INTERFACE_LINK_LIBRARIES ${CONAN_FULLPATH_LIBS_IMGUITEST} CONAN_PKG::gf CONAN_PKG::glm CONAN_PKG::imgui CONAN_PKG::glew CONAN_PKG::libpng CONAN_PKG::zlib)

i.e. the gf lib still contains the glm dependency, which should not be here

[d-schiffner]

Hi @memsharded,

just being active right now ;)

Just out of curiosity I added the following cmake targets in the Project generated during the unit tests (i'm not so deep into the python unit testing framework of yours, sorry):

add_executable(depLib hello.cpp)
target_link_libraries(depLib CONAN_PKG::glew CONAN_PKG::gf CONAN_PKG::imgui)
add_executable(depLib2 hello.cpp)
target_link_libraries(depLib2 CONAN_PKG::gf CONAN_PKG::glew CONAN_PKG::imgui)

and generated it on unix with the Unix Makefile Generator

Here is the output of grep -r helloglew . in the folder:

./CMakeFiles/depLib.dir/link.txt:/usr/bin/c++      CMakeFiles/depLib.dir/hello.cpp.o  -o bin/depLib -rdynamic -lhelloglew -lhellogf -lhelloglm -lhellolibpng -lhellozlib -lhelloimgui
./CMakeFiles/depLib2.dir/link.txt:/usr/bin/c++      CMakeFiles/depLib2.dir/hello.cpp.o  -o bin/depLib2 -rdynamic -lhelloglew -lhellogf -lhelloglm -lhellolibpng -lhellozlib -lhelloimgui
./CMakeFiles/say_hello.dir/link.txt:/usr/bin/c++      CMakeFiles/say_hello.dir/main.cpp.o  -o bin/say_hello -rdynamic lib/libhelloProject.a -lhelloImGuiTest -lhellogf -lhelloglm -lhelloimgui -lhelloglew -lhellolibpng -lhellozlib
./conanbuildinfo.cmake:set(CONAN_LIBS_GLEW helloglew)
./conanbuildinfo.cmake:set(CONAN_LIBS helloImGuiTest hellogf helloglm helloimgui helloglew hellolibpng hellozlib ${CONAN_LIBS})

I think, because both executables have dependencies on glew and on gf, glew is considered higher and is moved in front of gf by cmake. There is no way of influencing the order by reordering the dependencies.

[d-schiffner]

I further minimized the example, to the minimal failing configuration:

self._export("glew", "0.1")
self._export("glm", "0.1")
self._export("gf", "0.1", deps=[("glm/0.1@lasote/stable", "private"),
                                    "glew/0.1@lasote/stable"])

self._export("ImGuiTest", "0.1", deps=["glm/0.1@lasote/stable",
                                        "gf/0.1@lasote/stable"])

# Consuming project
self._export("Project", "0.1", deps=["ImGuiTest/0.1@lasote/stable"])

# Build packages for both recipes
self.client.run('install . --build=missing')
conanbuildinfo_cmake = load(os.path.join(self.client.current_folder,
                                            "conanbuildinfo.cmake"))

self.assertIn("CONAN_PKG::gf PROPERTY INTERFACE_LINK_LIBRARIES "
                "${CONAN_FULLPATH_LIBS_GF} CONAN_PKG::glew", conanbuildinfo_cmake)
self.assertIn("CONAN_PKG::ImGuiTest PROPERTY INTERFACE_LINK_LIBRARIES "
                "${CONAN_FULLPATH_LIBS_IMGUITEST} CONAN_PKG::glm CONAN_PKG::gf CONAN_PKG::glew",
                conanbuildinfo_cmake)

It clearly states, that glm is a private dependency of gf, but it is introduced as a dependency in the consuming project.

I get this output:

set_property(TARGET CONAN_PKG::ImGuiTest PROPERTY INTERFACE_LINK_LIBRARIES ${CONAN_FULLPATH_LIBS_IMGUITEST} CONAN_PKG::gf CONAN_PKG::glm CONAN_PKG::glew)
set_property(TARGET CONAN_PKG::gf PROPERTY INTERFACE_LINK_LIBRARIES ${CONAN_FULLPATH_LIBS_GF} CONAN_PKG::glew CONAN_PKG::glm)

[memsharded]

The assertion that is failing (the second one) seems wrong, the correct order for ImGuiTest is gf, glm, glew, so the actual output (first line) is right, isn't it? Changing that in the test gets a green test.

The glm is added to ImGuiTest, because you are actually adding it directly as a dependency of ImGuiTest! No matter if private for gf, it is direct dependency of ImGuiTest. Could you please check again your latest code for the test? :) :)

It is possible that cmake is having issues ordering libs within targets, but lets try to find out if at least conan is providing the targets in order, and those that should be listed. Thanks for your great efforts!

[d-schiffner]

The first one was supposed to fail ;) My bad, was missing the closing bracket...

Here a correct version of the first assert:

self.assertIn("CONAN_PKG::gf PROPERTY INTERFACE_LINK_LIBRARIES "
                "${CONAN_FULLPATH_LIBS_GF} CONAN_PKG::glew)", conanbuildinfo_cmake)

Regarding the second: As glm is the first dependency of ImGuiTest, shouldn't it be the first dependency to show up in the list?

[memsharded]

You are right about the first, I'll have a look.

The second, no, as glm is a dependency of gf, in the list it should be after gf, even if it is the first declaration in ImGuiTest dependencies. So it seems fine as is.

[memsharded]

That is right, it is not handling private deps properly. But so far it seems that the order of dependencies is right. I am trying, but doesn't seem an easy fix.

Meanwhile, that takes me to an important question: why gf has a private dependency to glm? Why a normal dependency is not enough? Private dependencies are tricky, and should be use very cautiously and only when strictly necessary, for example, when it is necessary to depend on different incompatible versions of the same package, and the dependencies can be fully embeddable.

In your case, being glm header only, I guess that gf doesn't have any "#include" to glm headers in the public headers of gf, only in .cpp files and in private headers, is that right?

[d-schiffner]

Hi @memsharded,

like in the thread already discussed multiple times, i was trying to use private dependencies to fix the cmake order. Don't think too much about the reason behind it.

Long story short: If the dependency is private, it is wrong to reintroduce it there.

[memsharded]

Good, I have a potential fix, might try to introduce it in a minor 0.18.1, but have to do some extra checks, I am concerned about breaking things. I'll keep you updated!

[memsharded]

I have submitted a PR: https://github.com/conan-io/conan/pull/833, lets see what happens...

@d-schiffner It would be very useful if you could try running conan from source code from my branch and test with your project: https://github.com/memsharded/conan/tree/feature/fix_cmake_targets_private

[d-schiffner]

Thx, i will give it a try and report back

[d-schiffner]

Hi @memsharded,

yep, this fixes the issue.

I think i'll open up a new issue, regarding the static link order stuff. I have some ideas, but this needs some discussion

[memsharded]

Great! :) Thanks for telling.
Good, go open another issue, and we will continue there. I hope this goes into 0.18.1, I'll label it as fixed when merged and close when released, stay tuned!

[memsharded]

This fix has been released in 0.18.1, please update and re-open and report if necessary.