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

Please add cmake options enabling/disabling static and shared libraries #100

Open
yurivict opened this issue Jan 4, 2018 · 4 comments
Open

Comments

@yurivict
Copy link

yurivict commented Jan 4, 2018

Some people only want shared, some people only want static, and some want both.

@ryeng
Copy link
Contributor

ryeng commented Jan 27, 2018

Hi Yuri,

Sorry about the late response.

My thoughts:

  • People can link with only the shared or the static library even if both are built.
  • It doesn't take long to build libpredict, so even if this may reduce the build time by 50 % to some people, it doesn't really amount to anything.
  • I'm a bit hesitant to add more complexity to the CMake script unless there's a real need for it.

As you can see, I'm afraid I don't understand the reason you want this. But there may be things I haven't thought about, so please elaborate why you want this.

Best regards,

Norvald

@yurivict
Copy link
Author

The reason is for packaging. For example, on FreeBSD static libraries aren't allowed to be installed without a good reason. So I have to patch cmake to make this happen.

FYI: Static libraries are generally not useful, and are rather harmful. They are beneficial only in these specific situations:

  • Project needs to build several large parts into one executable internally. Large parts are aggregated into a static library, which then are combined into an executable.
  • For security reasons, the static executable is preferred. All dependencies have to be static for this to happen. Example: Tor has an option to link statically.

Downsides:

  • When projects build static libs and they are used, this generally only leads to code duplication. The same code is being copied over and over into different executables through static libs.
  • Presence of both static and shared libs causes obvious waste of disk space, because they contain the same code.

This is why it is better to limit static libs. FreeBSD does this as a policy. This is the reason I asked.

Thanks!

@ryeng
Copy link
Contributor

ryeng commented Jan 27, 2018

I've only packaged software for Linux distros, never for FreeBSD. All Linux distro package formats I've worked with have a way of specifying which files to package and which to not. Doesn't FreeBSD packaging have a similar option? IMHO, that would be a better place to make this choice.

@yurivict
Copy link
Author

yurivict commented Jan 27, 2018

Doesn't FreeBSD packaging have a similar option?

For cmake projects, it installs what cmake installs. It is possible to add/delete files in a package. But it makes the port code unnecessarily more complex.
Arch linux does it much the same way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants