-
Notifications
You must be signed in to change notification settings - Fork 203
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
AL unit tests fixes for all three platforms #198
AL unit tests fixes for all three platforms #198
Conversation
…and Release: - Port AL_MayaUtilsTests to Windows + runtime path fixes for MacOSX/Linux. - Port AL_USDMayaTestPlugin to Windows + runtime path fixes for MacOSX/Linux. - Port testMayaSchemas to Windows + runtime path fixes for MacOSX/Linux. - Fix UnitTestHarness return status - Fix runtime path for _AL_USDMaya on MacOSX - Fix a Python bug in TestAdditionalTranslators - Fix Python module extension on MacOSx + Python:AL_USDTransactionTests - Build GTest as shared library on all platforms. - Fix various issues with creating temporary files on Windows (WIP) - Fix "Argument not separated from preceding token by whitespace" warning on Windows - Fix a bug in fetch_googletest macro - Use RUNPATH instead of RPATH for all shared libs and executables on Linux - Clean up various Cmake files
plugin/al/CMakeLists.txt
Outdated
@@ -98,4 +98,4 @@ get_property(PYTHON_LIBRARY_LOCATION GLOBAL PROPERTY GLOBAL_PYTHON_LIBRARY_LOCAT | |||
configure_file(ALUsdMayaConfig.cmake.in ${PROJECT_BINARY_DIR}/ALUsdMayaConfig.cmake @ONLY) | |||
|
|||
install(CODE "message(STATUS \"POST INSTALL: Compiling python/pyc for ${AL_INSTALL_PREFIX} ... \")") | |||
install(CODE "execute_process(COMMAND ${Python_EXECUTABLE} -m compileall ${AL_INSTALL_PREFIX} )") | |||
install(CODE "execute_process(COMMAND \"${Python_EXECUTABLE}\" -m compileall ${AL_INSTALL_PREFIX} )") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wrap all the full path variables around quotes in case there are located in weird places with whitespaces and special characters on Windows. Just to be safe!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a couple of minor comments.
if(IS_WINDOWS) | ||
set_target_properties(${USDTRANSACTION_PYTHON_LIBRARY_NAME} | ||
PROPERTIES | ||
SUFFIX ".pyd" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I was making my python debug changes I didn't realize this was a python library because it didn't have the .pyd extension. Good catch. But can you also make the change to add the _d to the name. Simply replace line 9 above with this:
if(IS_WINDOWS AND ${MAYAUSD_DEFINE_BOOST_DEBUG_PYTHON_FLAG})
# On Windows when compiling with debug python the library must be named with _d.
set(USDTRANSACTION_PYTHON_LIBRARY_NAME _${USDTRANSACTION_LIBRARY_NAME}_d)
else()
set(USDTRANSACTION_PYTHON_LIBRARY_NAME _${USDTRANSACTION_LIBRARY_NAME})
endif()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Roger that!
plugin/al/usdtransaction/AL/usd/transaction/tests/CMakeLists.txt
Outdated
Show resolved
Hide resolved
set_property(TEST ${USDTRANSACTION_PYTHON_TEST_NAME} APPEND PROPERTY ENVIRONMENT | ||
"PYTHONPATH=${pythonPath}" | ||
"PATH=${path}" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the bash scripts for setting and running python unit tests are now removed for the sake of portability.
CMake PROPERTY ENVIRONMENT
can be used instead to set ENV variables during the unit tests run.
@@ -10,7 +10,7 @@ set(PY_INIT_FILES | |||
# copy to build location for module tests | |||
foreach(INPUT_FILE ${PY_INIT_FILES}) | |||
string(REPLACE ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR} OUTPUT_FILE ${INPUT_FILE}) | |||
execute_process(COMMAND ${CMAKE_COMMAND} -E copy ${INPUT_FILE} ${OUTPUT_FILE}) | |||
execute_process(COMMAND "${CMAKE_COMMAND}" -E copy "${INPUT_FILE}" "${OUTPUT_FILE}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wrap all the full path variables around quotes in case there are located in weird places with whitespaces and special characters on Windows. Just to be safe!
@elrond79 I believe you are referring to missing As per previous comments, this missing symbol is not a new problem. We hit it already when fixing Pixar tests. We need tests working in the |
No, I was referring to this:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to approve this, and assuming we'll soon find a fix to the python/DTS error discussed below
Decided to just approve for now, despite the rpath issue. Will make a separate issue for that after. |
… tests This prevents unittest.main() from exiting on test failures and ensures that maya.standalone.uninitialize() gets called before returning success or failure.
@elrond79 FYI. We tried on multiple Linux setups and couldn't reproduce your rpath issue. Animal Logic didn't hit this issue either in Linux docker (which runs build.py). |
This prevents unittest.main() from exiting on test failures and ensures that maya.standalone.uninitialize() gets called before returning success or failure.
@kxl-adsk Thanks for checking! I looked at it again, and figured out what's causing it - it has to do with how it handles symlinks in the build path, so that explains why others didn't see it. I'll make a PR for it shortly. |
I know this PR is closed, but I wanted to follow up on the linker DTS issue on Linux again - this is proving to be a real pain for us in our standardised docker build.. to a point where I'm considering re-introducing as an internal patch the shell script that calls maya batch and runs the python script via a mel call... Wondering if anyone has tried building their own simple mayapy replacement that just evaluates the python script/module being passed in (without necessarily mimicking the full functionality of the python executable, just for executing tests? Would it suffer from the same problems? |
We explored multiple potential solutions to the problem and nothing came as close to complete solution on all platforms as what we currently have with mayapy. We don't recommend making the patch your described. Consider the following potential solutions instead:
How to 1)
Then apply this patch:
How to 2)
Python test
|
Hi @kxl-adsk - thanks for that... I had already seen Paul's comment..... 2) was mostly what I was proposing to do - but I'm glad there's a solution without the extra .sh script - which is great.... Will let you know how that goes and potentially put up a PR |
If you want to make a global change to the way tests are handled, you might
want to checkout PR#242:
#242
That way, you'd only need to make your change in one place...
…On Thu, Feb 6, 2020 at 3:35 PM Eoin Murphy ***@***.***> wrote:
Hi @kxl-adsk <https://github.com/kxl-adsk> - thanks for that... I had
already seen Paul's comment..... 2) was mostly what I was proposing to do -
but I'm glad there's a solution without the extra .sh script - which is
great.... Will let you know how that goes and potentially put up a PR
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#198?email_source=notifications&email_token=AAARQ6HZPTNEOMEXNP6PYRLRBSNDXA5CNFSM4KGLBTR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELBGADY#issuecomment-583163919>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAARQ6BBM5VEJXSPZT3YUGDRBSNDXANCNFSM4KGLBTRQ>
.
|
Or - well, 1 place for all the AL + autodesk tests - as Krystian pointed
out, the pxr tests still go through their own system.
…On Thu, Feb 6, 2020 at 3:38 PM Paul Molodowitch ***@***.***> wrote:
If you want to make a global change to the way tests are handled, you
might want to checkout PR#242:
#242
That way, you'd only need to make your change in one place...
On Thu, Feb 6, 2020 at 3:35 PM Eoin Murphy ***@***.***>
wrote:
> Hi @kxl-adsk <https://github.com/kxl-adsk> - thanks for that... I had
> already seen Paul's comment..... 2) was mostly what I was proposing to do -
> but I'm glad there's a solution without the extra .sh script - which is
> great.... Will let you know how that goes and potentially put up a PR
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#198?email_source=notifications&email_token=AAARQ6HZPTNEOMEXNP6PYRLRBSNDXA5CNFSM4KGLBTR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELBGADY#issuecomment-583163919>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAARQ6BBM5VEJXSPZT3YUGDRBSNDXANCNFSM4KGLBTRQ>
> .
>
|
We already explored 2) and it doesn’t apply to all platforms, so it’s not a direction we want to go with.
|
@elrond79 thank you that looks fantastic... |
We have to run tests with mayapy on MacOS. Having different methods of running tests per platform is not where we want to be. |
I agree that's not where we want to be - and in an ideal world we wouldn't be there - but if Linux tests can't be run by anyone using the recommended VFX Platform setup - surely that's a bigger problem? |
Option 1) allows you to run all tests using recommended VFX Platform setup. Why you don’t want to try it?
|
Updating a whole docker pipeline is time consuming for us - but it can be done. The bigger question is that everyone will have to do the same - whereas solution 2 will be transparent |
Anyway, we will give #1 a try, will take til Monday before all of the docker builds run and go through..here's the correct patch (I think the formatting in the one above went bad?):
|
Hi guys,
This pull request addresses various issues with running AL unit tests on different platform and both debug and release variants. In doing so, we hit various challenges on Windows that we had to tackle (e.g mix of "\" and "/" in temporary directories, whitespaces, linking against static GTest library, etc...).
With the current fixes, one should be able to run all AL tests from command line (Windows command prompt or bash).
We still have two tests that are failing on Linux and Windows (TestAdditionalTranslators and TestPxrUsdTranslators) which we would like to fix.
On MacOSX, all the tests are now passing.
I am going to add comments on the line of code on github sometimes tomorrow to hopefully make it easier to review this PR. We also tried to keep the changes to minimal but still ended up with 57 files changes.
Change log: