View Issue Details [ Jump to Notes ] [ Print ]
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
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0039171)
Brad King (manager)
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 (reporter)
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 (manager)
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 (manager)
2016-01-04 11:51

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2015-07-23 16:50 Laurent Demailly New Issue
2015-07-27 11:08 Brad King Note Added: 0039171
2015-07-27 11:09 Brad King Status new => resolved
2015-07-27 11:09 Brad King Resolution open => no change required
2015-07-28 02:56 Laurent Demailly Note Added: 0039172
2015-07-28 08:34 Brad King Note Added: 0039173
2016-01-04 11:51 Robert Maynard Note Added: 0040098
2016-01-04 11:51 Robert Maynard Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team