Registered Office: 1 Eagle Place, St James’s, London SW1Y 6AF
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
Registered Office: 1 Eagle Place, St James’s, London SW1Y 6AF
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
On 4/13/21 6:05 AM Rob McDonald wrote:
> I'm late to the party, but hopefully you can help me sort out my issues.
>
> I use the SuperProject concept in CMake. That means I build FLTK as an
> External_Project_Add - when it builds FLTK, it uses the CMake stuff to
> build and then locally 'install' the result.
>
> So far, this seems to work with the updates on both Windows and MacOS.
Okay, I understand that this means you can build the FLTK library, but
then (described in the following) you can't build your application.
If this is true, there's an important question for me to understand the
issue: is this a regression vs 1.3.5, i.e. did it work in 1.3.5 or, if
you didn't use 1.3.5 previously, with which version DID it work?
> After building all the Libraries, the CMake system for my main program
> uses FIND_PACKAGE( FLTK REQUIRED ) to find FLTK and to set up the
> UseFLTK stuff. This seems to work (though may be problematic as I know
> it is not supported). Here is how I call to find FLTK and then promote
> the variables because this is done in a CMake subdirectory in my system.
Yes, our CMake support is not yet ready and fully supported, as it
stands. It's still experimental in FLTK 1.3.6 although I hope the new
version is generally better than before.
I'm not familiar with the External_Project stuff and this is not yet
been tested, hence it may or may not work. However I'd like to help and
maybe improve it if I can.
> FIND_PACKAGE(FLTK REQUIRED)
Did you consider (or even try) using the [CONFIG|NO_MODULE] mode as
described in README.CMake.txt? CONFIG and NO_MODULE are synonyms, so you
could try for instance:
FIND_PACKAGE(FLTK REQUIRED CONFIG)
Does this change anything?
...
Before I dive into all this stuff in details, please answer the
questions above and try "CONFIG" mode to see if this changes anything.
Meanwhile I'll try to test a simple project with External_Project_Add.
I created an example project and verified that it works on my Linux
system. macOS still to be tested.
My example project can be found here:
https://github.com/Albrecht-S/fltk-build
You may want to check out this repository and try the
cmake-external-project subproject:
https://raw.githubusercontent.com/Albrecht-S/fltk-build/master/cmake-external-project/CMakeLists.txt
Note that all three projects are independent of each other and
demonstrate different ways to build (very simple) FLTK applications.
> I'm not familiar with the External_Project stuff and this is not yet
> been tested, hence it may or may not work. However I'd like to help and
> maybe improve it if I can.
The problem I found with this in my very naive first attempt was that
the external project (FLTK) must be *built* before it can be *found* by
find_package() in config mode. ISTR that I read something about this
earlier.
My "solution" is to execute CMake twice and ignore the FLTK subproject
in the first pass - which builds only the FLTK library. The second pass
"if(FLTK_FOUND)..." can then build the application.
How do you deal with this?
What happens if you delete the entire build folder and build from scratch?
> I don't think this is the problem - I was mentioning it for context.
Well, it can be a problem if your CMakeLists.txt finds the "wrong"
version of FLTK (maybe previously installed elsewhere) and builds with
this wrong one. Your usage of find_package() indicates that this *may*
be the case. It happened in my tests (!) until I removed another FLTK
installation folder and added the "if(FLTK_FOUND)..." conditional block.
Please see my example on how to setup config mode in general. In my
experience you must set FLTK_DIR *correctly* so CMake can find it, but
(as said above) FLTK must be built (or at least configured so it can
create FLTKConfig.cmake) before this can succeed - hence the second pass
in my example.
I'll be online today for another three hours or so - after my dinner
break. Feel free to try my example and compare with yours. I'm open for
all suggestions how to improve this situation.
BTW: the other "cmake-fetch-content" project doesn't have this issue. It
builds FLTK during the configure process and this works in one pass. See:
https://github.com/Albrecht-S/fltk-build/tree/master/cmake-fetch-content
On 4/13/21 11:25 PM Rob McDonald wrote:
> I see that FLTK.framework is the proper naming convention. To my
> knowledge, we didn't do anything to support FLTK/.framework, it 'just
> worked'.
Hmm, I have no idea how that worked - maybe *because* you used the old
FindFLTK.cmake from the CMake installation.
okay...
> However, that is expected to fail if the machine (say a Linux box) uses
> a system-installed FLTK that happened to be built with ./configure
unfortunately, yes. :-(
You could also have a box that has 1.3.5 (or 1.3.4) installed and
another one with 1.3.6 or a self-built 1.4.x.
> So, there is _no way_ to use find_package(FLTK) that will work for both
> a Linux box that may have been built with ./configure or cmake.
(a) There have been requests to create FLTKConfig.cmake with configure
and I'm considering to do this. I don't know exactly how that will work
out, but maybe...
(b) Another question was if we couldn't provide a new FindFLTK.cmake to
the CMake folks. I'm not sure if this would be a good solution because
all changes in FLTK would have to be reflected in that CMake module. But
this would only be available in the newest CMake versions, and our goal
is to work with older CMake versions too. As old as possible.
Phew, that was hard stuff, but I can report some success!
I managed to modify the CMake module FindFLTK.cmake so you can use both
module mode (default) or config mode (either explicitly or implicitly).
(1) Modify our generated CMake files so you can use them by executing
standard find_package(FLTK) commands.
(2) Modify FindFLTK.cmake to make this work with (1).
(3) As long as this modified FindFLTK.cmake file is not yet brought
upstream and in cases when the CMake version used to build the
application is older the developer would have to do something like this:
(3a) Copy the modified FindFLTK.cmake (provided by FLTK) to their own
source distribution.
(3b) Set the CMAKE_MODULE_PATH variable to point at this file's
directory (maybe only for CMake versions less than 3.22.x ?)
(3c) Execute find_package(FLTK) as usual.
See also documentation of CMAKE_MODULE_PATH:
https://cmake.org/cmake/help/latest/variable/CMAKE_MODULE_PATH.html
If FLTK is installed in an "unusual" place you'd have to set FLTK_DIR as
before. I didn't test macOS yet but I believe this could work as well
(framework stuff).
Can you imagine to do this in your setup?
Are you doing similar things for other FindXXX.cmake modules?
Currently I see that only small mods in FindFLTK.cmake would suffice,
but there is more very, very, very questionable stuff in this CMake
module. Note that it has been updated a lot in several CMake versions. I
evaluated different recent CMake versions and I'm confident that we can
provide a suitable replacement for the CMake version at least to be used
with FLTK 1.3 and 1.4.
I'm not sure if I can keep backwards compatibility (with FLTK 1.1) which
might be necessary to bring this upstream (to CMake). If that's not
possible, the future approach would be to release this file with FLTK in
a modified version suitable to be used with the same CMake versions that
can be used to build FLTK (currently 3.2.3 and higher, but this may
change in the future).
[ Sorry, now I'm confused! ]
(b) should NOT be done in FindFLTK.cmake. The find module should only
/return/ the variable but not set /global/ (link_directories) attributes.
Surprise, surprise! Current Debian still ships both FLTK 1.1 and FLTK
1.3 in different install locations!
Note: I delayed FLTK 1.3.6 release schedule till Apr 26, but if I can
find a solution earlier I can also release earlier.
On 4/27/21 12:06 AM Rob McDonald wrote:
> Thanks for this update. I'll hold off on testing rc1 until I hear back
> from you.
No, please go ahead and test. There won't be any more changes related to
the CMake issues in 1.3.6, it's all finished now.
The only relevant changes you should expect compared to 1.3.5 are the
renamed macOS framework and the new "backwards compatible" setting of
FLTK_INCLUDE_DIR in *CONFIG* mode as you expect in your app (at least
that's what I remember).
Note: as with 1.3.5 there will likely be no next 1.3 version (1.3.7) -
unless there are really serious bugs. But you never know... ;-)
I hope that we can solve the find_package() issue differently.
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
I know your situation where you /need/ to use the "old" FindFLTK.cmake
in some cases (particularly if the installed FLTK libs were not built
with CMake) and you /may/ use the "new" CONFIG mode if the FLTK libs
were built with CMake. Unfortunately I don't have a solution for this
dilemma yet, but I hope that a future FindFLTK.cmake can resolve this issue.
(As written before, you may want to use CONFIG mode first to see if you
can find FLTK and MODULE mode if not, but that has other drawbacks.)
BTW: I think from the line above you only really need "-framework Cocoa".