order of dependencies about cdep HOT 2 CLOSED

Unfortunately, this problem is difficult to tackle with the way CMakeGenerator currently uses the CMake logic.
The core problem is we're using target_link_libraries recursively which doesn't provide a mechanism to tell CMake how to build a dependency graph.
Concretely, this is what CMakeGenerator builds:
if(CMAKE_SYSTEM_NAME STREQUAL "Android")
if(CMAKE_SYSTEM_VERSION GREATER 20)
if(cdep_determined_android_abi STREQUAL "x86_64")
add_cdep_boringssl_dependency(${target})
add_cdep_zlib_dependency(${target})
execute_process(COMMAND /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -classpath /home/swinston/.cdep/bootstrap/downloads/-1010138560/cdep-0.8.22.jar io.cdep.CDep --working-folder /mount/120g/temp/. fetch-archive com.github.gpx1000:curl:7.56.0 file:/mount/120g/temp/curlUpload/curl-x86_64.zip 2084333 03a716990b06ddffacacb844a759b9e9d8605ef8c5d5d9ac6fbb9414fe83e839)^M
target_link_libraries(${target} "${exploded_archive_folder}/curl-x86_64.zip/lib/x86_64/libcurl.a")

Now the problem is both add_cdep_boringssl_dependency and add_cdep_zlib_dependency will similarly issue a target_link_libraries call so in effect this is the same thing as if one were to write this in a cmakelists.txt file:
target_link_libraries(${target} /libssl.a)
target_link_libraries(${target} /libz.a)
target_link_libraries(${target} /libcurl.a)

The bug is this prevents cmake from realizing that the dependency graph should note that curl depends upon z and ssl.
To fix this, I'd suggest the following ideas:
1.) switch to declaring each as a taget with add_library:
add_library( libName STATIC IMPORTED );
set_target_properties( libName PROPERTIES IMPORTED_LOCATION visit(LibraryPath) INTERFACE_INCLUDE_DIRECTORIES specific.includePath)
Then if any dependencies are noticed:
target_link_libraries( libName recursiveLibNameList )
target_link_libraries( ${target} libName )
or concretely (I've already implemented this version):
if(CMAKE_SYSTEM_NAME STREQUAL "Android")
if(CMAKE_SYSTEM_VERSION GREATER 20)
if(cdep_determined_android_abi STREQUAL "armeabi")
execute_process(COMMAND "java" )
add_library(libcurl STATIC IMPORTED )
set_target_properties(libcurl PROPERTIES IMPORTED_LOCATION "${exploded_archive_folder}/curl-armeabi.zip/lib/armeabi/libcurl.a")
target_link_libraries(libcurl ssl crypto z)
target_link_libraries(${target} libcurl)

The downside of this method is it ads in lots of targets to an already existing project; which might have issues with stepping on already allocated names from elsewhere.
An alternative solution would be similar to this:
2.) Reuse the package logic found here:
https://cmake.org/cmake/help/v3.7/manual/cmake-packages.7.html
This can probably work in addition to the first solution, it would make sense to consider placing the generated package into a cmake folder in the same directory as the CMakeLists.txt that calls the package. Changing the path to make it more visible would encourage a solution for not stepping on target names. Also keeping it as a separate project allows the dependency graph in CMake to handle things like circular dependencies correctly.

from cdep.

This issue is addressed. In PR #52

from cdep.