Thanks both - responses below. I’ll preface this by saying that I’m definitely a CMake novice, so there may well be a smarter way of doing things than the approach I ended up with.
Indeed, that’s what I tried first. But apparently, CMake’s local variables (defined by
CACHE) are not the same as CMake’s cache variables (defined by
CACHE). So setting the former doesn’t actually get alter the variable used by
Further reading of various CMake docs indicates that the cache variables are very much designed with command line arguments in mind, and indeed,
-DF2C_EXTERNAL_ARITH_HEADER=path/to/custom/arith.h works fine. However, sometimes it’s nice to just throw it into the
CMakeLists.txt so that it’s included in every build, no matter what. As such, I followed the advice here (see comments about the “make-shift global variable”) to forcibly set it, always, to the desired path.
For those who are interested, I made a little example to demonstrate:
When cross-compiled with Emscripten’s CMake configuration, this gives a warning about an unset
F2C_etc., which is only eliminated when adding those extra flags to
(An extra consideration is that I use the same
CMakeLists.txt to generate the
arith.h in the first place, by adding some instructions to cross-compile and execute the
arithchk.c thing. In this case, it’s natural to set the
F2C_etc. variable inside the
CMakeLists.txt because CMake already knows the location of the newly generated
arith.h. Setting it on the command line makes it a bit more awkward because I need to manually ensure that the path I generated inside the
CMakeLists.txt is the same as that used on the command line.)
To be honest, I think the real issue here is that CMake’s way of setting cache variables inside
CMakeLists.txt is way more complicated than setting it on the command line. Maybe this is by design, I don’t know, but it isn’t really an issue with igraph itself. Nonetheless, it would have been helpful if the igraph C installation docs provided a link to some instructions on setting these cache variables inside the
CMakeLists.txt, given that the same documentation already shows how to set some of these variables in command-line
Static linking is possible, but not for object files generated for the host architecture. I basically need to build
libgraph.a as a Wasm “static library”, and then I link my project (also compiled to Wasm) to that. Which makes sense to me; the Wasm binary won’t have the full numerical capabilities of any given host architecture, given that the same binary needs to run on everyone’s browser.
So, I could certainly compile igraph somewhere else and re-use the resulting
libgraph.a static library in all my igraph-related Wasm projects. But that initial compilation would still need to use a separate toolchain and a different
arith.h that is appropriate to the Wasm target.