MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015663CMakeCMakepublic2015-07-23 16:502016-01-04 11:51
ReporterLaurent Demailly 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformApple MacOSOS XOS Version10.4.10
Product VersionCMake 3.2.3 
Target VersionFixed in Version 
Summary0015663: externalproject cause make -j build failure the first time
Descriptionthe first time someone builds a cmake generated makefile, using -j yields a broken build because somehow the download of the external projects isn't complete

the dependencies should be set correctly such as make waits for that target to complete ?

https://github.com/facebook/wdt/issues/12 [^]
Steps To Reproducegit clone https://github.com/facebook/wdt.git [^]
mkdir build; cd build
cmake ../wdt -G "Unix Makefiles" -DBUILD_TESTING=on
make -j

this isn't mac specific - same issue with Ubuntu - could be a bug in our cmakelist.txt
https://github.com/facebook/wdt/blob/master/CMakeLists.txt#L212 [^]
is where we add gmock
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-07-23 16:50Laurent DemaillyNew Issue
2015-07-27 11:08Brad KingNote Added: 0039171
2015-07-27 11:09Brad KingStatusnew => resolved
2015-07-27 11:09Brad KingResolutionopen => no change required
2015-07-28 02:56Laurent DemaillyNote Added: 0039172
2015-07-28 08:34Brad KingNote Added: 0039173
2016-01-04 11:51Robert MaynardNote Added: 0040098
2016-01-04 11:51Robert MaynardStatusresolved => closed

Notes
(0039171)
Brad King   
2015-07-27 11:08   
The problem here:

 https://github.com/facebook/wdt/blob/2e60ce04c9/CMakeLists.txt#L212 [^]

is that you are trying to link to library files generated by the external project from targets that have no dependency on it. You can use

 add_dependencies(myexe myextproj)

to make sure the external project finishes building before your target tries to use it.
(0039172)
Laurent Demailly   
2015-07-28 02:56   
Thanks a lot ! add_dependencies() fixed it - I (incorrectly) thought the reference to the project libraries implied that

we still have a weird -L ${BINARY_DIR} that is needed only for XCode (and cause warning for everybody else) but I will file a different issue about that (or ask the mailing list)

https://github.com/facebook/wdt/blob/master/CMakeLists.txt#L241 [^]
(0039173)
Brad King   
2015-07-28 08:34   
Re 0015663:0039172: Great, I'm glad that worked. The reference to the external project library files is not enough to tell CMake that those files have anything to do with the external project target.

For this block:

> # ${BINARY_DIR}/libgmock.a works everywhere except xcode...
> # so ugly weird hack generating warnings about unknown dir for now:
> target_link_libraries(wdt4tests
> "-L ${BINARY_DIR} -L ${BINARY_DIR}/Debug -lgmock"
> wdtlib
> )

please ask on the mailing list. If no one responds after a day please find the post in the list archives:

 http://public.kitware.com/pipermail/cmake/ [^]

and post a link to it back here to remind us.
(0040098)
Robert Maynard   
2016-01-04 11:51   
Closing resolved issues that have not been updated in more than 4 months.