Is there a way to define the library path -Lpath in the fpm.toml file?
For instance, while it’s possible to specify -lmylib in fpm.toml as:
[build]
link = ["mylib"]
I haven’t found a direct solution to specify the library path -Lpath within the fpm.toml file. However, there are alternative approaches to set the library path outside the fpm.toml file: Using --flag '-Lpath' or --link-flag '-Lpath' or by setting the environment variable LIBRARY_PATH.
I think you’ve already explored all possible ways.
Also for metapackages, library directory flags are added to the set of linking flags like you’re suggesting. Fpm design also seems to suggest that (with ease of use in mind) no control knob for the library directories was planned:
&' # To declare link-time dependencies on external libraries a list of ',& &' # native libraries can be specified with the "link" entry. You may ',& &' # have one library name or a list of strings in case several ',& &' # libraries should be linked. This list of library dependencies is ',& &' # exported to dependent packages. You may have to alter your library ',& &' # search-path to ensure the libraries can be accessed. Typically, ',& &' # this is done with the LD_LIBRARY_PATH environment variable on ULS ',& &' # (Unix-Like Systems). You only specify the core name of the library ',& &' # (as is typical with most programming environments, where you ',& &' # would specify "-lz" on your load command to link against the zlib ',& &' # compression library even though the library file would typically be ',& &' # a file called "libz.a" "or libz.so").
I believe having this feature for fpm would be beneficial, as it would simplify the usage of provided fpm packages that rely on other external libraries.
Encoding system paths into a package configuration file is (IMO), not the right way to go. We could add some “smarts” into fpm about finding the locations of libraries you wish to link to and including them when compiling/linking. This is (IIUC) where CMake shines.
It is currently possible to set paths in the configuration file for include-dir, src-dir, tests, examples, preprocessor, and local dependencies. I think the same capability could be extended to libraries as well, particularly for straightforward scenarios where libraries can be included using relative paths within the package. Why might it be wrong in this case? Or are you suggesting some form of automation for this process?
each of those are generally internal to the package, aside from “local dependencies”, and even those should not be used to point to things outside a repo in published packages. The reason is, it’s not a portable package if it has hard-coded system paths in it. I.e. if your package has something like the following in the fpm.toml file,
library_paths = ['/opt/some/install/path/lib', ...]
Then it A) definitely won’t work on Windows, and B) is highly unlikely to work on anyone else’s system either. It’s not a good idea for a package to make assumptions about where its dependencies will be installed.
I believe there’s a misunderstanding. I didn’t suggest placing local libraries with absolute paths outside the package. The solution is straightforward for certain simple cases: utilize internal relative paths such as library_paths=['lib', ...'] for local libraries.
Additionally, fpm could display a warning if someone attempts to define paths (for any available path settings within the package, such as local dependencies or local libraries or …) outside the package.
It may be already this, but it would be nice if the installation directory is automatically passed to the -L directory list and to the -I directory list (well “-L/lib” and “-I/include”).
It may be nice if when installing the library the “-profile release” is used by default.
One may have an option in fpm.toml like (if a dependence is already installed don’t get and compile it but use the installed one).
One may need a way to check the version and the compiler of the installed library.