Skip to content

Use environment variable to pass external module paths to the compiler #452

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
milancurcic opened this issue Apr 19, 2021 · 3 comments
Open

Comments

@milancurcic
Copy link
Member

Since #438, it's possible to use external (non-fpm packaged) modules as dependencies.

There are currently two possible ways to do this:

  1. Pass the path explicitly via --flag, e.g.:
fpm build --flag "-I/path/to/my/external/dependencies"
  1. 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 @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.

@certik
Copy link
Member

certik commented Apr 19, 2021

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.

@LKedward
Copy link
Member

+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.

@milancurcic
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants