How to use local lib instead of sytem for vendor packages?

For example, in <odin>/vendor/commonmark hardcoded

when ODIN_OS == .Linux {
	foreign import lib "system:cmark"
}

It would be nice to have option for swtiching between the system library and the one supplied with compiler. Is that possible?
Alternatively, can I use just local library (e.g. in same folder with source code) ?
If not, is this something planned to be supported in the future?

Thanks for your, help. How you approach this problem?

If you change "system:cmark" to "cmark.lib" or something of that sort, it will do a path search, relative to where the source file is. "system:" behaves as a specifier for an absolute path, if you provide it one. Otherwise, all paths are relative.

Thanks for your answer.

Should I do it inside odin’s vendor/commonmark? While it works, it doesn’t seem like the best idea to me.

If I put the lib file in the folder with my code and import it as you suggested, that would also work. However, using vendor:commonmark provides me with bindings.

It would be useful to retain the bindings from vendor:commonmark while also having the option to use not system library.

I found a related topics on GitHub that I hope will clarify what I mean.

To be less vague. How I can use compiled by myself commonmark library with bindings from vendor:commonmark?

I would copy the bindings to another directory, change them as I need regarding the library path, put the compiled library file in the search path. And optionally use a -collection flag to have a similar path specification in import to vendor:mylib. Here is an example of using a collection.

Thanks a lot. Probably it would be my approach as well. One more thing that I’m intresting in, why it is not a an option to have a static library in vendor? I know that on linux it is more popular to have system library for security and optimization. Is it about it or something else?

I can’t tell for sure as I’m not the author, but I guess the answer is pretty boring. Judging by the links to the discussions you have provided, yes, it is just a more popular approach. Also, Linux experience is historically less polished than Windows, so that could be a reason too.

1 Like