Le sam. 25 mai 2019 à 13:51, Bill Somerville <b...@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 <b...@classdesign.com>
> <b...@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
--
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
