pxrTargets.cmake wanting import libraries when there are none

[foundry-markf]

Description of Issue

I have built USD 0.8.5a with VisualStudio 2015 using the provided build_usd.py script.
I tried to use the cmake config files in the install folder by including them into my CMakeLists.txt file, and resulted in errors looking for DLL import libraries for two DLLs that have no symbol exports (hence the import libs don't exist). The two DLLs are hdStream and usdObj.

Steps to Reproduce

1. Build and install USD for VisualStudio
2. Create a noddy CMakeLists.txt file containing

cmake_minimum_required(VERSION 3.11)
include(pxrConfig)

3. Invoke cmake with cmake -DCMAKE_MODULE_PATH=<USD install dir> .
4. Observe the errors:

CMake Error at D:/thirdparty/usdbuild/cmake/pxrTargets.cmake:381 (message):
  The imported target "hdStream" references the file

     "D:/thirdparty/usdbuild/lib/hdStream.lib"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "D:/thirdparty/usdbuild/cmake/pxrTargets.cmake"

  but not all the files it references.

5. You can work around this by removing the reference to hdstream.lib in
   list(APPEND _IMPORT_CHECK_FILES_FOR_hdStream "${_IMPORT_PREFIX}/lib/hdStream.lib" "${_IMPORT_PREFIX}/lib/libhdStream.dll" )
   in <USD install dir>/cmake/pxrTargets-release.cmake.
6. Run CMake again, observe these errors

CMake Error at D:/thirdparty/usdbuild/cmake/pxrTargets.cmake:381 (message):
  The imported target "usdObj" references the file

     "D:/thirdparty/usdbuild/share/usd/examples/plugin/usdObj.lib"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "D:/thirdparty/usdbuild/cmake/pxrTargets.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  D:/thirdparty/usdbuild/pxrConfig.cmake:8 (include)
  CMakeLists.txt:2 (include)

7. Workaround that by removing the reference to usdObj.lib in
   list(APPEND _IMPORT_CHECK_FILES_FOR_usdObj "${_IMPORT_PREFIX}/share/usd/examples/plugin/usdObj.lib" "${_IMPORT_PREFIX}/share/usd/examples/plugin/usdObj.dll" ) in <USD install dir>/cmake/pxrTargets-release.cmake.
8. Run CMake again. No errors.
9. Double check, view libhdstream.dll and usdobj.dll in depends.exe, and note there are no exported symbols.

System Information (OS, Hardware)

Windows 10, VisualStudio 2015

Package Versions

0.8.5a

Build Flags

All defaults

[jtran56]

Filed as internal issue #161891.

[sopvop]

To fix that all plugin libraries should be added as add_library(name MODULE ${source}) and not SHARED. For SHARED cmake always expects to find associated implib, and msvc does not generate implib for dll which contains no exported symbols.

Fixing that requires venturing into the depths of pxr build system, and that place is scary.

[foundry-markf]

@sopvop Thanks for the commit against this bug.

Should usdObj, as mentioned in the initial report, also have been fixed in the same way that hdStream has been?

[sopvop]

Oh no, that commit actually breaks build completely. It was pushed by accident.
As I said pxr build system is quite complex and that was an attempt to fix it with one little change. Didn't work.

If you just change it from SHARED to MODULE then plugins which do need a shared library because they also build python module can't be linked against that library.

To fix this issue you either have to force MSVC to generate empty import library somehow, or also check if python module will be build for this plugin. If python modules is being build then do SHARED, otherwise do MODULE.

[meshula]

UsdAbc has two symbols exported, in alembicTest.h. Probably the best fix is to add something exportable to UsdObj as well.

At this point hdStream has a lot of exports, so hopefully Usd >= 0.89 doesn't have a problem with HdSt?

[sunyab]

Rather than add dummy symbols to export, I would propose that we update the build system so that plugins that are built via pxr_plugin are just excluded from the generated pxrConfig.cmake and pxrTargets.cmake.files. These include:

usdAbc
usdMtlx
usdObj
usdSchemaExamples
hdEmbree
... and a few others(*)

The key distinction with these plugins is that they're not intended to be linked against by client code, so it doesn't make sense (AFAICT) to include them in the list of targets exported by cmake.

(*) hdStream isn't built using pxr_plugin but we think this is an oversight and it should be.

[foundry-markf]

Just wondering if there has been any more inside development made on this issue?

I was just testing 19.05, and encountered the same problem again with hdStream.

I also now see it for usdShaders too.

Thanks.

[c64kernal]

Hi @foundry-markf -- no I don't think we've had a chance to do anything about this, but would happily take a PR with @sunyab's suggestion in mind though.

[KelSolaar]

Hi,

I'm having the same issue when trying to build https://github.com/Autodesk/maya-usd

I removed all the references to:

• hdStream
• usdShaders
• usdObj
• usdDancingCubesExample
• usdRecursivePayloadsExample

in the pxrConfig.cmake, cmake/pxrTargets.cmake and cmake/pxrTargets-release.cmake files.

Would be fantastic to have a clean fix for that.

Cheers,

Thomas

[meshula]

@sunyab Is the fix as simple as changing these lines in function(pxr_library) from

   # Collect libraries.
    get_property(help CACHE PXR_ALL_LIBS PROPERTY HELPSTRING)
    list(APPEND PXR_ALL_LIBS ${NAME})
    set(PXR_ALL_LIBS "${PXR_ALL_LIBS}" CACHE INTERNAL "${help}")

to this?

   # Collect libraries.
    if(NOT args_TYPE STREQUAL "PLUGIN")
        get_property(help CACHE PXR_ALL_LIBS PROPERTY HELPSTRING)
        list(APPEND PXR_ALL_LIBS ${NAME})
        set(PXR_ALL_LIBS "${PXR_ALL_LIBS}" CACHE INTERNAL "${help}")
    endif()

Ultimately the pxrConfig.cmake file is populated by substituting PXR_ALL_LIBS in pxrConfig.cmake.in, so this would seem like a direct fix.

I'm not set up to test this at the moment, but I think this is what I interpret from your comment.

[sunyab]

@meshula -- we have a fix incoming; what you hae was part of it, but we discovered another part of the build that needed to be guarded as well.

[danlea]

Does the referenced commit resolve the issue for usdShaders, given that that library is not declared as a plugin? Can we simply change it to be declared as such?

[tallytalwar]

@danlea Thanks.

We did move usdShaders from usdImaging/lib to usdImaging/plugin in the dev branch for 19.11 release, however we missed updating the CMakeLists to make usdShaders a pxr_plugin. Thanks for catching that.