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

Support for static library build #95

Open
hs-apotell opened this issue Nov 14, 2019 · 5 comments
Open

Support for static library build #95

hs-apotell opened this issue Nov 14, 2019 · 5 comments

Comments

@hs-apotell
Copy link
Contributor

Add support for static library build - for use in native tools without bringing in python dependency.

@Nic30
Copy link
Owner

Nic30 commented Nov 14, 2019

$ mkdir build
$ cd build/
$ cmake ..
...
make -j8
...
[100%] Linking CXX shared library libhdlConvertor.so
[100%] Built target hdlConvertor_cpp_shared

On windows this should produce static library.
(Because public API is not marked for DLL export.)

Are you having troubles with this kind of build?

@hs-apotell
Copy link
Contributor Author

No that doesn't work because to build static libs HDLCONVERTOR_PYTHON has to be defined and that brings in dependency on Python. Moreover, hdlConverter/CMakeLists.txt has an explicit dependency on Cython and other python extensions that aren't wrapped in any conditional statement.

CMakeLists.txt will have to be updated to support building static libraries only.

@Nic30
Copy link
Owner

Nic30 commented Nov 14, 2019

Now I see.

@Nic30
Copy link
Owner

Nic30 commented Nov 21, 2019

@hs-apotell one small thing, doy you want a static build for windows or linux?

What I am trying to ask is if you actually need a static build so your users do not have to care about an extra lib or it is because there is no package in any public repo for C library and the more correct solution is to make a apt,conda, etc package.

@hs-apotell
Copy link
Contributor Author

We are building for Windows, Linux (multiple different flavors) and Mac, so we need for all these platforms. That said, I don't expect you to support all these platforms. If one is supported we can port for others. It's basically just a way to ensure this particular configuration is validated and tested in your release cycle.

We plan on linking it always as a static library to avoid dynamic library nightmares. Also, we use custom memory management and that's a whole lot more maintenance when dealing with dynamic modules. Also, we will always build it our self because of the number of different platforms we have to support and so release packages are not very attractive for our use case.

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

2 participants