| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This commit strips out all references to the Slurm API, instead making
subprocess calls to sbatch and scontrol.
Attempting to use the Slurm API seems to have been a mis-step. First,
it seems that nowhere has the Slurm headers pre-installed. Literally
none of the facilities where there are known deployments of CrystFEL
have them. And in a significant fraction of cases, getting them
installed is difficult, slow or impossible.
In addition, the API doesn't seem to work in all cases, so we already
shell out to 'scancel' to abort jobs - see d76fc3495.
There are some tricky implications for submitting Slurm jobs from a
container via the API. The Slurm REST API offers a solution, but is
very new and not widely available. Calls to the Slurm executables are
much easier to 'tunnel' out of a container.
This isn't a great solution. It's a net increase of only about 40 lines
of source code, but it incurs some unpleasant string handling and will
probably be less reliable overall. It completely relies on Slurm's not
being internationalised. If Slurm's messages start getting translated,
we will be in trouble.
|
|
|
|
|
|
|
|
|
|
|
|
This makes it explicit that the Meson and Ninja steps should be run from
the CrystFEL folder, not (e.g.) the Meson folder.
|
|
|
|
|
|
|
|
It's only used once, to get background colours for 'indexamajig
--int-diag', itself a rarely used feature. The dependency itself seems
to cause problems for some people, particularly those not using system
libraries for everything. So I think it's better just to remove it, and
use ANSI escape codes directly.
|
|
|
|
|
|
|
|
|
|
0.55 is required for wraps with patch_directory.
|
|
|
|
|
|
|
|
Better understanding of the fPIC problem.
|
|
|
|
|
|
|
|
|
|
|
