CMake prefers installed headers over source

[jcowles]

System Information (OS, Hardware, etc.)

Windows

Steps to Reproduce

1. Build a full USD tree
2. Make sure your built headers are on your PATH
3. Sync the tree with changes in arch headers
4. Build fails, in my case, it was the introduction of ArchResolveSymLink().

Deleting the installed pxr headers fixed the build, so presumably it's preferring the installed headers over the source headers.

It seems like CMake should be configured to prefer the source headers over any headers that can be found on the users PATH.

[asluk]

I've seen this as well on OSX, and had started looking into it briefly a
while back. The actual g++ command lines that I was getting looked to be in
order wrto -I's, so I was wondering it there was a race condition between
copying local headers to the build location and the compile, but I haven't
dug deeper yet.

On Mon, Oct 17, 2016 at 5:37 PM, Jeremy Cowles notifications@github.com
wrote:

System Information (OS, Hardware, etc.)

Windows
Steps to Reproduce

1. Build a full USD tree
2. Make sure your built headers are on your PATH
3. Sync the tree with changes in arch headers
4. Build fails, in my case, it was the introduction of
   ArchResolveSymLink().

Deleting the installed pxr headers fixed the build, so presumably it's
preferring the installed headers over the source headers.

It seems like CMake should be configured to prefer the source headers over
any headers that can be found on the users PATH.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#83, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AB_7ZuNwq8ngVB22bXWfpF2iyQUnd21Fks5q05ZQgaJpZM4KYxgC
.

[jtran56]

Filed as internal issue #138796.

[meshula]

Further to @asluk's point, I think that transitive header-only dependencies might not be detected in the current scheme. i.e. Foo->Bar->Baz where Foo only needs a header from Baz, might not trigger Baz to publish it's headers if Bar is otherwise up to date.

[robp-mpc]

I also just ran into this (OSX) where I had an old USD installation, then updated the source to 0.7.2 and tried to build again.

I had the same issue with OIIO a few months back, and logged it (and the fix in that case) here: AcademySoftwareFoundation/OpenImageIO#1522
Hopefully it's useful/relevant. I've not done any digging into USD's CMake setup ... not brave enough at present ;)

[robpieke]

darn it ... just got bitten by this again.

[meshula]

The BEFORE keyword looks like it might help here too, as you suggest.

[Delwin9999]

Possibly related to this - I keep getting the system boost libraries instead of the locally built ones when the various pxr_test builds are happening. There's a lot of internal logic in there sorting internal and external libraries and I think it's also preferring system installed ones over the locally built ones.

[meshula]

also related #419

[sunyab]

Just wanted to note I've run into this in the past but it was in the middle of some other work and I neglected to write down the exact steps to reproduce it consistently. I'm guessing this issue is still present; if it is, I'd love to fix it, so if anyone has a good set of repro steps please let me know -- thanks!

[robpieke]

On OSX at least.....

This fails (on the second build):

%  git checkout v0.8.2
%  python build_scripts/build_usd.py --no-python --no-imaging /tmp/usdHeaderTest
%  git checkout v18.09
%  python build_scripts/build_usd.py --no-python --no-imaging /tmp/usdHeaderTest

This still works:

%  git checkout v0.8.2
%  python build_scripts/build_usd.py --no-python --no-imaging /tmp/usdHeaderTest_old
%  git checkout v18.09
%  python build_scripts/build_usd.py --no-python --no-imaging /tmp/usdHeaderTest_new

[superfunc]

Yeah @robpieke I had a similar repro when I ran into it (mine was in /usr/local)

[sunyab]

Thanks @robpieke and @superfunc, I can reproduce the build failures using those steps. When I follow those steps, my build fails when linking the sdfdump executable -- can you confirm whether you see the same failure mode?

This particular problem is due to include directory ordering, and I think I have a pretty straightforward fix for this. However, it looks like this is only an issue when building the executables via pxr_build_test; building libraries doesn't seem to have this problem. So, I'm not sure this is the same issue that was originally posted about.

[robpieke]

Hey @sunyab ... yes I can confirm a fail on linking sdfdump given the above.

Why do you think this is different than the original report? The specific place/symbol/class where it fails might be different than where @jcowles or I saw it previously, but I suspect the cause (installed header preference) is the same.

I'm still hoping something similar to what was done for OIIO (AcademySoftwareFoundation/OpenImageIO#1522) will work here.

[superfunc]

Mine dies in sdfdump as well. I think on older releases, I saw it die earlier, due to a fundamental change in some headers, but I honestly can't remember the specifics.

[sunyab]

@robpieke, I'm mostly guessing. The fix I currently have only affects building executables, and I swear the time I ran into this problem it happened when I was building a library. And yes, my I think my fix is essentially the same as the OIIO issue you posted -- it just switches the include directory ordering around.

In any case, I'm hoping to land my fix soon and see where we are then.