Project

General

Profile

Bug #10354

CMakeLists.txt issues

Added by Germano Massullo over 5 years ago. Updated over 3 years ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
-
Target version:
Start date:
03/02/2015
Due date:
% Done:

100%

Estimated time:
Affected Version:
1.6.2
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Everything started with http://www.darktable.org/redmine/issues/10353
we thought it was a GCC trouble, then Kevin Kofler found out CMake race conditions =====================
<@Kevin_Kofler> I think this one is a parallel make race condition. Sometimes, build scripts don't get the makefile dependencies right for parallel make. In this case, there's a CMake rule with 2 outputs (a .c and the corresponding .h), handling that with CMake is always problematic.
<@Kevin_Kofler> A quick hack is to just resubmit until it works, otherwise you can also remove the %{?_smp_mflags} from the make invocation (but that'll slow down the builds). =====================

Then we submitted CMakeLists.txt to CMake's IRC channel for a review and ngladitz said: =====================
[18:51:56] <+ngladitz> hm maybe I am missing something but "error: 'DT_METADATA_XMP_DC_CREATOR' redeclared as different kind of symbol" does not look like it would be a parallel make issue(?)
[18:57:58] <+ngladitz> oh I missed the file with the error itself is generated
[19:00:44] <+ngladitz> Germano: https://github.com/darktable-org/darktable/blob/master/src/CMakeLists.txt seems to be where that is done
[19:00:44] <+ngladitz> there are lots of issues with that setup :\
[19:00:45] <+ngladitz> generating two outputs is not a problem but having multiple targets depend on the same generated source files does lead to race conditions
[19:02:38] <Germano> ngladitz: are there many issues in that CMakeLists?
[19:03:49] <+ngladitz> certainly looks that way ... though some of that may just be outdated use/conventions
[19:04:55] <+ngladitz> e.g. globbing for source files is generally discouraged ... but the glob being used lists existing files rather than patterns so it doesn't even make that much sense
[19:05:37] <+ngladitz> or add_library(lib_darktable STATIC SHARED <- STATIC and SHARED are mutually exclusive =====================

Associated revisions

Revision 202761c0 (diff)
Added by Roman Lebedev over 4 years ago

CMake: add custom target to drive metadata generation. Refs #10354

As per add_custom_command() documentation,
this is the only way. Else we risk race conditions.

Revision c8d0d6ff (diff)
Added by Roman Lebedev over 4 years ago

CMake: add custom target to drive preferences generation. Refs #10354

As per add_custom_command() documentation,
this is the only way. Else we risk race conditions.

Revision 9a36a592 (diff)
Added by Roman Lebedev over 4 years ago

CMake: no need for metadata_dummy lib. Replace with a simple dep. Refs #10354

Revision 590ceed8
Added by Roman Lebedev over 4 years ago

Merge pull request #1162 from LebedevRI/cmake-issues

CMake fixes: part 2. Fixes #10354

History

#1 Updated by Germano Massullo over 5 years ago

<parafin> "having multiple targets depend on the same generated source files does lead to race conditions"
<parafin> erhm, why?
[19:42:10] <+ngladitz> you will get multiple instances of the same commands running potentially in parallel
[19:43:39] <+ngladitz> is is documented behavior: "Do not list the output in more than one independent target that may build in parallel or the two instances of the rule may conflict" (http://www.cmake.org/cmake/help/v3.1/command/add_custom_command.html)
[19:44:07] <+ngladitz> also documents the recommended workaround

#2 Updated by Roman Lebedev over 4 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Fixed

#3 Updated by Roman Lebedev over 3 years ago

  • Target version set to 2.2.0

Also available in: Atom PDF

Go to top