Run dependencies tests about fpm HOT 3 OPEN

@epagone good question. Here is how I think we are imagining this will work:

• your program depends on FGSL.
• FGSL will be an fpm package. As such, when you execute fpm test in the FGSL repository, it will test it. (Currently FGSL is not an fpm package. We envision that eventually people would like to make all such libraries an fpm package, but until then, somebody can create simple repository that will be the fpm package for it, and it would fetch the FGSL sources and build it correctly with fpm, and it would ensure that fpm test works.)
• In your program, you would just depend on the FGSL as an fpm package.

To run tests for FGSL, there are two options, you either checkout the FGSL repository and execute fpm test there. Or we can add an option to fpm test, such as fpm test -p FGSL that would execute the tests for FGSL.

I just checked how Cargo does it. And while Cargo has the -p option for cargo test, it only works with local packages in a workspace (one can have multiple packages in a git repository), but it doesn't seem to work for dependencies that are not in the current repository.

We can discuss this more.

from fpm.

Thanks for the explanation @certik, I understand now the logic better. However, I went back to re-read the packaging guide and I think the requirement that the dependency has to be already an fpm package is not stated:

Inevitably you'll want to be able to include other libraries in your project. fpm makes this incredibly simple, by taking care of fetching and compiling your dependencies for you. You just tell it what your dependencies are, and where to find them.

Probably the assumption that the dependency has been already packaged with fpm is implied. Thinking about it, I guess it should not be a big deal to re-package existing libraries in fpm: it's a matter of swapping files in the right directories and writing the fpm.toml file (if I'm not missing anything major).

from fpm.

@epagone yes, that's the most natural approach.

from fpm.