[BugFix] Modernize CMake, remove object libraries, build Simulink MEX#1555
Merged
deslaughter merged 5 commits intoOpenFAST:devfrom May 4, 2023
Merged
[BugFix] Modernize CMake, remove object libraries, build Simulink MEX#1555deslaughter merged 5 commits intoOpenFAST:devfrom
deslaughter merged 5 commits intoOpenFAST:devfrom
Conversation
This commit undoes most of the changes in PR OpenFAST#1010 which introduced object libraries into the build system to produce a statically linked MEX file for Simulink. The Object Libraries were somewhat complex and didn't behave the same as normal libraries. While trying to debug a compilation issue on an M1 mac the CMake `matlab_add_mex` function was discovered which could build a static mex file within CMake. The build system was reworked to use this feature.
There was some duplication in processing of OpenMP flags between FAST.Farm and openfastcpp which caused compile issues. Finding the package and adding flags were moved to the main CMakeLists.txt. This also sets the LINKER_LANGUAGE to Fortran for openfastlib and fixes a typo in the VersionInfo CMake file.
Also set number of parallel builds using CMAKE_BUILD_PARALLEL_LEVEL environment variable instead of specifying -j. Total action run time reduced by 10-15 minutes
andrew-platt
approved these changes
May 4, 2023
deslaughter
added a commit
that referenced
this pull request
May 9, 2023
The module name was incorrectly changed to `versioninfolib` when the CMakeLists.txt files were revised in PR #1555.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request is ready to be merged.
Related issue, if one exists
This PR addresses issue #1551 where compilation fails on an M1 mac.
Impacted areas of the software
CMakeLists.txtfilesautomated-dev-tests.yml- updated to Ubuntu 22.04 and gcc-12Additional supporting information
This PR, #1535, and #1530 address issues created by PR #1010 which used CMake object libraries to statically link the Simulink MEX file. These object libraries created a lot of complexity in the build system and made the module dependencies confusing. This PR removes the object libraries and uses CMake's
matlab_add_mexfunction (https://cmake.org/cmake/help/latest/module/FindMatlab.html#command:matlab_add_mex) to build the MEX file directly, instead of relying oncreate_FAST_SFunc.m. The MEX file links againstopenfast_preliband recompiles parts ofopenfast_postlibwithCOMPILE_SIMULINKdefined. This these libraries are statically linked, it should solve the problems that PR #1010 were originally trying to solve. It also makes the process of build the MEX file easier when using CMake.create_FAST_SFunc.mshould still be used when building with Visual Studio on Windows.Various other improvements were made to the CMake build system:
target_include_directoriesto specify includes per targettarget_compile_definitionsto reduce the scope of preprocessor definesFindMatlab.cmakesince it's included in CMakeTest results, if applicable
All tests are passing when compiled with
gfortranandifort