Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add PXR_SYMLINK_HEADER_FILES cmake option #150

Closed

Conversation

pmolodo
Copy link
Contributor

@pmolodo pmolodo commented Jan 18, 2017

Description of Change(s)

On build, CMake automatically copies the header files into a slightly different location in the cmake build directory (ie, from pxr/base/lib/tf to CMAKE_DIR/pxr/base/tf). Unfortunately, this plays havoc with certain IDEs (ie, CLion), which find the "copied" headers instead of the "source" headers.

This change adds a PXR_SYMLINK_HEADER_FILES option which makes CMake symlink these headers to the cmake build dir, instead of copying, so that you can freely edit the headers in either location without having to worry which header you have.

On install, the headers are still properly copied, not symlinked.

Included Commit(s)

Fixes Issue(s)

  • none

@sunyab
Copy link
Contributor

sunyab commented May 23, 2017

Hi @elrond79, I just committed cff6390 which I think resolves the IDE issues with the copied headers without needing this build option. I tried this on Xcode and MSVC and confirmed that compile errors take me to headers in the source tree instead of the build directory. I haven't tried CLion, but I'm hoping it'll work the same there. Let me know if this works for you if/when you get a chance to try it out. Thanks!

@pmolodo
Copy link
Contributor Author

pmolodo commented May 23, 2017

Cool, we'll check to see if this does the trick!

@jtran56
Copy link

jtran56 commented Jun 2, 2017

Filed as internal issue #147126.

@pmolodo
Copy link
Contributor Author

pmolodo commented Jun 14, 2017

So, finally got around to giving this a shot - alas, it looks like our IDE (clion) does not support special handling for #line directives.

Also - one nice thing about the symlink approach is it really works for pretty much everything - ie, if you use "find" or "grep -R" from the command line, then open it up in a text editor, you don't need to worry about which version of the file you have.

However - if you folks find really are against this, then we can drop the PR (though I think some others might find it handy!)

Also - out of curiosity, what IDE are you folks using for developing USD?

Handy for some IDEs which "find" the symlinked versions by default;
also removes confusion about which to edit. Defaults to off.
@pmolodo
Copy link
Contributor Author

pmolodo commented Apr 10, 2018

Ok, seems like this PR likely isn't going to happen (though I still think it's a good idea!), so I'm going to close the request.

@pmolodo pmolodo closed this Apr 10, 2018
AdamFelt pushed a commit to autodesk-forks/USD that referenced this pull request Apr 16, 2024
…nt height for GenericText. (PixarAnimationStudios#150)

TextSytem introduces a DecorationLayout structure which is composed of some contiguous line sections, and the section data is calculated by textLayout.
GenericText --(1:m)-- Final decoration(s) --(1:m)-- TextLine decoration(s) --(1:m)-- Section(s) --(1:m)-- Same Color TextRun(s)
Fix line color: Every section will be created to one underline/overline curve drawItem in USD. The _lineColor of Section will be converted to displayColor for every curve drawItem.
Fix line breaking result from different font size in one line: Contiguous line sections in one line is stored in same Decoration, and Decoration has only one yPosition.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants