Features could be added to require these.

They should somehow use these C API functions to validate that the functionality is present in system libraries:

int lammps_config_has_gzip_support();
int lammps_config_has_png_support();
int lammps_config_has_jpeg_support();
int lammps_config_has_ffmpeg_support();

When activated in an automatic build, they should set the corresponding cmake flags to yes.

I don't think these features should be enabled by default, for the same reasons that exceptions is not on by default. However, unlike for mpi, I believe it is okay that cmake should be allowed to enable these libraries if they are found, even without the feature. (so without the feature, we should do nothing, rather than defining WITH_JPEG=no). This is because they do not require additional effort from us to link them, given that cmake could find them. (whereas linking MPI requires querying mpicxx)

...I think. I could be wrong.

I have no need for any of this myself, so I'll leave the effort to somebody who does. ;)

This is a big reason why my own code still uses v0.3.x. I need dynamic linking for the occasional time I need to modify the LAMMPS source.

Back when I was writing 0.4.x, I briefly considered having static and dynamic flags, but chickened out. Kornelski gives some good best practices here: https://kornel.ski/rust-sys-crate

In Cargo.toml you can have [features] section with static and dynamic options.

[features]
static = []
dynamic = []

Don't put any of them as Cargo's default feature, because it's too hard to unset defaults in Cargo.

and this gives the toplevel binary crate the power to choose which to use by depending on lammps-sys and activating the appropriate feature.

Trying to build using Windows Subsystem for Linux. This is odd:

This is even more odd:

[ exp @ 22:03:36 ] (master) /mnt/f/asd/clone/rsp2/target/debug/build/lammps-sys-e860d6dc26d88121/out/lammps
$ ls
LICENSE  README  cmake  doc  lib

Where's... where's the src directory!?

I went and tried using the cmake build system to manually build lammps, and it worked just fine, so... yeah. Uhm... something's up.

v0.5.0 will be far from perfect, but I feel that, now that we have the option to choose between system libs and automatic builds, it is finally usable enough to be ready for crates.io.

Issue #10 was able to slip by unnoticed because I had a system install of lammps when I packaged the crate. This is the kind of stuff travis is for.

The travis test for automatic builds should specifically include a call to cargo package, to make sure nothing essential from the lammps submodule is accidentally excluded.

The ./lammps/potentials/* exclude rule in Cargo.toml not only excludes the contents of the potentials directory, but it even gets rid of the directory itself!

Also, we need to keep the manpage under doc which it tries to install.

Wonderful things were added to library.h in recent versions:

int lammps_config_has_package(char * package_name);
int lammps_config_package_count();
int lammps_config_package_name(int index, char * buffer, int max_size);

It would be awesome to use these somehow to validate that certain features have been enabled in a system installation of lammps. Like the exceptions feature, we could reject a system library missing these features and fall back to a source build.

The code for building from source in the 0.4.x branch is pretty nasty, and even does stuff like editing a Makefile. I'd love to get rid of it.

It turns out that Lammps has some (tragically underadvertised!) cmake configuration files, which appear to aim to solve a great deal of the problems that lammps-sys needs to solve, and quite probably in a better manner than how lammps-sys does it. It'd be nice to be able to use those.

There is a known issue that the current version of lammps-sys is incompatible with crates that use recent versions of bindgen or clang-sys.

This is due to problems upstream. Basically, we're waiting for a number of upstream crates to update their dependencies:

• You cannot have multiple versions of clang-sys due to it declaring the links property.
• libffi-sys uses an old bindgen that uses an old clang-sys
• mpi-sys uses libffi-sys and therefore must also use an old bindgen
• lammps-sys uses mpi-sys and therefore must also use an old bindgen

Currently I can't even build 0.4.x for the potentials that I use!

At bare minimum I personally need a feature for

make yes-manybody

...but really, what I should do is find a complete listing of these packages somewhere in the LAMMPS documentation.

Also says "unreleased" in release notes

Currently lammps-sys depends on an unreleased master commit of LAMMPS for some bugfixes. Once LAMMPS gets another release, v0.5.0 can be released.

(for future reference, at the time of writing, the latest release is patch_5Sep2018)

I consider it suboptimal that lammps-sys only cares about pkg-config when searching for system libraries. The trouble is that a liblammps.pc file will almost never exist in PKG_CONFIG_PATH for any typical installation of LAMMPS, because this is not something people normally need to worry about (entries in LD_LIBRARY_PATH and C_INCLUDE_PATH are usually all you need!).

However, the reason that it only cares about pkg-config at the moment is because there needs to be a clear way for the build script to determine when the libraries are NOT present, so that it knows when to fall back to performing an automatic build. And I'm not sure what the right way is to do that. (is there something we can do at build-script time to determine whether an -l library would be found by the linker when invoked by rustc?)

While trying to update the building from source guide, I tried building my own copy of LAMMPS and ran into a number of issues:

• The use of the ptr argument to lammps_open is deprecated; the function now returns a pointer.
  • Unfortunately this makes it unclear how to fix lammps_open, which we need to define ourselves to avoid incompatibilities with how rsmpi defines MPI_Comm.
    • Thankfully, the current signature void(*) (int, **char, MPI_Comm, **void) is loosely ABI-compatible with the old signature void (int, **char, MPI_Comm, **void) in most modern calling conventions.
    • ...unfortunately I'm getting a segfault when I try to test with this.
    • There is still no update to mpi-sys
• -DBUILD_LIB=on is no longer required`
• Many packages were renamed or split up.
  • Here's the documented list as of 2022-03-07:
    ADIOS ASPHERE ATC AWPMD BOCS BODY BROWNIAN CG-DNA CG-SDK CLASS2 COLLOID COLVARS COMPRESS CORESHELL DIELECTRIC DIFFRACTION DIPOLE DPD-BASIC DPD-MESO DPD-REACT DPD-SMOOTH DRUDE EFF EXTRA-COMPUTE EXTRA-DUMP EXTRA-FIX EXTRA-MOLECULE EXTRA-PAIR FEP GPU GRANULAR H5MD INTEL INTERLAYER KIM KOKKOS KSPACE LATBOLTZ LATTE MACHDYN MANIFOLD MANYBODY MC MDI MEAM MESONT MESSAGE MGPT MISC ML-HDNNP ML-IAP ML-PACE ML-QUIP ML-RANN ML-SNAP MOFFF MOLECULE MOLFILE MPIIO MSCG NETCDF OPENMP OPT ORIENT PERI PHONON PLUGIN PLUMED POEMS PTM PYTHON QEQ QMMM QTB REACTION REAXFF REPLICA RIGID SCAFACOS SHOCK SMTBQ SPH SPIN SRD TALLY UEF VORONOI VTK YAFF
• Virtually any update related to any of this is going to require adding CI Testing on a matrix of MPI/no-MPI, system/build, and a small number of "tested" lammps versions, because it's beyond the point where I have the bandwidth to test all of this.