Brad Richardson

In your case, I'd recommend using a wrapper script to make doing things properly a bit easier. Something like ```bash #!/bin/bash expected_archive=$1 make all F95=$FC cp where/your/*.mod $BUILD_DIR cp where/your/archive.a...

fpm calls that script with the appropriate argument. So assuming your script is called `build_script.sh`, your `fpm.toml` would look like ```toml ... [library] source-dir = "src" # presumably build_script =...

I'm not sure I have a thoroughly compelling answer, but my thinking is along the lines of the following: - We should conform to common practices in existing build systems...

The mod files need to go in the same place.

> I would suggest to follow Cargo's approach, and not invent our own conventions. > […](#) > On Tue, Jul 14, 2020, at 5:05 PM, Brad Richardson wrote: I'm not...

I think we should move towards Cargo's API design. Then the communication mechanism can be the same for any build script; inputs as environment variables, outputs as prefixed lines on...

A quick note, `BUILD_DIR` is always `build/_/project`, whether it's building your project standalone or as a dependency. So when building your project as a dependency, the `BUILD_DIR` is not within...

I lean towards option 2. Note that (I think) you'll have to deal with integer vs floating-point vs string values when adding the macros to the compile/pre-process command in different...

> Why make the additional effort to have separate tables for macros with and without values, they are not really that much different. ``` [preprocess] cpp.macros = ["FOO", "BAR", "TESTMACRO1=4",...

Just a note, if you tie the build directory to the compiler options, as I've done for h-fpm, then you have to pass the same options to `fpm run`, or...