rclone
seamlessly connects to remote cloud storage for cloud storage services including
Google Shared Drive,
Dropbox,
Microsoft OneDrive and many more providers.
The rclone CLI is easier than rsync.
rclone works with encrypted filesystems.
Setup Rclone:
Linux: winget install Rclone.Rclone
macOS / Homebrew: brew install rclone
Windows: winget install Rclone.Rclone
Add various remote file shares (Google Drive, Dropbox, etc.) by:
rclone config
In these examples, remote is the particular drive name chosen during rclone config.
If too much
swap space
is filled, the system could become unusable until force-rebooted due to very slow hard drive (or SSD) I/O relative to RAM.
It can be better to have the application terminated automatically due to running out of RAM instead of having the system become inaccessible until force-rebooted.
There are
disadvantages
for no swap file.
If not using hibernation, 100 MB swap size is a general starting point for laptop, desktop and embedded systems.
Consider the specific situation and test before deployment to avoid unexpected impacts.
Setting swapfile size is only for systems using a swapfile versus a
swap partition.
For systems using
Dphys-swapfile
such as Raspberry Pi, check swap status:
The tilde “~” character is used by most terminal shells as shorthand for the user home directory.
The home directory is typically a safer place to write files than the system root directory, so ~ give a convenient way to refer to an absolute path generic across systems.
Many code languages require parsing the tilde, including Python, C++, Fortran and Matlab.
GNU Octave understands that ~ tilde is the user’s home directory on any operating system, even Windows.
Matlab does not consistently understand ~ as the user home directory, particularly on Windows.
For more advanced Python-like subprocess control from Matlab, use
matlab-stdlib subprocess_run()
that allows setting environment variables, cwd, stdin pipe, timeout, and more.
Environment variables in CMake
set outside of CMake before a CMake process is started have global scope in CMake.
Setting environment variables in a CMake script don’t have visibility outside the current CMake process.
That includes CMake ExternalProject, which will NOT see
environment variables set(ENV{name})
in the parent CMake project.
Also, build and test processes will NOT see environment variables set in the CMake script.
To make environment variables take effect in a CMake script or CMake configure, set the environment variable before running CMake, or on a Unix-like OS on the command line.
For example, to tell
CMake the HDF5
library location, set environment variable
HDF5_ROOT
before the first CMake configure command:
# Unix-likeHDF5_ROOT=~/mylib cmake -Bbuild
# Windows PowerShell$env:HDF5_ROOT="~/mylib"cmake -B build
Of course, one could also set the CMake variable at configure like:
cmake -Bbuild -DHDF5_ROOT=~/mylib
To make environment variables present during a CMake build, for example for an
ExternalProject,
do as above for the configure.
To control environment variables present for CTest tests, including for individual tests, set
test properties.
For modern Fortran development, “.f90” is the recommended filename suffix.
For legacy Fortran 77 code, “.f” is the recommended filename suffix.
To preprocess Fortran code files (e.g. with #ifdef statements), capitalize the filename suffix e.g. “.F90”
Failing to capitalize the suffix of code that requires preprocessing can break build systems such as CMake and Meson.
The introspection of Fortran code by CMake or Meson may make an incorrect build graph if the preprocessing is not done.
This can show up as random (or deterministic) build failures, whether in serial or parallel build.
We use the first “free-form” syntax Fortran 90 standard “.f90” suffix to indicate the current Fortran standard.
This helps avoid too many ambiguous file suffixes.
C and C++ likewise do not indicate their language standard year in the source code file suffix.
Common among build systems is the use of environment variables
CC,
CXX,
FC
to signal user intent to use a compiler, regardless of what appears first in environment variable PATH.
A contradiction can arise for a CMake project using ExternalProject in that
CMAKE_C_COMPILER et al
are not automatically passed to the ExternalProject.
Thus if environment variable “CC=gcc” but the top-level project user specified “cmake -DCMAKE_C_COMPILER=icx”, the top level CMake project would use icx IntelLLVM but the subproject would use GCC, which can cause unintended results.
The fix for this issue is to explicitly pass CMAKE_C_COMPILER et al to the ExternalProject CMAKE_ARGS if the subproject is also a CMake project.