Problem make install asset resolver plugin

[fsuarezg]

Hello ,

I'm currently trying to build your example plugin of the custom asset resolver, and I'm running into a bit of a problem building it and I was wondering if you had maybe encountered a similar error.

I'm on a Centos 7 machine, with a built version of USD (21.02), devtoolset-8 (for gcc 8.3.1), and cmake (3.14.6).

Running the USD_INSTALL_ROOT=/home/fernandos/Documents/USD cmake ..command seems to work, the problem occurs when running the make install command:

[ 50%] Building CXX object src/CMakeFiles/URIResolver.dir/resolver.cpp.o
In file included from /home/fernandos/Documents/USD/include/pxr/base/tf/enum.h:33,
                 from /home/fernandos/Documents/USD/include/pxr/base/tf/stringUtils.h:36,
                 from /home/fernandos/Documents/USD/include/pxr/base/vt/value.h:42,
                 from /home/fernandos/Documents/USD/include/pxr/usd/ar/threadLocalScopedCache.h:30,
                 from /home/fernandos/Documents/USD/include/pxr/usd/ar/defaultResolver_v1.h:37,
                 from /home/fernandos/Documents/USD/include/pxr/usd/ar/defaultResolver.h:35,
                 from /home/fernandos/Documents/USD-Cookbook-master/plugins/custom_resolver/project/src/resolver.cpp:2:
/home/fernandos/Documents/USD/include/pxr/base/tf/hash.h:44:6: error: ‘enable_if_t’ in namespace ‘std’ does not name a template type
 std::enable_if_t<std::is_integral<T>::value>
      ^~~~~~~~~~~
...

This type error seems to indicate an error possibly caused by a wrong version of gcc. I know that enable_if_t was added in c++14, so if you have an old compiler (such as the standard gcc 4.8.1 on Centos 7) it would throw this error as it standard uses c++11 to compile.
However, I'm using the devtoolset-8 environment and everything seems to indicate that I am using gcc 8.3.1 to compile. Now I noticed that you previously built this project with USD 19.07, might it be that that version was still compiled with and old version of gcc that used c++11 as the standard and that the makefile somehow uses a wrong version of gcc (the standard 4.8.1 version on Centos 7)(This does not seem the case, but I thought I ask)

So I guess my question is: is it normal that I am encountering this problem with USD 21.02? or are you able to build it without any issues with that USD version?

[cole-clark]

The version of C++ does matter with USD, as your error is coming from a USD include. It looks like USD is built against C++14 here:
https://github.com/PixarAnimationStudios/USD/blob/dc710925675f7f58f7a37f6c18d046a687b09271/cmake/defaults/CXXDefaults.cmake#L29

Does it work if you add -DCMAKE_CXX_STANDARD=14 when you call Cmake?
https://cmake.org/cmake/help/v3.1/variable/CMAKE_CXX_STANDARD.html#variable:CMAKE_CXX_STANDARD

[fsuarezg]

Hi Colin,
First of all thanks for the reply!

I tried your suggestion of adding the cmake flag to the command

USD_INSTALL_ROOT=/home/fernandos/Documents/USD cmake -DCMAKE_CXX_STANDARD=14 ..
which added these lines in the cmakeCache file:

//No help, variable specified on the command line.
CMAKE_CXX_STANDARD:UNINITIALIZED=14

but when I ran make install, it unfortunately still results in the same enable_if_t not a type error.
I'm trying to understand how that is possible. I'm on a Virtual Machine to make sure that my environment is as clean as possible: all I did was install on a clean Centos 7 devtoolset-8, cmake 3.14.6, and python-devel.
I'm also going to try if there is any other cmake flag that I should set.

[fsuarezg]

AH I found the solution and also why adding -DCMAKE_CXX_STANDARD=14 when calling cmake didn't work.
In the custom_resolver/project/CMakeLists.txt file the was a line set(CMAKE_CXX_STANDARD 11), so I had to change it to 14 and that fixed it. This caused the flag to be overwritten even when it was passed to cmake.

[cole-clark]

Ah that'll do it! @ColinKennedy USD versions after 20.02 look like they require C++14. Probably rework that line to support newer versions. Perhaps something here can help?

https://github.com/wetadigital/USDPluginExamples/blob/2155c713cf6366f5cfa4fc3a9ca7268f55abc323/cmake/packages/FindUSD.cmake#L40

[ColinKennedy]

Hey @fsuarezg and apologies for the confusion. USD-Cookbook is built against on an old USD version so this was bound to happen at some point. @colevfx rightly pointed out to me the other day that we need some automated testing to make sure this repository stays build-able.

Probably that'll necessitate combining all of the ~40 CMake projects into a single build and then adding some CI so we can make sure this works on different OSes. It'll take a while to move everything over so in the meantime, please use this ticket to flag any other projects which you're unable to build in later versions and we'll address them once that automation is in a usable state.

Edit: Also FYI there's a similar thread on usd-interest - https://groups.google.com/g/usd-interest/c/XeYSf-IpzG8/m/5G3NnOB-AgAJ