-
Notifications
You must be signed in to change notification settings - Fork 559
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
Intrelab: Switch to target based Intrelab CMake build #10631
Intrelab: Switch to target based Intrelab CMake build #10631
Conversation
@bartlettroscoe Once this PR is finished (switching to target based CMake for Intrelab), will we want to have it merged prior to the TriBITS update or with it (or even after)? |
@kuberry, these changes should be merged along with or after PR #10614 is merged. (There are few remaining items to address before that can be merged, likely mid to late next week.) I could have them merged at the same time by merging this topic branch into the topic branch for PR #10614 and that would result in them being merged at the same time. That is likely the best option. Just tell me when this branch is ready to merge and I will merge it into the branch associated with PR #10614. |
@kuberry, I see you removed the copied and modified function matlab_add_mex_mac(). Is this branch now working along with the TriBITS upgrade in PR #10614? Is this PR's topic branch kuberry:intrelab_trilinos_14 ready to merge into bartlettroscoe:tribits-299-modern-cmake-targets-1-again-2 so it gets merged at the same time that PR #10614 gets merged? |
@bartlettroscoe Yes, this branch is working along with #10614. I'm waiting to hear back from @dridzal, but I believe it is ready to be merged. |
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.
Intrelab builds and tests pass on MacOS, with cmake 3.22.1. On Linux, there are errors:
CMake Error at /net/sherlock.sandia.gov/storage/fast/projects/sems/install/rhel7-x86_64/sems/v2/utility/cmake/3.22.4/gcc/8.3.0/base/iyazzmq/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Matlab (missing: Matlab_INCLUDE_DIRS) (found version
"NOTFOUND")
Call Stack (most recent call first):
/net/sherlock.sandia.gov/storage/fast/projects/sems/install/rhel7-x86_64/sems/v2/utility/cmake/3.22.4/gcc/8.3.0/base/iyazzmq/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
/net/sherlock.sandia.gov/storage/fast/projects/sems/install/rhel7-x86_64/sems/v2/utility/cmake/3.22.4/gcc/8.3.0/base/iyazzmq/share/cmake-3.22/Modules/FindMatlab.cmake:1946 (find_package_handle_standard_args)
CMakeLists.txt:30 (find_package)
I looked at the cmake cache file, and it reports:
//Matlab installation root path
Matlab_ROOT_DIR:PATH=/net/sherlock.sandia.gov/storage/fast/projects/sems/install/rhel7-x86_64/sems/utility/tex/2019/bin
This is clearly wrong (why did it choose this??). I specifically set
set(MATLAB_ROOT_DIR "/home/dridzal/software/MATLAB/R2020b/")
if(DEFINED ENV{Matlab_ROOT_DIR})
set(Matlab_ROOT_DIR $ENV{Matlab_ROOT_DIR})
endif()
find_package(Matlab REQUIRED)
I have no idea why cmake is ignoring the variable I set.
@dridzal, did you mean to set:
instead of:
? CMake variable names are case-sensitive. |
Thanks @bartlettroscoe . That is an issue. I'll report back soon. |
b6273ca
to
b1afc4a
Compare
I fixed the Matlab path and built Intrelab successfully on Linux. Unfortunately, after starting Matlab as I normally do for Intrelab, I get the error:
To clarify, this is a Matlab mexa64 executable looking for a library function from Trilinos. This used to work with the old Trilinos and the old Intrelab CMakeLists.txt. I've tried building Trilinos in shared library mode and in static mode with fPIC. Both builds result in the same error. Adding my Trilinos /install/lib directory to the LD_LIBRARY_PATH does not help either. |
@dridzal Can you run: ldd /home/dridzal/development/Intrelab/Trilinos/packages/intrepid/matlab/intrelab/install/intrepid_getNumCubaturePoints.mexa64 and print the output? Also, could you run: readelf -d ../install/intrepid_getNumCubaturePoints.mexa64 and print that output? This will inform whether this is an RPATH issue or not. |
@kuberry : The first command gives a lot of output. I see tons of "standard" unrelated libraries, but nothing at all that looks like Trilinos. The second command gives:
What's your conclusion? |
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.
MacOS and Linux builds work with Matlab 2020a and 2020b, respectively. I think this is ready to be merged.
also 2021b |
@bartlettroscoe Hi Ross, can we get this merged into #10614? |
@kuberry, I have a checklist item to merge this at the top of #10614 before merging that PR. So this should be a smooth transition. |
At least as Intrelab is concerned :-) |
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.
Just a few suggestions to improve this. Otherwise, this is very simple and straightforward. It is almost too simple (which is a major victory, no?).
@@ -39,159 +55,20 @@ endif() | |||
|
|||
FIND_PACKAGE(Trilinos REQUIRED) |
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 would suggest that you pass in the exact Trilinos packages that Intrelab needs with:
find_package(Trilinos COMPONETS <pkg1> <plg2> ... REQUIRED)
so that if someone tries to configure this CMake project against an install of Trilinos without the necessary packages, then the find_package(Trilinos ... REQUIRED)
command will error out and tell them what Trilinos packages (i.e. components) are missing. Otherwise, you will not see this mistake until build time at which point would confuse whoever is trying to builds these MEX files.
- Changes from requiring CMake 3.10 to 3.12 to ensure "*_ROOT" is supported - Reformat MOBJS list - Change variable modification to work with Matlab_ROOT, MATLAB_ROOT, Matlab_ROOT_DIR, and MATLAB_ROOT_DIR as well as Trilinos_ROOT and TRILINOS_ROOT
@bartlettroscoe : With @kuberry 's prior work on this, and your recommended changes, it looks like we are not far from building Intrelab as part of Trilinos, rather than a standalone project. This would be much simpler for end users. They would just need some way of setting the Matlab root directory. What are your thoughts on this? I'm perfectly content with the few extra steps to build it separately, however considering that Intrelab is already distributed as part of Intrepid, it may make sense to build it as part of the Trilinos build. |
@dridzal, you can't really build Intrelab as part of Trilinos per-say since it requires an install of Trilinos in order for I am actually going to write a Trilinos CTest test that does the install of Trilinos and another CTest test that builds and runs the example application as part of the Trilinos PR test suite. That will show how this gets done. (But first, I need to merge PR #10614.) |
@dridzal, and actually, if there is a Matlab license on the Trilinos PR build machines, you could even use this to test the Intrelab build and perhaps run some Matlab tests that ensure that this interface layer is working. (Otherwise, you could set up a nightly build on a machine with a Matlab license so you would know within 24 hours if any Trilinos commit broke it.) |
@bartlettroscoe : Thanks for the info, that sounds very promising. A tested build against Matlab would be another important step. There are other packages, like @trilinos/muelu , that could benefit from this infrastructure. For now, let's complete this first step of modernizing the "manual" build, and then we'll attack the "fully automated" build in the next iteration. |
- Adds -O3, -mtune, -march flags for Release builds
6276f8e
to
f772b2a
Compare
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.
Tests pass.
@bartlettroscoe This is ready to go. Please feel free to merge with #10614 when you are ready. |
FYI: With the merge commit 16a8e73 to the branch https://github.com/bartlettroscoe/Trilinos/tree/tribits-299-modern-cmake-targets-1-again-2, this PR will merge automatically when the PR #10614 is merged to 'develop'. |
@trilinos/intrepid
Motivation
Switch to the modern target based CMake for building mex files.