separate between static and shared libs, make it configureable

[goldhoorn]

No description provided.

[goldhoorn]

Not all people want to have static libs available. Furthermore it causes problem if like from libturbojpeg only a shared lib is installed in the system. Therefore make the lib-building configurable.

[xlz]

This has been going forth and back a few times. #263 and #276 tried to build both static and shared libs at once. I thought toggling with a flag would be more elegant but it was merged anyway.

A few comments about your patch:

[goldhoorn]

The static version of tubrojpeg was not linked before too (as far i see) so i did no change in the behavior.

The env BUILD_SHARED_LIBS defines only if a add_library(lib foo.cpp) result in a shared or static library. This would be the way to go if no automatic compilation (as in this project) is done.

Therefore reusing this variable would be hacky from my point of view.

In our project i would definitely go for a shared lib because i have control of libusb and the deps. A static lib causes problems because the system-dependancies does not provide a static version of turbojpeg. Therefore i cannot build with system-dependancies turbojpeg. I want to prevent a local compilation.

[xlz]

if no automatic compilation (as in this project) is done.

What is automatic compilation? I think everything is automated, no?

Why is it hacky? It does exactly what it says, and it's standard.

In our project

Well, there is also the other users' demand #263 and #276, not mine.

[goldhoorn]

Regarding the other prs i will have a look tomorrow.

Regarding the cmake option it normally builds a shared instead of static one. In this usecase it disables/enables only the shared one Without affecting the static one.

[goldhoorn]

Automatic compilation: i mean in this project are a static and a shared one (automatically) created

[xlz]

This is a policy question with several choices. To avoid further back and forth PRs, a decision is needed among the choices.

For each build, it can:

• Build only one of shared and static versions, controlled with a standard CMake option BUILD_SHARED_LIBS - my proposal
  • Pros: no hack for OpenCV on Windows which supports only one of shared and static configurations in each build.
  • Cons: does not provide both shared and static versions at once (who is going to need both at the same time? Probably only distro packagers)
• Build both shared and static versions from scratch - proposed in build static library libfreenect2.a as well #263
  • Cons: automatically creates unneeded static version for some users (me, @goldhoorn)
  • Cons: twice the time for building two versions
• Build both shared and static versions with the same -fPIC objects - merged as create static and shared library from same source build #276
  • Cons: automatically creates unneeded static version
  • Cons: -fPIC results in slower static code [1] [2]
• Build shared (controlled by BUILD_SHARED) or build static (controlled by BUILD_STATIC) versions with the same -fPIC objects - this PR
  • Cons: -fPIC results in slower static code

@floe @hanyazou

[goldhoorn]

On 16.06.2015 23:01, Lingzhu Xiang wrote:

This is a policy question with several choices. To avoid further back
and forth PRs, a decision is needed among the choices.

For each build, it can:

• Build only one of shared and static versions, controlled with a
  standard CMake option |BUILD_SHARED_LIBS| - my proposal
  o Pros: no hack for OpenCV on Windows which supports only one of
  shared and static configurations in each build.
  o Cons: does not provide both shared and static versions at once
  (who is going to need both at the same time? Probably only
  distro packagers)

👍
This is the standart way for cmake packages. The behaviour is the
standart each package should follow.
I would be happy to provide a patch that follows this guideline but i
dont know if this fts the need of others..

[goldhoorn]

If @floe and @ hanyazou agree i provide a patch which builds ONE version of the lib. The behavior can be changed by setting then the BUILD_SHARED_LIBS option.

The complete cmake system in this project is a mess and we should try to keep it as close the the normal cmake behavior as possible.

[goldhoorn]

Should this merged or not, otherwise please close this....

[floe]

I think it's been superseded by #376? Otherwise, please re-open.