[CMake] Dependency cycle - why?

Sat May 25 10:47:05 EDT 2019

Le sam. 25 mai 2019 à 13:51, Bill Somerville <bill at classdesign.com> a
écrit :

> Hi Robert,
>
> thanks for that, the target name change does seem to help but I am still
> unable to achieve my goal. Here is a simplified example that demonstrates
> the problem:
>
> cmake_minimum_required (VERSION  3.1.0 FATAL_ERROR)
> project (demo LANGUAGES NONE)
> add_custom_target (prog_target COMMAND ${CMAKE_COMMAND} -E touch prog${CMAKE_EXECUTABLE_SUFFIX})
> add_executable (prog IMPORTED)
> add_dependencies (prog prog_target)
> set_target_properties (prog PROPERTIES IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/prog${CMAKE_EXECUTABLE_SUFFIX})
> install (TARGETS prog RUNTIME DESTINATION bin)
>
> which gives the following error at CMake configuration:
>
> CMake Error at CMakeLists.txt:7 (install):
>   install TARGETS given target "prog" which does not exist.
>
>
> -- Configuring incomplete, errors occurred!
>
> So the target that 'add_executable(name IMPORTED)' creates is not a real
> executable target. I can change its properties but the 'install(TARGETS
> ...)' command thinks it does not exist. Note that a executable target is a
> very simple demonstration and I understand that I can use 'install(PROGRAM
> ...)' just about as easily, but when it comes to a shared library it gets a
> lot more complex when using, exporting, and instlling it, and it seems that
> IMPORTED targets fall well short of useful when they are actually produced
> by the current CMake project.
>
> I can understand that an IMPORTED target is perhaps not meant to be
> installable
>

Robert will give his advice on that but I bet IMPORTED target were never
meant to be drop-in *replacement* of genuine target.

They were meant to ease *reference to* object/lib:executable that are
outside the build of the project.
e.g the doc says:
https://cmake.org/cmake/help/latest/command/add_library.html#imported-libraries
"An IMPORTED library target references a library file located outside the
project"

Nmelly a target that is "already installed somewhere" and that you want to
reference in your CMake build.

> but if so then your statement that "The goal that you have is fully
> supported by CMake" seems to be incorrect. To reiterate, I am trying to use
> foreign tools to make binary targets and wish to have CMake treat them *as
> if* they were created by supported languages like C, ++, or Fortran. Am I
> still missing something?
>

My opinion is that IMPORTED target are not designed (as of today) for that
purpose.

When you want to do what you seem to want you need to either:
1) add a "new LANGUAGE" (you seem to be willing to add golang)
    see:
https://stackoverflow.com/questions/7978517/how-do-i-get-cmake-to-work-with-the-go-programming-language
    and may be: https://github.com/aadidenko/golang-cmake-example (or fork
of this)

2) define a set of custom macros that mimic genuine target behaviour.
    may be see: https://github.com/cpconduce/go_cmake

If you want to have a look at existing similar example shippped with CMake,
have a look at UseJava.cmake module (
https://cmake.org/cmake/help/latest/module/UseJava.html)
You'll see that you have
add_jar, which is similar to add_executable and create a custom target
and
install_jar which is similar to install on genuine target but plays with
target properties and install(FILES...) in order to mimic that.
see: https://github.com/Kitware/CMake/blob/master/Modules/UseJava.cmake

I'm not developing with golang but AFAIK go has a builtin "build system" so
bringing go as a language in CMake may not be the best option,
but again I am no Go expert.

The only reference of that kind of thing I found in the CMake mailing list
is oldish:
https://cmake.org/pipermail/cmake-developers/2011-August/013715.html

May be adding the support for "install" command for IMPORTED target is
doable but this seems to be a feature request to be discussed on developer
mailing list;
Regards,
Eric

> Regards
> Bill Somerville.
>
> On 24/05/2019 20:23, Robert Maynard wrote:
>
> Hi,
>
> The goal that you have is fully supported by CMake. You have just run
> into a bug in CMake, and you should report this tohttps://gitlab.kitware.com/cmake/cmake/issues .
> Basically at a very high level the name out the add_executable target
> `callback_generator` is the same as the internal name that CMake is
> using for the add_custom_command. This than causes some logic in CMake
> (cmTargetTraceDependencies) to incorrectly build another link between
> the add_custom_command and your add_executable.
>
> The easiest way to solve this issue is name the add_executable target
> to have a different name than the output of your custom command minus
> file extension. So maybe something like  `callback_generator_exec`
>
> On Fri, May 24, 2019 at 2:02 PM Bill Somerville <bill at classdesign.com> <bill at classdesign.com> wrote:
>
> On 13/05/2019 12:03, Bill Somerville wrote:
>
> Hi folks,
>
> I am struggling to understand what the problem is with this:
>
> find_program (GO go)
> set (GOPATH "${CMAKE_CURRENT_BINARY_DIR}/go")
> file (MAKE_DIRECTORY ${GOPATH})
>
> set (sources ${CMAKE_CURRENT_SOURCE_DIR}/callback_generator.go)
> set (build_command ${GO} build)
> set (output callback_generator${CMAKE_EXECUTABLE_SUFFIX})
> add_custom_command (OUTPUT ${output}
>   COMMAND ${CMAKE_COMMAND} -E env GOPATH=${GOPATH} CGO_CFLAGS=${CMAKE_CGO_CFLAGS} ${build_command} -o ${output} ${CMAKE_GO_FLAGS} ${sources}
>   DEPENDS ${sources}
>   VERBATIM)
> add_custom_target (callback_generator_target DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${output})
> add_executable (callback_generator IMPORTED)
> set_target_properties (callback_generator
>   PROPERTIES
>   IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${output}
>   )
> add_dependencies (callback_generator callback_generator_target)
>
> add_custom_target (server ALL DEPENDS callback_generator)
>
> which gives this error:
>
>
> cmake --version
>
> cmake --version
> cmake version 3.14.3
>
>
> cmake -G "MinGW Makefiles" ..\..
>
> cmake -G "MinGW Makefiles" ..\..
> -- Configuring done
> CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
>   "callback_generator_target" of type UTILITY
>     depends on "callback_generator_target" (strong)
> The component contains at least one cycle consisting of strong dependencies (created by add_dependencies) that cannot be broken.
>
> The set_target_properties () call seems to be part of the problem but I don't understand why.
>
> Regards
> Bill Somerville.
>
> Hi again,
>
> answering my own post since no one has replied. Clearly my question was too specific. Let me try again with a more general question. I have tools that can generate executables (programs, static libraries, and shared libraries, including DLL import libraries on MS Windows). These tools are not directly supported by CMake but they are both needed within a project that uses them and installs them as the project artefacts. How do I integrate, for example a shared library, into a CMake project as if it were produced by a supported toolchain like C or C++? The library is produced by an add_custom_target() command (not add_custom_command() since the underlying tools do their own dependency checking so it is right to run the target commands every build). I need to have a target that I can use in target_link_libraries() and install(TARGETS ...) just like one would with a CMake generated library made with add_library() and programs made with add_executable().
>
> If it helps the tools that are not supported by CMake are the Go language build tools. The project builds some Go programs as utilities but the main project artefact is a shared library with a C language API built using the cgo tools. There are many of C and C++ test programs and example programs as well in the project which need to link against the project shared library etc.
>
> Regards
> Bill Somerville.
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:https://cmake.org/mailman/listinfo/cmake
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190525/0dbfdca9/attachment.html>