Need Ability to Specify Options for Specific Files

[everythingfunctional]

With the Haskell version phased out, I checked to see if the Fortran version could build my sqliteff project, and unfortunately it can't. I need to add -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_THREADSAFE=0 when compiling sqlite3.c but I don't have a way to do that with the Fortran version of fpm.

Previously I was using the build script option and a (admittedly not very portable) Makefile. But the Fortran version doesn't support that option (yet).

What do you guys think the proper path forward would be? Should we include a way of specifying additional compiler arguments for specific files? Or should we add the build script option to the Fortran version? I know there was some discussion about that and the implementation from the Haskell version wasn't exactly the design a lot of people wanted to stick with. (see #351, #94, #249, #219 and #118 are the discussions I could find)

I suppose in my case I could just "manually preprocess" the sqlite3.c file so those options wouldn't be needed, but I'd consider that a short term workaround.

[awvwgk]

Looks like you need a way to set preprocessor variables for this in the package manifest by some means. This could be done by setting compiler variables in a compilation profile or by hiding it in some kind of one-way build script, leaving aside that we don't have support for neither, both approaches seem not really well-suited for this purpose IMO. Maybe looking into this together with the preprocessor support in fpm might be the best way forward here.

The package manifest could provide some way to set variables for the preprocessor to static values:

[preprocessor.variables]  # maybe .local/.global for project scope vs. global scope?
SQLITE_OMIT_LOAD_EXTENSION=1
SQLITE_THREADSAFE=0

[everythingfunctional]

I kind of like the idea of preprocessor variables for this use case.

[ivan-pi]

Should there be a command line syntax for this too?

In many cases preprocessor variables are used to deal with platform specific issues (e.g. a processor or compiler supports certain features). Presumably, this would be the job of a custom build script to figure out (e.g. does the compiler support xyz syntax or does my processor have a fused-multiply add instruction) and specify the right options.

In other cases preprocessor variables might be used to choose between different algorithms (accurate algorithm vs sloppy algorithm), which is something the user might want to select at build time, but ultimately the package implementors should strive to offer a sane default.

In case of an interface library like sqliteff it makes sense you have to fix the preprocessor variables at a local project level (through the manifest or a custom build script), and document the consequences it carries for your package (e.g. the library is not thread safe).

What would be the purpose of a preprocessor variable with global scope? (I understand this as a flag given to all project dependencies built by fpm). I'm not sure if this is something which makes sense.

[everythingfunctional]

I think Cargo probably deals with this through their "features" capability and custom build scripts. I'm not quite clear on the design of that capability though, or how well it would mesh with our design of fpm.

[ivan-pi]

Indeed, Cargo build scripts can receive input through a CARGO_CFG_<cfg>variable, and have the possibility to communicate configuration settings back using the instructions

cargo:rustc-cfg=KEY[="VALUE"] — Enables compile-time cfg settings.

Which configuration options are set is determined statically during the compilation of the crate. Certain options are compiler-set based on data about the compilation. Other options are arbitrarily-set, set based on input passed to the compiler outside of the code. It is not possible to set a configuration option from within the source code of the crate being compiled.

The compiler-set options are mainly related to the platform (Unix or Windows) and properties of the target (CPU architecture, CPU features, operating system, pointer width, endianess, etc.) so they cover what I described above as the need for platform-specific preprocessing.

I think it will take a while before we can arrive at something similar, so maybe if we can pinpoint the behavior of simple build scripts in #219 (and replicate the Haskell-fpm behavior) it is the best short-term solution for you.