[CMake] ExternalProject_Add + imported targets: no rule to make yourlibrary.so

[SnakE]

Hello,

I think I've found a bug in the ninja generator. I wonder if it's fixed
already in a more recent cmake version.

I'm using cmake 3.3.1. My project uses ExternalProject_Add() to pull some
pre-built binaries from an internal repository in some configurations. In
other configurations however that same dependency may be picked from the
system, and yet in other configurations it is built from sources. So I want
to unify the usage by only requiring the user code to do
target_link_libraries().

I'm trying to utilize imported targets to achieve that. But I get errors
immediately after I run the build before any download can happen.

Here's a very simple CMakeLists.txt which allows to reproduce this on
Linux. The foo_file target imitates downloading. You'll need to provide
some trivial main.c, like "main() { return 0; }". If generated with the
Makefile generator the build starts and then fails with an expected error:
foo.so is indeed not a proper shared object. But if I generate for Ninja
the build fails immediately with the error: "ninja: error: 'foo.so', needed
by 'bar', missing and no known rule to make it"

------8<----CMakeLists.txt----------------------
cmake_minimum_required(VERSION 3.2)
add_custom_target(foo_file COMMAND ${CMAKE_COMMAND} -E touch foo.so)
add_library(foo SHARED IMPORTED)
add_dependencies(foo foo_file)
set_target_properties(foo PROPERTIES IMPORTED_LOCATION foo.so)
add_executable(bar main.c)
target_link_libraries(bar foo)
------8<----------------------------------------------

Should I file a bug report, or just switch to a newer CMake version?

Thanks,
SnakE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160428/daa8d61b/attachment.html>