You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Link all modules into a include (default) directory and let fpm pick them up.
Option 1 is verbose and error-prone, especially when you start to include more than one non-fpm dependency into the project. It's particularly bad during development when I want to type fpm build often.
Option 2 is much easier but inelegant. It's difficult to manage different versions of dependencies or dependencies built by different compilers (both are common use cases in my field) because you'd need to replace the files or symlinks.
Rather than managing the external dependency modules on a file system level, I suggest to introduce an fpm-specific environment variable to pass the paths to the compiler.
Originally proposed by @LKedwardhere. A candidate variable name, proposed by @certikhere, is FPM_EXTERNAL_MODULES_PATH. Which I like as well.
#444 would solve this (variable name aside), but it turns out it was trying to solve something else.
The text was updated successfully, but these errors were encountered:
It seems if we get FPM_EXTERNAL_MODULES_PATH working, then we can later move to CPATH if that is what we would like, but it gets the feature implemented. I think we can change things until we reach fpm 1.0, so the above should work.
+1 from me. As per my original comment, this isn't meant as a perfect long-term solution, rather it simply allows fpm projects to easily use system-installed modules right away. It is noted that we harm reproducibility, but this is the nature of using system-installed modules, not the proposed method of doing so in fpm.
It seems if we get FPM_EXTERNAL_MODULES_PATH working, then we can later move to CPATH if that is what we would like, but it gets the feature implemented.
I don't think there will be a need for CPATH once FPM_EXTERNAL_MODULES_PATH is working. I think CPATH came up only because some compilers use it as their own convention to find modules, but I've never used it myself.
Since #438, it's possible to use external (non-fpm packaged) modules as dependencies.
There are currently two possible ways to do this:
--flag
, e.g.:include
(default) directory and let fpm pick them up.Option 1 is verbose and error-prone, especially when you start to include more than one non-fpm dependency into the project. It's particularly bad during development when I want to type
fpm build
often.Option 2 is much easier but inelegant. It's difficult to manage different versions of dependencies or dependencies built by different compilers (both are common use cases in my field) because you'd need to replace the files or symlinks.
Rather than managing the external dependency modules on a file system level, I suggest to introduce an fpm-specific environment variable to pass the paths to the compiler.
Originally proposed by @LKedward here. A candidate variable name, proposed by @certik here, is
FPM_EXTERNAL_MODULES_PATH
. Which I like as well.#444 would solve this (variable name aside), but it turns out it was trying to solve something else.
The text was updated successfully, but these errors were encountered: