| |
| |
On 4/29/21 7:17 PM Rob McDonald wrote:
What this means is: IF you are using the NO_MODULE (or CONFIG)
approach,
THEN you don't need to take care of all "FLTK_LIBRARIES" because they
will be included by the named target, which are (unfortunately) named
only in a sentence at the end of the instructions. These targets are:
fltk, fltk_gl, fltk_images, fltk_forms, and fluid
...
This may have been obvious to everyone else, but it just hit me like a
ton of bricks...
With CONFIG mode -- there are more changes that I am expected to make
throughout my CMake stuff....
I was under the impression that changing to CONFIG mode changed the way
FLTK was discovered and any settings used while building FLTK were
discovered -- but that all the variables were set the same and the
library would be used in exactly the same way by the application.
Rob, what you describe is how it *should* work, that's correct. And I
agree with you that this should be achieved.
But what I described is how it *actually* works because the CMake config
files created by FLTK just do it this way at this time. This is how the
CMake support files have been created (rewritten) when FLTK 1.3 was
developed. I didn't know much about CMake at that time, someone else
wrote these CMake files and this is what we have now. It's great as it
is, but I also see deficiencies.
Meanwhile I took over the (FLTK CMake) maintenance and I'm learning more
and more what to do and how to do it. I know that the current CMake
support of FLTK is somewhere in the middle between "old" and "modern" CMake.
To get that right I need more time. Since we always said that CMake
support in 1.3 is not yet production ready, that's all we can provide
now and what you can get. In FLTK 1.4 I'm striving to make the CMake
support complete and easy to use, but this is still much work.
My goal is to have the users (consumers) choose which kind of
find_package() /output/ they use, either the old style with variables or
the new style with targets. The new config mode *should* also be
backwards compatible so projects like yours that use the "old cmake"
approach with variables can work as they did and that users expecting
"new style" (aka modern CMake) targets can work as well. And the old
FindFLTK.cmake should be modernized so it can be used by "old" projects
and also compatible with "new" projects.
This means working at two ends:
(a) update FLTKConfig.cmake to provide targets *and* old style variables
(the latter is just not (yet) implemented)
(b) update CMake's FindFLTK.cmake (or provide one for consumers) that
sets the variables as expected (old style) but also provides usable
targets (new style). The "new" convention would be "namespaced" target
names like fltk::fltk and fltk::fltk_gl, but that's something I need to
investigate further.
I hope this clarifies why your expectations can't be met *today* by the
current status of FLTK's CMake support. I don't say that your
expectations are wrong - it's just that all this is not yet production
ready. But I hope this all will be as expected in the future.
That all said, I appreciate the discussions and your input very much
because I learned a lot about user (consumer) expectations and why our
current approach does not work as expected and needs to be improved.
Thank you very much!
I'll continue working on this...
One final recommendation: for the time being, leave your approach as-is.
The CONFIG mode is not yet ready for you. Our README.CMake.txt is usable
and works well for developers that build FLTK themselves and can adjust
their projects accordingly but not yet ready for your usage that
requirements to find FLTK even on a system with FLTK installed by the
distro.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/c632f807-9115-6b1f-9b09-d84fcb272238%40online.de.
[ Direct Link to Message ] | |
|
| |
