Closed Neumann-A closed 10 months ago
Yes, that's the current status quo ... it was designed to allow for having static and shared lib side by side.
This might go onto the TODO list for future improvements.
Remember: Currently I'm the a single main developer, whoch works in this in his spare time!
If you want to propose a better solution: Please just post a PR!
it was designed to allow for having static and shared lib side by side.
Maybe that design is wrong since it ignores BUILD_SHARED_LIBS. Since you are not using OBJECT libraries to build both everything is just getting compiled twice so it is not even saving time (except for "configuration time"). What was your argument to allow building both?
As I said: "Yes, that's the current status quo" ... I'm open to better solutions, but my time is currently limited.
I'm working on this right now ... please have a look at https://github.com/jkriege2/JKQtPlotter/commit/b0df7a1fd7ccea4c3e097e8d42b81d5c228aff1b ... and possible bugfix-commmits that follow!
I think my changes from yesterday should adress your suggestions. Could you have a look at the changed CMake-Build-System? Can I close this issue?
See https://jkriege2.github.io/JKQtPlotter/page_buildinstructions__c_m_a_k_e.html for a detailed description.
Its better, not ideal since you encoded the Qt version in the targets without providing also an unversioned target. Downstream users shouldn't need to care which version of Qt to use since it is a hard requirement the moment the library itself is build and installed. Furthermore there is no way to use 5 and 6 in the same project without running into other issues.
Simply said: Your CMake users will have a horrible experience with the current intended usage of jkqtplotter since they actively have to care about the fact if jkqtplotter was build as a static or shared library.
Your current usage looks like this:
instead of a simple:
So please provide a common entry point to find JKQtPlotter and also provide an lib agnostic target for downstream consumers.