use mpi_f08 is recommended for
Fortran
across computing platforms, including Windows.
For native x86 (Intel / AMD CPU) binaries, currently only free Intel oneAPI has mpi_f08 for Fortran.
Windows Subsystem for Linux can use OpenMPI or MPICH to access mpi_f08. For Windows ARM CPU users, Windows Subsystem for Linux is currently the only option for mpi_f08 in Fortran.
Hugo uses Chroma for code syntax highlighting. That is, when putting a code fence block into the Markdown source that is rendered by Hugo into a webpage, Hugo uses Chroma to highlight syntactical elements of the code similar to a modern IDE or Gist-like services, making the code more readable. Auto-detection of code languages is a computationally-intensive task, particularly for unlabeled code snippets. The webpage author specifies the code language using the Chroma alias.
For example, for Fortran or PowerShell scripts, the leading code fence is like:
```fortran```ps1Rather than putting a lot of development environment paths into environment variable PATH, it can be preferable to make little shell / PowerShell scripts and invoke the programs that way. For example, when testing multiple versions of the Python interpreter on a script, a simple method can be to create a one-liner Powershell script for each Python version, passing all command line arguments to the Python interpreter.
& $env:LOCALAPPDATA\\Programs\\Python\\Python3x\\python.exe $argsthe preceding ampersand “&” makes this a Call so that the command line is expanded properly.
For Unix-like shells:
$HOME/python3.x/bin/python "$@"CMake can place a .gitignore file in the top-level build directory to allow making build directories with arbitrary names not cause Git clutter. Rather than adding arbitrary directory names to the project-wide .gitignore, be programmatic by having CMake create a .gitignore in the out-of-source build directory.
In general, it is recommended to use out-of-source builds with CMake as well as other build systems in general. Meson build system does not allow in-source builds.
Put this line of code in the top-level CMakeLists.txt to auto-ignore out-of-source build directory tree.
if(NOT PROJECT_SOURCE_DIR STREQUAL PROJECT_BINARY_DIR)
# Git auto-ignore out-of-source build directory
file(GENERATE OUTPUT .gitignore CONTENT "*")
endif()CMake does pure lexical file path operations via cmake_path, including normalizing paths. To resolve symbolic links and expand “~” tilde to home directory, use file(REAL_PATH).
This example shows the distinct behavior versus get_filename_component(REALPATH), including on case-insensitive filesystems such as macOS and Windows.
A key feature of meta-build systems is dynamically testing system capabilities. Dynamic checks are easier to maintain and use versus large if-else trees or requiring the user to manually include specific Makefiles, etc. In CMake, dynamic testing via check* module functions generally wrap try_compile with logic to only run the check once. try_compile() will run each time CMake runs unless additional if() guard logic is put around try_compile().
check_source_compiles shows the influence six variables CMAKE_REQUIRED* have on the check* functions. Rather than manually setting CMAKE_REQUIRED_FLAGS with compiler language standard flags, instead we recommend setting CMAKE_CXX_STANDARD or similar variable for the code language being checked. The CMAKE_CXX_STANDARD (or similar for C etc.) takes effect in the check* functions.
GNU Octave offers the syntax of Matlab in an open-source software suite. Octave binaries are readily installed:
For Linux, Flatpak may already be installed by the Linux distro. The flathub repo is added by:
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepoFor practical purposes, Git over HTTPS works with Overleaf if others aren’t editing the same document at the same time via the web interface. Overleaf has a single Git branch and requires a linear Git commit history (no force Git push). If other users are using the normal web interface of Overleaf to edit the same document, Git merge will be frequently needed on local Git, which may be inconvenient. Practically speaking, if coworkers on the same Overleaf LaTeX document are using Git to push local edits, and they use Overleaf just to view, it can work OK.
The Git repo URL is given from the Overleaf project, under Menu → Sync → Git. The Git URL is a long hexadecimal number. As usual with Git, clone to a human-friendly directory name like “paper1”.
git clone https://git.overleaf.com/<hash> paper1Some Overleaf projects may be large (100s of MB) and can take minutes to download. To show progress while Git cloning in general, add the –verbose “git clone” option.
Computer-wide Git pre-commit hooks may be bothersome when uploading. To disable Git pre-commit hooks for the repo:
git config core.hooksPath " "Overleaf Git interface uses token authentication.
Git can use HTTPS credential cache mechanisms–on Windows consider Microsoft Git Credential Manager. A Git credential cache can avoid typing the password for each remote Git operation. The command below remembers the Git HTTPS password for 300 seconds (5 minutes).
git config credential.helper 'cache --timeout=300'Since Overleaf Git tracking is limited, one may wish to disable GPG signing to avoid the burden of typing the additional GPG password on Git commit. As usual, this can be done on a per-Git-repo basis like:
git config commit.gpgsign falseCMake execute_process doesn’t print to stdout until the process ends or flushes the stdout buffer. This is shown by example. The stdout print before flush behavior may be platform-dependent in general, but we observed that CMake didn’t print till flushed.
GitHub only allows a user to have one fork derived from a repo. For maintainers of popular repos, this can be an issue as there may be many forks and forks of forks etc. To collaborate with an active contributor who is not a member of the original repo, there arises an issue since the maintainer can’t fork the contributor repo since the maintainer probably already has a fork of the original repo.
A technique we use for this is to create a branch in the original repo and then create a pull request from the contributor’s fork to the branch in the original repo (or vice versa for the pull request). That is, if the maintainer wants to make a pull request to the contributor repo, the maintainer creates a branch in the original repo and then creates a pull request from that branch to the forked repo.
From the original local repo, add the contributor’s fork as a remote.
git remote add contrib1 https://github.invalid/contrib1/repo.gitFetch the contributor’s fork.
git fetch contrib1Create a local branch tracking the contributor’s remote branch.
git switch -c contrib1-feat1 --track contrib1/feat1Make changes, commit, and push
git push -u origin contrib1-feat1You may need to manually compose the URL for the pull request. For this example, it would be like:
https://github.invalid/contrib1/repo/compare/feat1...orgname:repo:contrib1-feat1