Remove global constructor for Traversal constants

[ld-kerley]

When we ship MaterialX in apple ecosystem we maintain a number of patches to avoid global constructors and destructors on exit. (-Wglobal-constructors -Wexit-time-destructor)

This PR proposed one of these patches, if this is merged, I'll propose some others moving forwards. This will help us lower the burden of ongoing maintenance for MaterialX integration in the apple ecosystem.

[jstone-lucasfilm]

This looks good to me, thanks @ld-kerley, and I had just one minor note.

[jstone-lucasfilm]

Just adding a reminder to run clang-format on your new code, so that it inherits the Allman braces style of the project.

[ld-kerley]

Thanks for the reminder - if only we were running clang-format in the CI... :) Then I wouldn't forget.

[jstone-lucasfilm]

Not related to your PR, but does anyone know how to get clang-format to maintain Allman braces consistently in data initializers as well as functions?

The MaterialX code style expects Allman braces everywhere, but clang-format seems to treat data initializers as a special case.

[jstone-lucasfilm]

This looks good to me, @ld-kerley, though I'd recommend reverting the style changes that don't relate to your work on Traversal constants, so that we're not interleaving functional and style changes in a single PR.

I'm still curious as to whether clang-format can be instructed to use Allman braces universally, matching the existing style of the MaterialX codebase, rather than using one convention for functions and another convention for data initializers. But we don't need to solve that in your PR, and it's a project that we can follow up on another day.

[ld-kerley]

Thats pretty frustrating... Being asked to run clang-format and then revert those changes.

I think we really need to improve that aspect of the developer experience. It would save a lot of time if we could just decide on a clang-format configuration, and then apply it universally - even if that led to a change in formatting conventions, it would be applied across the entire project, and would save many hours of time, in both manual fixes, and also time spent reviewing code for formatting.

[ld-kerley]

I reverted the clang-format changes.

[jstone-lucasfilm]

This looks good to me, thanks @ld-kerley!

In case it's helpful for future changes, clang-format can be applied to just the new code that you're adding to a codebase, as originally requested in this PR. That's the approach that I use when contributing code to a repository, so that I'm not accidentally changing unrelated lines of code that may simply need a refresh for a new version of Clang.

I like the idea of steering our codebase in the direction of full clang-format automation in the future, and one step in this direction will be to resolve the unusual interpretation of Allman braces for initializer lists in Clang.

I had a chance to look this up recently, and it could be that the Cpp11BracedListStyle option will bring clang-format closer to the universal interpretation of Allman braces that we expect in MaterialX.

[ld-kerley]

Thanks for merging this - I'll likely have some more changes in this vein to help us manage future MaterialX upgrades internally.

Full clang-format automation would be a huge win IMHO. Every project I've worked on that has taken that leap has seen a significant improvement in velocity, code cleanliness and also interestingly quality of code review. Once you don't have to think about formatting anymore your brain is able to focus on the meaningful pieces.

I was poking around the internet and couldn't find a formal definition of Allman braces written down anywhere. Is it perhaps possible that clang-format is correct and we're misinterpreting in the MaterialX source code?

Either way, I really don't have any strong preference as to what formatting style is used, if it's enforced by the tools and I don't have to think about it. I would propose that its beneficial to the community to morph the MaterialX coding standards to meet clang-format if we can't find a way to get clang-format to follow our coding standards. To me the productivity upside outweighs the historical formatting choices - but thats just a personal opinion.