[cmake-developers] [PATCH] cmNinjaTargetGenerator: Create files to satisfy pending-creation imported libs

[Sam Spilsbury]

Ninja evaluates all dependencies before building any targets unlike
other generators, so if a file forming part of a dependency rule does
not exist then this is a fatal error for Ninja. These files might be
created as
part of the build process (and not custom commands) so if the user
imports a library target with add_library (... IMPORTED) and the path
to that target is within the build directory, then just touch the file
and assume it will be created later.

Added ImportedExternalProjectLibrary, which builds a library in a sister
subdirectory to an executable as an external project, the alternate
sister subdirectory adding the library as an IMPORTED library
depending on the external project and linking to it.

Fixes #13574.
---
 Source/cmNinjaTargetGenerator.cxx                  | 37 ++++++++++++++++++++++
 Tests/CMakeLists.txt                               |  1 +
 .../ImportedExternalProjectLibrary/CMakeLists.txt  |  5 +++
 .../CMakeLists.txt                                 |  3 ++
 .../ImportedExternalProjectLibrary.c               |  6 ++++
 .../LibrarySubdir/CMakeLists.txt                   | 17 ++++++++++
 .../ProjectWithImportedLibrary/CMakeLists.txt      |  4 +++
 .../ProjectWithImportedLibrary/library.c           |  4 +++
 9 files changed, 79 insertions(+), 2 deletions(-)
 create mode 100644 Tests/ImportedExternalProjectLibrary/CMakeLists.txt
 create mode 100644
Tests/ImportedExternalProjectLibrary/ImportedExternalProjectLibraryDir/CMakeLists.txt
 create mode 100644
Tests/ImportedExternalProjectLibrary/ImportedExternalProjectLibraryDir/ImportedExternalProjectLibrary.c
 create mode 100644
Tests/ImportedExternalProjectLibrary/LibrarySubdir/CMakeLists.txt
 create mode 100644
Tests/ImportedExternalProjectLibrary/LibrarySubdir/ProjectWithImportedLibrary/CMakeLists.txt
 create mode 100644
Tests/ImportedExternalProjectLibrary/LibrarySubdir/ProjectWithImportedLibrary/library.c

I'm not particularly keen on this implementation, but it was the best
thing I can think of for now. The trade off is that marking a target
as IMPORTED doesn't necessarily mean the user is generating it and we
end up calling the linker against a plain-text file, which results in
a rather cryptic error message.

The problem here is that Ninja does all its dependency scanning before
building any targets, unlike other generators which do it once the
target is reached. Thus if an IMPORTED library is being created as
part of using ExternalProject_Add, then the Ninja generator will get
upset and refuse to run.

Another solution is to create a utility rule to "create" the library,
but then it needs to be attached to something anyways and you get the
same problem if the library is never actually built before others link
to it.

Another solution would be to omit adding dependencies where the file
does not exist. This is inconsistent between builds though - as the
file will exist after the build has taken place.

Broader context: This prevents me from using ExternalProject_Add with
the Ninja generator generally. I use ExternalProject_Add for one of my
other projects[1] and having Ninja support back would be really nice.

[1] https://github.com/polysquare/gmock-cmake

-- 
Sam Spilsbury
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cmNinjaTargetGenerator-Create-files-to-satisfy-pendi.patch
Type: application/octet-stream
Size: 8186 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140607/5a7a313a/attachment.obj>