mfem
mfem copied to clipboard
Improve support for out-of-tree installations
Hi,
The changes here have the objective of allowing a classical build (i.e. one via the provided makefile
) to install the required files on a system directory (via PREFIX=
) with suitable permissions for use by everyone in that system.
In addition, a user (or a module file for instance) should then be able to set MFEM_INSTALL_DIR
allowing the use of the provided makefile
s to build examples, miniapps and tests. Note the idea to use or
and wildcard
comes from an existing makefile
:
https://github.com/mfem/mfem/blob/12ed616e47ea47c6d36a4c40290cf41510544914/tests/par-mesh-format/makefile#L16-L17
Cheers, -Nuno
PR | Author | Editor | Reviewers | Assignment | Approval | Merge |
---|---|---|---|---|---|---|
#4252 | @nmnobre | @tzanio | @v-dobrev + @tzanio + @justinlaughlin | 5/11/24 | ⌛due 5/25/24 | ⌛due 6/1/24 |
PR Checklist
- [ ] Code builds.
- [ ] Code passes
make style
. - [ ] Update
CHANGELOG
:- [ ] Is this a new feature users need to be aware of? New or updated example or miniapp?
- [ ] Does it make sense to create a new section in the
CHANGELOG
to group with other related features?
- [ ] Update
INSTALL
:- [ ] Had a new optional library been added? If so, what range of versions of this library are required? (Make sure the external library is compatible with our BSD license, e.g. it is not licensed under GPL!)
- [ ] Have the version ranges for any required or optional libraries changed?
- [ ] Does
make
orcmake
have a new target? - [ ] Did the requirements or the installation process change? (rare)
- [ ] Update continuous integration server configurations if necessary (e.g. with new version requirements for each of MFEM's dependencies)
- [ ]
.github
- [ ]
.appveyor.yml
- [ ]
- [ ] Update
.gitignore
:- [ ] Check if
make distclean; git status
shows any files that were generated from the source by the project (not an IDE) but we don't want to track in the repository. - [ ] Add new patterns (just for the new files above) and re-run the above test.
- [ ] Check if
- [ ] New examples:
- [ ] All sample runs at the top of the example source file work.
- [ ] Update
examples/makefile
:- [ ] Add the example code to the appropriate
SEQ_EXAMPLES
andPAR_EXAMPLES
variables. - [ ] Add any files generated by it to the
clean
target. - [ ] Add the example binary and any files generated by it to the top-level
.gitignore
file.
- [ ] Add the example code to the appropriate
- [ ] Update
examples/CMakeLists.txt
:- [ ] Add the example code to the
ALL_EXE_SRCS
variable. - [ ] Make sure
THIS_TEST_OPTIONS
is set correctly for the new example.
- [ ] Add the example code to the
- [ ] List the new example in
doc/CodeDocumentation.dox
. - [ ] If new examples directory (e.g.
examples/pumi
), list it indoc/CodeDocumentation.conf.in
- [ ] Companion pull request for documentation in mfem/web repo:
- [ ] Update or add example-specific documentation, see e.g. the
src/examples.md
. - [ ] Add the description, labels and screenshots in
src/examples.md
andsrc/img
. - [ ] In
examples.md
, list the example under the appropriate categories, add new categories if necessary. - [ ] Add a short description of the example in the "Extensive Examples" section of
features.md
.
- [ ] Update or add example-specific documentation, see e.g. the
- [ ] New miniapps:
- [ ] All sample runs at the top of the miniapp source file work.
- [ ] Update top-level
makefile
andmakefile
in corresponding miniapp directory. - [ ] Add the miniapp binary and any files generated by it to the top-level
.gitignore
file. - [ ] Update CMake build system:
- [ ] Update the
CMakeLists.txt
file in theminiapps
directory, if the new miniapp is in a new directory. - [ ] Add/update the
CMakeLists.txt
file in the new miniapp directory. - [ ] Consider adding a new test for the new miniapp.
- [ ] Update the
- [ ] List the new miniapp in
doc/CodeDocumentation.dox
- [ ] If new miniapps directory (e.g.
miniapps/nurbs
), add it toMINIAPP_SUBDIRS
in themakefile
. - [ ] If new miniapps directory (e.g.
miniapps/nurbs
), list it indoc/CodeDocumentation.conf.in
- [ ] Companion pull request for documentation in mfem/web repo:
- [ ] Update or add miniapp-specific documentation, see e.g. the
src/meshing.md
andsrc/electromagnetics.md
files. - [ ] Add the description, labels and screenshots in
src/examples.md
andsrc/img
. - [ ] The miniapps go at the end of the page, and are usually listed only under a specific "Application (PDE)" category.
- [ ] Add a short description of the miniapp in the "Extensive Examples" section of
features.md
.
- [ ] Update or add miniapp-specific documentation, see e.g. the
- [ ] New capability:
- [ ] All new public, protected, and private classes, methods, data members, and functions have full Doxygen-style documentation in source comments. Documentation should include descriptions of member data, function arguments and return values, template parameters, and prerequisites for calling new functions.
- [ ] Pointer arguments and return values must specify whether ownership is being transferred or lent with the call.
- [ ] Any new functions should include descriptions of their intended use e.g. for internal use only, user-facing, etc., along with references to example code whenever possible/appropriate.
- [ ] Consider adding new sample runs in existing examples to highlight the new capability.
- [ ] Consider saving cool simulation pictures with the new capability in the Confluence gallery (LLNL only) or submitting them, via pull request, to the gallery section of the
mfem/web
repo. - [ ] If this is a major new feature, consider mentioning it in the short summary inside
README
(rare). - [ ] List major new classes in
doc/CodeDocumentation.dox
(rare).
- [ ] Update this checklist, if the new pull request affects it.
- [ ] Run
make unittest
to make sure all unit tests pass. - [ ] Run the tests in
tests/scripts
. - [ ] (LLNL only) After merging:
- [ ] Update internal tests to include the new features.
Hi @nmnobre, if this is ready, can you mark it with the ready-for-review
label please?
(See also the CONTRIBUTING document.)
Hi @nmnobre, if this is ready, can you mark it with the
ready-for-review
label please?
I can't, I don't think I have triage access on this repo.
Hi @nmnobre, if this is ready, can you mark it with the
ready-for-review
label please?I can't, I don't think I have triage access on this repo.
Can you please try again?
This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.
Merged in next
for testing...