Right now the given a
@[Link("foo" ... )] statement the compiler will do the best it can to find the library to link.
That process is basically for posix environments that for each
pkg-configis installed it will ask to it using
pkg-config foo --libs [--static]
For simple use cases, this is enough. But there are a couple of limitations:
- It’s hard for the end user to link to a custom build of the library, for example with debug information.
- If a shard requires a library the user has no opinion whether the library can be linked statically or not.
- In OSX it is possible to link to a static library in some cases but that requires the full path to
We don’t want to lose the simplicity of the build process that involves linking, that’s for sure.
The question is how we can enable customization of the linking and have nice defaults that are populated by the compiler and also probably by the shards.
At the end of the day having some lookups of link configuration files at the: project, shard, user, compiler level seems a good idea to me.
Using the foo at
@[Link("foo")] as a key for accessing that configuration seems simple.
Maybe when building a project by the first time a
.crystal-link.yml could be generated or expanded with the missing entries. Or a separate step can also provide that expansion directly.
The current arguments to the
LinkAnnotation could be used to populate this defaults. As long as there is no other
.crystal-link.yml at project, shard, user, compiler that states a value.
The link file could provide directly the flags to use by the linker
version: 1 libs: foo: /path/to/libfoo.a bar: libbar.a -L/usr/local/lib
Or could eventually support more features like running a bash/script to detect path/version of a specific library.
Or if no library is found it will be able to emit something in the link config file.
A more simple alternative would be to use convention over configuration. An environment variable per library like
CRYSTAL_LINK_FOO, if defined, could state the link command to use, if not keep the current behavior. Although it is simple it leaves to the user the burden of managing all those settings.