On 2018.06.16 02:13, Thomas Baumgart wrote:
On Samstag, 16. Juni 2018 00:45:38 CEST Jack Ostroff wrote:
Recently, I've been playing with some informal comparisons between
make and ninja as build system, and between gcc and clang as
compiler. I have a sense that ninja is a bit faster, although I've
also been trying cccache, which make a great difference if doing
clean compiles but with only minor changes in configure parameters.
>
However, starting about two days ago, several builds ended up not
having libofx clientuid capability, which is absolutely essential
for me, and which has worked fine for quite a long time. I started
digging into the code, and I did notice two recent commits in CMake
files related to libofx. However, nothing made any sense, until I
realized that what happened was that all my compiles using "make"
failed to find clientuid support, but my compiles with "ninja" did
find it. Note that terminology is not quite accurate, since the
success or failure was all within the cmake/ccmake run, before
either make or ninja was involved. I'm guessing this is a bug within
cmake itself, but I'm stumped as to how to create a small test case.
>
Question: is there anyone compiling from source who has found the
problem with cmake not finding clientuid support, where it was
previously found? I'm really not sure if one of the cmake related
commits tripped over some sort of edge case,
>
I did reinstall cmake on 23 May, but it was just a reinstall of the
same version 3.9.6 I originally installed on 27 Dec. I'm going to
try a newer version of cmake, but would love to find I'm not the
only one who has gotten caught by this.
>
> Thanks for any ideas.
>
> Jack
Can you check if the attached patch makes a difference, please?
Yes, it works. Thanks.
Now I'm curious why it worked when preparing for Ninja but not for
make. I also don't seem to follow the logic of why it didn't find the
clientuid support, but DID find libofx.
Jack
