Skip to content
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

Nimble package with external shared library #918

Open
Clonkk opened this issue May 5, 2021 · 5 comments
Open

Nimble package with external shared library #918

Clonkk opened this issue May 5, 2021 · 5 comments

Comments

@Clonkk
Copy link

Clonkk commented May 5, 2021

Some package rely on an external shared library (https://github.com/SciNim/flambeau for example).

To make things easier, the download, extract eventually build of the library is wrapped by a Nimble task in a vendor folder (that is not in git configuration).

Where should these external library be installed in nimble to be used easily with package ?

Should a libs folder inside nimbleFolder be added (in the same way as bin ? Should we put libraries as binary inside bin ?

@dom96
Copy link
Collaborator

dom96 commented May 6, 2021

Yeah, this is a tricky one. I think we need a proper API for this stuff.

Ideally users should be able to ask Nimble to put built shared libraries somewhere where the system can find them, this usually needs sudo. For local installations we can implement putting the libraries in ~/.nimble/libs but then the user needs to be asked to add that directory to the shared library PATH.

@Clonkk
Copy link
Author

Clonkk commented May 7, 2021

That would be a start, and IMO asking the user to source an env file is acceptable (cargo does it).

But using environment variable might not even be enough to cover all use case.

Consider the following :

  • Package NimblaA v1.0.0 depends on libA.so.1.0
  • Package NimblaA v2.0.0 depends on libA.so.1.5

What happens if you install both NimblaA v1.0.0 and NimbleA v2.0.0, which library is actually the one used ?
Does it depends on the order of installation ?

What if some projects depends on NimbleA v1.0.0 and some projects depends on NimbleA v2.0.0, how do we handle that ?

Then again, maybe it's better to start small and not over complicate things

@dom96
Copy link
Collaborator

dom96 commented May 8, 2021

Yeah, I dunno. I would be tempted to consider this out of scope for Nimble. Dynamic libraries should be handled by the OS package manager.

@Clonkk
Copy link
Author

Clonkk commented May 8, 2021

Os package manager are not enough.

Lots of library don't have official release from OS package manager and needs to be downloaded and uncompressed / rebuild from source.

I think this is very much in Nimble scope since easy FFI is one of Nim's key selling point.

Saying that the official package manager do not support the distribution of shared library bindings would be disappointing since lots of stuff is built relying on shared C or C++ library

@CyberTailor
Copy link
Contributor

Use the following pragmas:

{.passCflags: staticExec("pkg-config --cflags mydep").}
{.passLflags: staticExec("pkg-config --libs mydep").}

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