CMake
find_program
does not generally consider NAMES parameter to have file suffixes unless manually specified.
A special case is Windows, where
.com and .exe
file suffixes are also considered.
If on Windows and an executable “hello.exe” or “hello.com” exists, then CMake will find it.
CMake would NOT find “hello.exe” on non-Windows platforms, where no file suffix is expected.
Intel oneAPI 2023 provides GNU-like and MSVC-like
compiler drivers
for Windows.
This is a good thing, but CMake had assumptions that only C++ compiler driver icpx OR icx would be present.
CMake 3.25.2
fixed
oneAPI 2023 compiler detection on Windows.
Long term, GNU-like
support for Windows
may also come.
Until you update CMake, you can workaround this issue of C++ oneAPI compiler detection on Windows by configuring the CMake project like:
Visual Studio executables built in Debug mode by default pop up
modal
debug windows if an unhandled exception occurs.
This can be annoying to developers particularly when unit testing a project.
On remote systems, modal windows can become a real issue if the modal window is accidentally off-screen.
In such cases it is sometimes hard to get the modal window back to the main desktop to be closed.
Adding a few lines of code to the C++ program works around this issue by redirecting the error text to stderr console and not popping up the modal window.
_CrtSetReportMode keeps the model window from appearing.
_CrtSetReportFile redirects the message text to stderr so that the message can be diagnosed.
By design, CTest
WILL_FAIL
test property
does not handle
segmentation faults and other unexpected terminations.
That is, a failing test will also show as failed in CTest, when the desire may have been to show an intended failure as success via WILL_FAIL.
A simple workaround for this is to make a wrapper script that calls the intentionally segfaulting executable and catch that result, and pass that to CTest, as in this example project.
Visual Studio can detect memory leaks in programs with
_CrtDumpMemoryLeaks.
This minimal example doesn’t do the printout.
Using these checks requires the project is build in Debug mode.
More complete working minimal example that prints the memory diagnostics with Visual Studio.
On Linux, Valgrind can be used to detect memory leaks.
Numerous other free memory checkers are available and work with CMake CTest frontend.
#ifdef _MSC_VER
#include<crtdbg.h>#endif
intmain(void){
char* c
c = malloc( 100 );
// unfreed memory, a deliberate leak
// near the end of the function to be checked
#ifdef _MSC_VER
_CrtDumpMemoryLeaks();
#endif
return0;
}
With distutils proposed deprecation in Python 3.10,
migration
to setuptools is a topic being worked on by major packages such as Numpy.
Aside from major packages in the Scipy/Numpy stack, I don’t recall many current packages setup.py relying on distutils. However, there is code in some packages using import distutils that could break.
I applaud the decision to remove distutils from Python stdlib despite the fallout.
The fallout is a symptom of the legacy baggage of Python’s packaging.
Non-stdlib packages like setuptools are so much more nimble that sorely needed improvements can be made more rapidly.
Matplotlib on any platform can use FFmpeg, Avconv or Mencoder to directly write lossy or lossless compressed movies created from sequences of plots.
Instead of creating hundreds of PNGs, or skipping plots and missing details, Matplotlib movies of a large sequence of plots is highly effective for many processes that evolve across time and/or space.
In matplotlib_writeavi.py,
just four added lines of code do the AVI writing.
First line tells Matplotlib to use
FFmpeg.
Second line tells Matplotlib to make a lossless FFV1 video at 15 frames/sec.
One can optionally use codec='mpeg4', but lossy encoding can wash out details of plots.
Third line says to use 100 DPI (smaller DPI–smaller file and movie size).
The macOS terminal defaults to UTF8.
When SSHing into a Mac computer from a non-macOS computer, or any computer with a different locale, there may be problems running programs on the remote Mac where locale is important.
For example, a Linux system with “C” locale may cause .zip archive extraction on the remote Mac to fail like:
Pathname cannot be converted from UTF-8 to current locale.
Locally on the Mac (or using Remote Desktop over SSH), check locale with:
Python packaging can be described in pyproject.toml alone per PEP 621.
These packages are installable in live developer mode:
python -m pip install -e .
Or via PyPI like any other Python package.
It can be most effective to put all project configuration, including Python package prerequisites in pyproject.toml alone as a single source of truth.
pyproject.toml is human-readable and machine-parseable without first installing the package.
Putting all package metadata into pyproject.toml instead of setup.py gives benefits including:
reproducible results
security risk mitigation
dynamic prerequisite tree based on Python version etc.
static or dynamic package version
This is an example of a minimal pyproject.toml that works all alone, no other metadata files required, except perhaps MANIFEST.in for advanced cases.
The __version__ is contained in file mypkg/__init__.py as Python code:
__version__ ="1.2.3"
pyproject.toml:
[build-system]
requires = ["setuptools>=61.0.0", "wheel"]
build-backend = "setuptools.build_meta"[project]
name = "mypkg"description = "My really awesome package."keywords = ["random", "cool"]
classifiers = ["Development Status :: 5 - Production/Stable",
"Environment :: Console",
"Intended Audience :: Science/Research",
"Operating System :: OS Independent",
"Programming Language :: Python :: 3",
]
requires-python = ">=3.7"dynamic = ["version", "readme"]
[tool.setuptools.dynamic]
readme = {file = ["README.md"], content-type = "text/markdown"}
version = {attr = "mypkg.__version__"}
PEP8 checking via flake8 is configured in .flake8: