MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013538CMakeCMakepublic2012-09-14 08:462015-01-05 08:39
ReporterMiguel FIGUEIREDO 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionduplicate 
Platformx86_64OSGNU/LinuxOS VersionUbuntu 12.04
Product VersionCMake 2.8.9 
Target VersionFixed in Version 
Summary0013538: Ninja: Generated 'build.ninja' seems to be incomplete and fails to build ExternalProjects.
DescriptionI'm building proprietary components and 3rd parties components using "ExternalProject" : sqlite3, ezxml and Cunit.

My build succeed when I use a "Unix/Makefiles" generator and fails with "Ninja" generator with the following error message :
"ninja: error: 'vendor/ezxml/staging/lib/libezxml.a', needed by 'vodaccess_depends.c', missing and no known rule to make it".

When I run 'ninja -d explain' into cmake directory, I got :
"[...]
ninja explain: vendor/ezxml/staging/lib/libezxml.a has no in-edge and is missing
ninja explain: vendor/cunit/staging/lib/libcunit.a has no in-edge and is missing
ninja explain: vendor/sqlite3/staging/lib/libsqlite3.a has no in-edge and is missing
[...]"
corresponding to my ExternalProjects.
Steps To ReproduceSorry, I do not reproduce the problem outside my environment yet.

Note that I was able to build my ExternalProjects (in standalone) outside my build environment.
Additional InformationI hacked the generated 'build.ninja' file with the following lines :

"build vendor/ezxml/staging/lib/libezxml.a : phony vendor/ezxml/ezxml
build vendor/cunit/staging/lib/libcunit.a : phony vendor/cunit/cunit
build vendor/sqlite3/staging/lib/libsqlite3.a : phony vendor/sqlite3/sqlite3", and the build proceeds.
TagsNo tags attached.
Relationships
related to 0014963closed Brad King Add explicit specification of custom command side effect outputs 
related to 0013574closed  Ninja: no transitive dependency for imported libraries 
Attached Fileszip ninja.info.zip (19,572) 2012-09-14 08:46
https://public.kitware.com/Bug/file/4482/ninja.info.zip
Issue History
Date ModifiedUsernameFieldChange
2012-09-14 08:46Miguel FIGUEIREDONew Issue
2012-09-14 08:46Miguel FIGUEIREDOFile Added: ninja.info.zip
2012-09-15 19:27Peter KuemmelNote Added: 0031032
2012-10-03 08:49Peter KuemmelAssigned To => David Cole
2012-10-03 08:49Peter KuemmelStatusnew => assigned
2012-10-03 08:58Peter KuemmelNote Added: 0031162
2012-10-05 15:34Peter KuemmelNote Edited: 0031032bug_revision_view_page.php?bugnote_id=31032#r845
2012-10-05 15:41Peter KuemmelRelationship addedrelated to 0013574
2012-11-21 14:44David ColeNote Added: 0031645
2012-11-21 14:45David ColeAssigned ToDavid Cole =>
2012-11-21 14:45David ColeStatusassigned => new
2013-02-09 07:02Peter KuemmelSummary[CMAKE+NINJA] Generated 'build.ninja' seems to be incomplete and fails to build ExternalProjects. => Ninja: Generated 'build.ninja' seems to be incomplete and fails to build ExternalProjects.
2013-03-09 06:24Peter KuemmelNote Added: 0032553
2013-03-09 06:24Peter KuemmelAssigned To => Peter Kuemmel
2013-03-09 06:24Peter KuemmelStatusnew => backlog
2014-06-11 08:36Brad KingRelationship addedrelated to 0014963
2014-06-11 08:38Brad KingNote Added: 0036158
2014-07-01 09:33Brad KingNote Added: 0036296
2014-07-01 09:33Brad KingAssigned ToPeter Kuemmel =>
2014-07-01 09:33Brad KingStatusbacklog => resolved
2014-07-01 09:33Brad KingResolutionopen => duplicate
2015-01-05 08:39Robert MaynardNote Added: 0037577
2015-01-05 08:39Robert MaynardStatusresolved => closed

Notes
(0031032)
Peter Kuemmel   
2012-09-15 19:27   
(edited on: 2012-10-05 15:34)
I assume the other generators only hide a bug in your setup.
To see this, call make with a target which needs the external project.
Then I also get an error with the nmake generator.

I assume you have somewhere:
ExternalProject_Add(ezxml ....)
set(EZXML_LIB vendor/ezxml/staging/lib/libezxml.a)

and later you use
target_link_library(x ${EZXML_LIB})
add_dependencies(x ezxml)


But cmake can't know that ezxml and ${EZXML_LIB} are related.

So try

ExternalProject_Add(ezxmlBuild ....)
add_library(ezxml STATIC IMPORTED GLOBAL)
add_dependencies(ezxml ezxmlBuild)
set_target_properties(ezxml PROPERTIES IMPORTED_LOCATION vendor/ezxml/staging/lib/libezxml.a)

and later you only need
target_link_library(x ezxml)


This works with make but not with ninja.
(0031162)
Peter Kuemmel   
2012-10-03 08:58   
Maybe ExternalProject_Add() should do above automatically:

   #--Install step---------------
    [INSTALL_DIR dir] # Installation prefix
    [INSTALL_COMMAND cmd...] # Command to drive install after build
    [INSTALL_LIBRARIES <var> libraries]# List of libraries which depend on this target and could be used via <var> in other projects. Libraries will have the INSTALL_DIR prefix.
(0031645)
David Cole   
2012-11-21 14:44   
Even if ExternalProject did this sort of library linkage automatically, the dependencies through to the source files would not be available to the outer project's make (or ninja) dependency analysis system.

And if we did do this automatically, then that's the next thing that people would ask for...

And if we did that all the way, then there is no longer anything External about it, and it's then conceptually the same as what you get with add_subdirectory and a direct inclusion of the sub-projects CMakeLists.txt files...

So I don't think we should do any of this automatic stuff.

I don't think this scenario described in this bug report should even work with the Makefiles generators... and if it does, I think it probably works by accident somehow.

I'm re-setting the status of this bug back to new and un-assigning it from myself... If anybody else wants to tackle this, I'm happy to advise and review proposed changes, but I strongly lean toward leaving well enough alone in this case.

ExternalProject should only be used to build things that are really external. Referring to them properly after that is up to each individual user. Usually the clients/importers of things built this way can just use find_package after the external project is built to get things imported properly.

See the Open Chemistry super build for a good example of how this works, using CMAKE_PREFIX_PATH so that find_package works automatically for the most part:

  http://source.openchemistry.org/gitweb?p=openchemistry.git;a=summary [^]
(0032553)
Peter Kuemmel   
2013-03-09 06:24   
Bug is not new any more, there was some activity.
(0036158)
Brad King   
2014-06-11 08:38   
See discussion in 0014963.
(0036296)
Brad King   
2014-07-01 09:33   
I'm resolving this as a duplicate of issue 0014963 which describes the larger problem. Either 0014963 needs to be resolved on the CMake side, or the Ninja issue linked in 0014747:0035830 needs to be resolved on the Ninja side. That will resolve this issue.
(0037577)
Robert Maynard   
2015-01-05 08:39   
Closing resolved issues that have not been updated in more than 4 months