RE: [fltk.coredev] Release FLTK 1.3.6 -- [General Use]

[MacArthur, Ian (Leonardo, UK)]

> I invite and ask everybody (devs and others reading here) to test builds
> on their available platforms. I'm particularly interested in *build*
> feedback, mostly in CMake builds but also configure/make and bundled
> IDE's (VS and Xcode). I'd like to fix regressions (if any) before I
> publish an official 1.3.6 release candidate, hopefully on April 15.

Tested 3 Windows build variants (all with mingw* tools) as follows:

1) Autoconf, Msys, mingw32
2) cmake, Msys, mingw32
3) cmake, Msys, mingw64

All three built correctly and test and examples seem to be working.
I do not have VS on this machine, so can not readily test that here.


Observations:

Build-1, Autoconf:
==================
This built OK, and the code executes fine, the libraries appear to be fine, but "fltk-config" (which I use a lot in my Makefiles) seems to be broken in a way I've not seen before.
Specifically, the GL libs do not seem to be getting expanded in the fltk-config output, so I get:

$ ./fltk-config --use-gl --ldstaticflags
-mwindows -static-libgcc -static-libstdc++ ./lib/libfltk_gl.a @GLLIB@ ./lib/libfltk.a -lole32 -luuid -lcomctl32


Where the @GLLIB@ then causes my builds to choke.
The generated makeinclude does not seem to have this "feature" which is presumably why the libs and tests build OK.
FWIW, I think we'd expect that to expand as "-lglu32 -lopengl32", which is what makeinclude has. I *think* this symbol used to be named GLDLIBS perhaps, not GLLIB? Do not know.


Also, setting "--with-abiversion" on the ./configure line did not seem to do anything; the "abi-version.h" file was not set, and the build was "plain".

Hand-editing "abi-version.h" and building worked OK and the libs then had the extended functionality as expected.


Build-2 and 3 (cmake builds)
============================
These both seemed to work OK, but there are a number of "features" here too.
Firstly, the GL libs seem to be "differently broken" in the fltk-config files, viz:

(32-bit) ./fltk-config --use-gl --ldstaticflags
-Wl,-subsystem,windows -mwindows D:/Support/fltk-1.3.x/build-32/lib/libfltk_gl.a D:/Support/fltk-1.3.x/build-32/lib/libfltk.a -lole32 -luuid -lcomctl32 -lws2_32

(64-bit) ./fltk-config --use-gl --ldstaticflags
-Wl,-subsystem,windows -mwindows D:/Support/fltk-1.3.x/build-64/lib/libfltk_gl.a D:/Support/fltk-1.3.x/build-64/lib/libfltk.a -lole32 -luuid -lcomctl32 -lws2_32

Here, there is no spurious "@GLLIB@" string, but again the "correct" libs do not seem to be listed, "-lglu32 -lopengl32".

This was testing with the fltk-config generated by cmake in the "build" folder, not the one generated in the "bin" folder, which I believe is only suitable for use in an installed build (and does not work for me, as I do not install the libs...)


Also the "abi-version.h" file is set *correctly* by cmake.

However (as I think we have seen with the fltk-1.4 build) the cmake build doesn’t seem to be paying attention to the optimizer options or the build settings, with the result that the generated libs appear to be "un-optimized" and the fltk-config script returns empty for the optim option:

(32-bit) ./fltk-config --optim


For comparison the autoconf-generated fltk-config returns a more believable:

$ ./fltk-config --optim
-O3 -Wall -Wunused -Wno-format-y2k -fno-exceptions -fno-strict-aliasing -ffunction-sections -fdata-sections


> If possible, building shared libs and linking existing projects with the
> shared libs would be very helpful.

Hmm, tricky. I don't actually have any shared-lib builds (or projects) at all...

Leonardo UK Ltd

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.

********************************************************************

[MacArthur, Ian (Leonardo, UK)]

> Build-1, Autoconf:
> ==================
> This built OK, and the code executes fine, the libraries appear to be
> fine, but "fltk-config" (which I use a lot in my Makefiles) seems to be
> broken in a way I've not seen before.
> Specifically, the GL libs do not seem to be getting expanded in the fltk-
> config output, so I get:
>
> $ ./fltk-config --use-gl --ldstaticflags
> -mwindows -static-libgcc -static-libstdc++ ./lib/libfltk_gl.a @GLLIB@
> ./lib/libfltk.a -lole32 -luuid -lcomctl32

This seems to be a typo. in fltk-config.in, it *looks* like we have:

if test x$use_gl = xyes; then
LDLIBS="-lfltk_gl$SHAREDSUFFIX @GLLIB@ $LDLIBS"
LDSTATIC="$libdir/libfltk_gl.a @GLLIB@ $LDSTATIC"
fi

But by comparing to other builds it looks like the symbol might be @GLLIBS@ (note extra 'S' at end of name there...) But not sure.
Also, whilst in fltk-config.in, the copyright date, the COPYING and bug report messages probably need to be brought into line:

# http://www.fltk.org/COPYING.php
#
# Please report all bugs and problems on the following page:
#
# http://www.fltk.org/str.php
#


In other news, the autoconf generated makeinclude seems to be slightly off too, though doing no harm AFAICT, viz:

# FLTK version numbers

FL_VERSION = @FLTK_VERSION@
FL_DSO_VERSION = 1.3
FL_ABI_VERSION = 1.3.0

The FL_VERSION string is not being expanded. Do not know why, but it possibly may not matter and may have been awry before.
FWIW 1.4 builds do set this as expected. But I do not think it is used much...?

[Albrecht Schlosser]

On 4/9/21 1:07 PM 'MacArthur, Ian (Leonardo, UK)' via fltk.coredev wrote:
>> Build-1, Autoconf:
>> ==================
>> This built OK, and the code executes fine, the libraries appear to be
>> fine, but "fltk-config" (which I use a lot in my Makefiles) seems to be
>> broken in a way I've not seen before.
>> Specifically, the GL libs do not seem to be getting expanded in the fltk-
>> config output, so I get:
>>
>> $ ./fltk-config --use-gl --ldstaticflags
>> -mwindows -static-libgcc -static-libstdc++ ./lib/libfltk_gl.a @GLLIB@
>> ./lib/libfltk.a -lole32 -luuid -lcomctl32
>
> This seems to be a typo. in fltk-config.in, it *looks* like we have:
>
> if test x$use_gl = xyes; then
> LDLIBS="-lfltk_gl$SHAREDSUFFIX @GLLIB@ $LDLIBS"
> LDSTATIC="$libdir/libfltk_gl.a @GLLIB@ $LDSTATIC"
> fi
>
> But by comparing to other builds it looks like the symbol might be @GLLIBS@ (note extra 'S' at end of name there...) But not sure.
> Also, whilst in fltk-config.in, the copyright date, the COPYING and bug report messages probably need to be brought into line:
>
> # http://www.fltk.org/COPYING.php
> #
> # Please report all bugs and problems on the following page:
> #
> # http://www.fltk.org/str.php
> #

Yep, thanks for finding this.

This issue is fixed in commit 1c587997c23c.

> In other news, the autoconf generated makeinclude seems to be slightly off too, though doing no harm AFAICT, viz:
>
> # FLTK version numbers
>
> FL_VERSION = @FLTK_VERSION@
> FL_DSO_VERSION = 1.3
> FL_ABI_VERSION = 1.3.0
>
> The FL_VERSION string is not being expanded. Do not know why, but it possibly may not matter and may have been awry before.
> FWIW 1.4 builds do set this as expected. But I do not think it is used much...?

FL_VERSION vs. FLTK_VERSION: there's been a rename for consistency,
maybe I missed something.

I'm going to look into the other issues you reported right now...

[Albrecht Schlosser]

Did you use a fresh working copy or did you "upgrade"?

If the latter could you please execute:

$ make distclean
$ autoconf -f
$ make

This is (or may be) necessary to regenerate 'configure' because I
changed configure.ac. I should have noted this explicitly in my previous
post (asking for tests).

I'll check this anyway, but maybe not regenerating configure caused this
issue. (?)

[Albrecht Schlosser]

On 4/9/21 1:27 PM schrieb Albrecht Schlosser:

Sorry for the noise: I can confirm this issue; looking into it...

[MacArthur, Ian (Leonardo, UK)]

> This seems to be a typo. in fltk-config.in, it *looks* like we have:
>
> if test x$use_gl = xyes; then
> LDLIBS="-lfltk_gl$SHAREDSUFFIX @GLLIB@ $LDLIBS"
> LDSTATIC="$libdir/libfltk_gl.a @GLLIB@ $LDSTATIC"
> fi
>
> But by comparing to other builds it looks like the symbol might be
> @GLLIBS@ (note extra 'S' at end of name there...) But not sure.

Looks like this one might be a loose end from commit e934dd5468655ba8c64240c04d0f434dfbc40d34

> In other news, the autoconf generated makeinclude seems to be slightly off
> too, though doing no harm AFAICT, viz:
>
> # FLTK version numbers
>
> FL_VERSION = @FLTK_VERSION@
> FL_DSO_VERSION = 1.3
> FL_ABI_VERSION = 1.3.0

And this one also, FWIW...

[Albrecht Schlosser]

On 4/9/21 1:33 PM 'MacArthur, Ian (Leonardo, UK)' via fltk.coredev wrote:
>> This seems to be a typo. in fltk-config.in, it *looks* like we have:
>>
>> if test x$use_gl = xyes; then
>> LDLIBS="-lfltk_gl$SHAREDSUFFIX @GLLIB@ $LDLIBS"
>> LDSTATIC="$libdir/libfltk_gl.a @GLLIB@ $LDSTATIC"
>> fi
>>
>> But by comparing to other builds it looks like the symbol might be
>> @GLLIBS@ (note extra 'S' at end of name there...) But not sure.
>
> Looks like this one might be a loose end from commit e934dd5468655ba8c64240c04d0f434dfbc40d34
>
>> In other news, the autoconf generated makeinclude seems to be slightly off
>> too, though doing no harm AFAICT, viz:
>>
>> # FLTK version numbers
>>
>> FL_VERSION = @FLTK_VERSION@
>> FL_DSO_VERSION = 1.3
>> FL_ABI_VERSION = 1.3.0
>
> And this one also, FWIW...

Thanks for your help, but I don't think this old commit is related.

I renamed some configure (FL_*_VERSION) variables to be consistent with
CMake for better maintenance but I missed to adjust some files
accordingly. The result was a mix of FL_*_VERSION (old) and
FLTK_VERSION_* (new) variables. Note that this is only in
configure/CMake/build related files. In source file (and in makeinclude
and some Makefiles) there's still FL_VERSION, FL_API_VERSION, and
FL_DSO_VERSION. This is a little confusing ...

I'm confident that this commit fixed it:

commit 359f8b5d4aee70cdd4a2c82c9b94804eac5ea454
Author: Albrecht Schlosser <albrech...@online.de>
Date: Fri Apr 9 14:08:03 2021 +0200

Fix FLTK_VERSION_XXX strings in configure et al

Variables FL_XXX_VERSION (XXX = { MAJOR | MINOR | PATCH } ) have been
renamed to FLTK_VERSION_XXX for compatibility with CMake.

Note: FL_DSO_VERSION and FL_ABI_VERSION are not affected.


Note that you should start with a fresh build and run at least `autoconf
-f` before executing `configure` to thest these changes.

[Albrecht Schlosser]

On 4/9/21 12:49 PM 'MacArthur, Ian ... wrote:

> Tested 3 Windows build variants (all with mingw* tools) as follows:
>
> 1) Autoconf, Msys, mingw32
> 2) cmake, Msys, mingw32
> 3) cmake, Msys, mingw64
>
> All three built correctly and test and examples seem to be working.
> I do not have VS on this machine, so can not readily test that here.

Thank you very much for your tests and reports.

> Observations:
>
> Build-1, Autoconf:
> ==================

> $ ./fltk-config --use-gl --ldstaticflags
> -mwindows -static-libgcc -static-libstdc++ ./lib/libfltk_gl.a @GLLIB@ ./lib/libfltk.a -lole32 -luuid -lcomctl32

I replied on this issue separately and this is fixed now.

> Also, setting "--with-abiversion" on the ./configure line did not seem to do anything; the "abi-version.h" file was not set, and the build was "plain".

Hmm, I can't confirm/reproduce this one with mingw-w64 (MSYS2) which
should be very similar to your mingw build. Works fine for me and sets
the abi-version in FL/abi-version.h as expected. Even
"--without-abiversion" works and resets the abi version.

$ pwd
/c/Users/albrecht/git/fltk/branch-1.3
$ test/fltk-versions.exe
FL_VERSION = 1.0306
Fl::version() = 1.0306
FL_API_VERSION = 10306
Fl::api_version() = 10306
FL_ABI_VERSION = 10306
Fl::abi_version() = 10306
FLTK_ABI_VERSION = 10306


Can you please double-check?

> Build-2 and 3 (cmake builds)
> ============================
> These both seemed to work OK, but there are a number of "features" here too.
> Firstly, the GL libs seem to be "differently broken" in the fltk-config files, viz:
>
> (32-bit) ./fltk-config --use-gl --ldstaticflags
> -Wl,-subsystem,windows -mwindows D:/Support/fltk-1.3.x/build-32/lib/libfltk_gl.a D:/Support/fltk-1.3.x/build-32/lib/libfltk.a -lole32 -luuid -lcomctl32 -lws2_32
>
> (64-bit) ./fltk-config --use-gl --ldstaticflags
> -Wl,-subsystem,windows -mwindows D:/Support/fltk-1.3.x/build-64/lib/libfltk_gl.a D:/Support/fltk-1.3.x/build-64/lib/libfltk.a -lole32 -luuid -lcomctl32 -lws2_32
>
> Here, there is no spurious "@GLLIB@" string, but again the "correct" libs do not seem to be listed, "-lglu32 -lopengl32".
>
> This was testing with the fltk-config generated by cmake in the "build" folder, not the one generated in the "bin" folder, which I believe is only suitable for use in an installed build (and does not work for me, as I do not install the libs...)

Again, this works fine for me.

$ ./fltk-config --use-gl --ldstaticflags
-static-libgcc -static-libstdc++ -Wl,-subsystem,windows -mwindows
C:/Users/albrecht/git/fltk/branch-1.3/build/debug/lib/libfltk_gl.a
-lglu32 -lopengl32
C:/Users/albrecht/git/fltk/branch-1.3/build/debug/lib/libfltk.a -lole32
-luuid -lcomctl32 -lws2_32


Except checking that the GL libs are listed I also built glpuzzle.exe
with fltk-config --compile in the CMake build folder:

$ pwd
/c/Users/albrecht/git/fltk/branch-1.3/build/debug
$ ./fltk-config --use-gl --compile ../../test/glpuzzle.cxx
C:/msys64/mingw64/bin/g++.exe
-IC:/Users/albrecht/git/fltk/branch-1.3/build/debug
-IC:/Users/albrecht/git/fltk/branch-1.3 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o 'glpuzzle'
'../../test/glpuzzle.cxx' -static-libgcc -static-libstdc++
-Wl,-subsystem,windows -mwindows
C:/Users/albrecht/git/fltk/branch-1.3/build/debug/lib/libfltk_gl.a
-lglu32 -lopengl32
C:/Users/albrecht/git/fltk/branch-1.3/build/debug/lib/libfltk.a -lole32
-luuid -lcomctl32 -lws2_32
$
$ ./glpuzzle.exe

r Reset puzzle
s Solve puzzle ...

Works even if started from file explorer (i.e. with standard Windows path).

> However (as I think we have seen with the fltk-1.4 build) the cmake build doesn’t seem to be paying attention to the optimizer options or the build settings, with the result that the generated libs appear to be "un-optimized" and the fltk-config script returns empty for the optim option:
>
> (32-bit) ./fltk-config --optim

Yep, that's a known issue. I'll check if I can improve this before the
release (in both 1.3.6 and 1.4).

>> If possible, building shared libs and linking existing projects with the
>> shared libs would be very helpful.
>
> Hmm, tricky. I don't actually have any shared-lib builds (or projects) at all...

Thanks for considering it.

I tried a demo project (copied test/pixmap_browser.cxx) and linked it
against the shared libs created with CMake and VS2019 which was known to
*not* work in 1.3.5 - one of the reasons I wanted to release 1.3.6. This
worked well for me and I could open and display all sorts of images.

FYI: the bundled IDE projects in 1.3.x create only one complete shared
lib (dll). CMake in 1.3.5 built all separate dll's which failed (due to
not exported symbols). This is now fixed in 1.4 and backported to 1.3.6.

[Ian MacArthur]

On 9 Apr 2021, at 13:18, Albrecht Schlosser wrote:
>
> I'm confident that this commit fixed it:
>
> commit 359f8b5d4aee70cdd4a2c82c9b94804eac5ea454
> Author: Albrecht Schlosser <albrech...@online.de>
> Date: Fri Apr 9 14:08:03 2021 +0200
>
> Fix FLTK_VERSION_XXX strings in configure et al
>
> Variables FL_XXX_VERSION (XXX = { MAJOR | MINOR | PATCH } ) have been
> renamed to FLTK_VERSION_XXX for compatibility with CMake.
>
> Note: FL_DSO_VERSION and FL_ABI_VERSION are not affected.

Yes - this seems to be better, for the record.

[Ian MacArthur]

On 9 Apr 2021, at 18:01, Albrecht Schlosser wrote:
>
>> Also, setting "--with-abiversion" on the ./configure line did not seem to do anything; the "abi-version.h" file was not set, and the build was "plain".
>
> Hmm, I can't confirm/reproduce this one with mingw-w64 (MSYS2) which should be very similar to your mingw build. Works fine for me and sets the abi-version in FL/abi-version.h as expected. Even "--without-abiversion" works and resets the abi version.

This failure is reproducible for me, consistently.

But... the version of the auto tools I’m using is pretty ancient (indeed a lot of my mingw setup is pretty ancient, as it is tied into a specific build configuration that I cannot really change...)

So it is entirely possible this failure only occurs in my configuration.

>>
>> Build-2 and 3 (cmake builds)
>> ============================
>> These both seemed to work OK, but there are a number of "features" here too.
>> Firstly, the GL libs seem to be "differently broken" in the fltk-config files, viz:
>> (32-bit) ./fltk-config --use-gl --ldstaticflags
>> -Wl,-subsystem,windows -mwindows D:/Support/fltk-1.3.x/build-32/lib/libfltk_gl.a D:/Support/fltk-1.3.x/build-32/lib/libfltk.a -lole32 -luuid -lcomctl32 -lws2_32
>> (64-bit) ./fltk-config --use-gl --ldstaticflags
>> -Wl,-subsystem,windows -mwindows D:/Support/fltk-1.3.x/build-64/lib/libfltk_gl.a D:/Support/fltk-1.3.x/build-64/lib/libfltk.a -lole32 -luuid -lcomctl32 -lws2_32
>> Here, there is no spurious "@GLLIB@" string, but again the "correct" libs do not seem to be listed, "-lglu32 -lopengl32".
>> This was testing with the fltk-config generated by cmake in the "build" folder, not the one generated in the "bin" folder, which I believe is only suitable for use in an installed build (and does not work for me, as I do not install the libs...)
>
> Again, this works fine for me.
>
> $ ./fltk-config --use-gl --ldstaticflags
> -static-libgcc -static-libstdc++ -Wl,-subsystem,windows -mwindows C:/Users/albrecht/git/fltk/branch-1.3/build/debug/lib/libfltk_gl.a -lglu32 -lopengl32 C:/Users/albrecht/git/fltk/branch-1.3/build/debug/lib/libfltk.a -lole32 -luuid -lcomctl32 -lws2_32
>

Hmm - that’s the fltk-config from the cmake “build" folder? Or the one from the "build/bin" folder?

For me, the latter doesn’t really work, and the former does not report the GL libs - though clearly yours does. The cmake I have is *recent*, but it is conceivable there’s still something in my (otherwise old) toolchain configuration that is upsetting the cmake...

[Ian MacArthur]

FWIW, I also tested on Linux/X11, with both autoconf and cmake. This was using a clean checkout from after the recent commit, and the fltk-config et al seemed broadly fine.
Also, --with-abiversion works just fine (of course.)

So all good in that regard.

Since this was my Linux box, I also set --enable-cairo and --enable-cairoext for these builds (and the equivalent in cmake) and that seemed to work OK (I do not have the Cairo libs on my Windows test machine.)

Both builds seemed to work just fine, but (when testing the fltk-config) I noticed two things that seemed odd.
Firstly, the list of libraries reported by the cmake generated fltk-config for “fltk-config --with-cairo --ldstaticflags” didn’t seem complete; it did not include pixman, whereas the autoconf version did.
TBH, I have no idea if cairo does need pixman, but I’ve always used it because I copied a config from somewhere once and...

Secondly, the libs (from the cmake generated fltk-config) looked like they might be in the “wrong order”, with X11 listed before things that depend on it... Maybe it’s OK, but it just seemed odd, and different from the autoconf fltk-config.

But - I don't actually know for sure about this, and didn’t have time to try using the cmake version to perform any project builds, so it may well be completely fine!

[Albrecht Schlosser]

On 4/9/21 9:55 PM Ian MacArthur wrote:
> On 9 Apr 2021, at 18:01, Albrecht Schlosser wrote:
>>
>>> Also, setting "--with-abiversion" on the ./configure line did not seem to do anything; the "abi-version.h" file was not set, and the build was "plain".
>>
>> Hmm, I can't confirm/reproduce this one with mingw-w64 (MSYS2) which should be very similar to your mingw build. Works fine for me and sets the abi-version in FL/abi-version.h as expected. Even "--without-abiversion" works and resets the abi version.
>
> This failure is reproducible for me, consistently.
>
> But... the version of the auto tools I’m using is pretty ancient (indeed a lot of my mingw setup is pretty ancient, as it is tied into a specific build configuration that I cannot really change...)
>
> So it is entirely possible this failure only occurs in my configuration.

Until now I only tested with a Windows Virtualbox VM on my Linux
notebook with a pretty current MSYS2/MinGW-w64 setup. All the Windows
CMake builds were with -G"MinGW Makefiles", BTW.

I can try to start my older Win10 box which has a pretty old "standard
MinGW" build setup which I used earlier (and an ancient CygWin as well).
I'll report whether I can find any differences, likely tomorrow. This
has an older autoconf setup, maybe similar to yours, and I can try the
`configure --with-abiversion` build.

>>> Build-2 and 3 (cmake builds)
>>> ============================
>>> These both seemed to work OK, but there are a number of "features" here too.
>>> Firstly, the GL libs seem to be "differently broken" in the fltk-config files, viz:
>>> (32-bit) ./fltk-config --use-gl --ldstaticflags
>>> -Wl,-subsystem,windows -mwindows D:/Support/fltk-1.3.x/build-32/lib/libfltk_gl.a D:/Support/fltk-1.3.x/build-32/lib/libfltk.a -lole32 -luuid -lcomctl32 -lws2_32
>>> (64-bit) ./fltk-config --use-gl --ldstaticflags
>>> -Wl,-subsystem,windows -mwindows D:/Support/fltk-1.3.x/build-64/lib/libfltk_gl.a D:/Support/fltk-1.3.x/build-64/lib/libfltk.a -lole32 -luuid -lcomctl32 -lws2_32
>>> Here, there is no spurious "@GLLIB@" string, but again the "correct" libs do not seem to be listed, "-lglu32 -lopengl32".
>>> This was testing with the fltk-config generated by cmake in the "build" folder, not the one generated in the "bin" folder, which I believe is only suitable for use in an installed build (and does not work for me, as I do not install the libs...)
>>
>> Again, this works fine for me.
>>
>> $ ./fltk-config --use-gl --ldstaticflags
>> -static-libgcc -static-libstdc++ -Wl,-subsystem,windows -mwindows C:/Users/albrecht/git/fltk/branch-1.3/build/debug/lib/libfltk_gl.a -lglu32 -lopengl32 C:/Users/albrecht/git/fltk/branch-1.3/build/debug/lib/libfltk.a -lole32 -luuid -lcomctl32 -lws2_32
>
> Hmm - that’s the fltk-config from the cmake “build" folder? Or the one from the "build/bin" folder?

The one from the "build" folder (which is "build/debug" for this build).

> For me, the latter doesn’t really work, and the former does not report the GL libs - though clearly yours does. The cmake I have is *recent*, but it is conceivable there’s still something in my (otherwise old) toolchain configuration that is upsetting the cmake...

The one from the build/bin folder (here: build/debug/bin) is the one
that's to be installed together with bin/fluid. It can - and should -
only work after installation because it uses the "install path" as
opposed to the build folder path in the former.

Side note: I just looked into it and the default CMake setup has install
prefix "C:/Program files (x86)" or something like that. This would need
to be quoted (multiple times, recursively) which is not going to work -
I tried it but it's broken anyway. After I changed CMAKE_INSTALL_PREFIX
to "C:/FLTK" (w/o spaces and brackets) it looks fine - but I didn't
install (yet) and try that.

Here's a diff after changing CMAKE_INSTALL_PREFIX to 'C:/FLTK':

$ pwd
/c/Users/albrecht/git/fltk/branch-1.3/build/debug

$ diff -rubw fltk-config bin/fltk-config
--- fltk-config 2021-04-09 18:22:33.974831300 +0200
+++ bin/fltk-config 2021-04-09 23:06:22.291124400 +0200
@@ -26,15 +26,15 @@
### BEGIN fltk-config
selfdir=`dirname "$0"`

-prefix=C:/Users/albrecht/git/fltk/branch-1.3/build/debug
+prefix=C:/FLTK
exec_prefix=${prefix}
exec_prefix_set=no
-includedir=C:/Users/albrecht/git/fltk/branch-1.3
+includedir=${prefix}/include
libdir=${exec_prefix}/lib
srcdir=.

# BINARY_DIR - used only for CMake builds in local (binary) directory
-BINARY_DIR=C:/Users/albrecht/git/fltk/branch-1.3/build/debug
+BINARY_DIR=

# compiler names
CC="C:/msys64/mingw64/bin/gcc.exe"


As you can see only the prefix-related stuff is different. The
'BINARY_DIR' variable is only needed fltk-config in the build dir (for
the additional -I switch for abi-version.h) and is empty in the
installed version because that's not needed.

Here for comparison:

(a) "build" folder:

$ ./fltk-config --use-gl --ldstaticflags
-static-libgcc -static-libstdc++ -Wl,-subsystem,windows -mwindows
C:/Users/albrecht/git/fltk/branch-1.3/build/debug/lib/libfltk_gl.a
-lglu32 -lopengl32
C:/Users/albrecht/git/fltk/branch-1.3/build/debug/lib/libfltk.a -lole32
-luuid -lcomctl32 -lws2_32

(b) "build/bin" folder (install prefix = 'C:/FLTK'):

$ bin/fltk-config --use-gl --ldstaticflags
-static-libgcc -static-libstdc++ -Wl,-subsystem,windows -mwindows
C:/FLTK/lib/libfltk_gl.a -lglu32 -lopengl32 C:/FLTK/lib/libfltk.a
-lole32 -luuid -lcomctl32 -lws2_32

This looks fine for me.

More about this tomorrow...

[Albrecht Schlosser]

On 4/9/21 10:09 PM Ian MacArthur wrote:
> FWIW, I also tested on Linux/X11, with both autoconf and cmake. This was using a clean checkout from after the recent commit, and the fltk-config et al seemed broadly fine.
> Also, --with-abiversion works just fine (of course.)
>
> So all good in that regard.

Thanks for the report. Same here.

> Since this was my Linux box, I also set --enable-cairo and --enable-cairoext for these builds (and the equivalent in cmake) and that seemed to work OK (I do not have the Cairo libs on my Windows test machine.)

Same here (although I tried that some time ago on another box).

> Both builds seemed to work just fine, but (when testing the fltk-config) I noticed two things that seemed odd.

> Firstly, the list of libraries reported by the cmake generated fltk-config for “fltk-config --with-cairo --ldstaticflags” didn’t seem complete; it did not include pixman, whereas the autoconf version did.
> TBH, I have no idea if cairo does need pixman, but I’ve always used it because I copied a config from somewhere once and...

I'm not sure, but usually CMake does a good job. If libcairo is the
shared lib (although you used --ldstaticflags) it may work anyway. But
it's also possible that this is wrong.

But ISTR that this can also differ by system. IIRC Greg wrote some
advice to remove -lpixman from the build commands if this produces an
error. Which means, on systems where -lpixman is not used (and hence
doesn't exist) you must not use it.

> Secondly, the libs (from the cmake generated fltk-config) looked like they might be in the “wrong order”, with X11 listed before things that depend on it... Maybe it’s OK, but it just seemed odd, and different from the autoconf fltk-config.

Yeah, link library order. I think it will work on some systems (if
reversed) but maybe on other systems it won't work. It's more likely to
work if you link against shared libs because the will include all
symbols from the libs anyway - and X11 stuff are certainly .so files
almost always.

That said, a faint recollection tells me there might be a FIXME comment
somewhere that says that library order should be checked and/or fixed...

> But - I don't actually know for sure about this, and didn’t have time to try using the cmake version to perform any project builds, so it may well be completely fine!

I think it's at least the same (now) in 1.3.6 and 1.4 current, so I
think it works - probably.

Again, I'll look into it tomorrow...

[Albrecht Schlosser]

Regarding "./configure --with-abiversion=10306"

On 4/9/21 11:37 PM Albrecht Schlosser wrote:
> On 4/9/21 9:55 PM Ian MacArthur wrote:
>> On 9 Apr 2021, at 18:01, Albrecht Schlosser wrote:
>>>
>>>> Also, setting "--with-abiversion" on the ./configure line did not
>>>> seem to do anything; the "abi-version.h" file was not set, and the
>>>> build was "plain".
>>>
>>> Hmm, I can't confirm/reproduce this one with mingw-w64 (MSYS2) which
>>> should be very similar to your mingw build. Works fine for me and
>>> sets the abi-version in FL/abi-version.h as expected. Even
>>> "--without-abiversion" works and resets the abi version.
>>
>> This failure is reproducible for me, consistently.
>>
>> But... the version of the auto tools I’m using is pretty ancient
>> (indeed a lot of my mingw setup is pretty ancient, as it is tied into
>> a specific build configuration that I cannot really change...)
>>
>> So it is entirely possible this failure only occurs in my configuration.
>
> Until now I only tested with a Windows Virtualbox VM on my Linux
> notebook with a pretty current MSYS2/MinGW-w64 setup. All the Windows
> CMake builds were with -G"MinGW Makefiles", BTW.
>
> I can try to start my older Win10 box which has a pretty old "standard
> MinGW" build setup which I used earlier (and an ancient CygWin as well).
> I'll report whether I can find any differences, likely tomorrow. This
> has an older autoconf setup, maybe similar to yours, and I can try the
> `configure --with-abiversion` build.

Done. I started my older Win10 system and tried:

$ ./configure --with-abiversion=10306
...

Result: works fine.

Ian, are you sure you didn't misspell the option somehow?

See attached file for a configure and test log (w/o the actual build
process). I left the full configure log so you can compare.

I have no idea where to look further. Maybe something's really broken on
your build system.

[Manolo]

Here are build tests of FLTK 1.3.6 I did on macOS 11.2.3 (Intel proc) :

1) default build with configure/make : OK (after small change in Fl_cocoa.mm, committed)

2) configure —enable-x11 : OK (after change in configure.ac, committed)

3) CMake + make w/ default options : OK

4) CMake + make with OPTION_APPLE_X11 : OK

[Manolo]

Other build tests for FLTK 1.3.6 under Windows 10 (as a Virtualbox guest) :

1) CMake + build w/ Visual Studio 16 2019 release mode : OK

2) configure + make (g++ 8.1.0 64-bit) w/ default options : OK

[Albrecht Schlosser]

Thanks for these and the Windows tests and the committed fixes.

Anybody else with test results?

Release schedule:

"Soft" deadline for tests is tomorrow evening (Tue 13 Apr, midnight, no
matter what your timezone is).

My plans are to prepare the public release on Wed 14 April and to
release 1.3.6rc1 on Thu 15 April.


Last minute test (and bug?) reports welcome as well ...

[Manolo]

Other build tests for FLTK 1.3.6 under Windows XP (as VirtualBox guest):

1) configure + make (g++ 4.9.3 32-bit) w/ default options : OK

2) CMake + build w/ make default options : OK

[MacArthur, Ian (Leonardo, UK)]

> Ian, are you sure you didn't misspell the option somehow?

No, not really sure!

However, thinking back, setting the abi-version via configure has always been a bit flaky for my build.

That said, I removed everything and checked out the tip of the 1.3 branch: commit d40093dd3bfec83387e507b43d0dbf3ba18cbe21

Then I ran:

auotconf

followed by:

LDFLAGS="-static-libgcc -static-libstdc++" ./configure --with-abiversion=10306 --enable-localjpeg --enable-localpng --enable-localzlib

And let that run its course. At the end I had a valid abi-version.h file after all:

/* FL/abi-version.h. Generated from abi-version.in by configure. */
/*
ABI Configuration file for the Fast Light Tool Kit (FLTK).

============================================================================
DO NOT EDIT - This file is generated by configure !
============================================================================

define FL_ABI_VERSION: 1xxyy for 1.x.y (xx,yy with leading zero)
*/

#define FL_ABI_VERSION 10306

And the build worked as before.
So... I guess I'm sorted, then. Whatever it was...




Leonardo UK Ltd

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.

********************************************************************

[Albrecht Schlosser]

On 4/12/21 12:10 PM 'MacArthur, Ian (Leonardo, UK)' via fltk.coredev wrote:
>> Ian, are you sure you didn't misspell the option somehow?
>
> No, not really sure!
>
> However, thinking back, setting the abi-version via configure has always been a bit flaky for my build.
>
> That said, I removed everything and checked out the tip of the 1.3 branch: commit d40093dd3bfec83387e507b43d0dbf3ba18cbe21
>
> Then I ran:
>
> auotconf
>
> followed by:
>
> LDFLAGS="-static-libgcc -static-libstdc++" ./configure --with-abiversion=10306 --enable-localjpeg --enable-localpng --enable-localzlib
>
> And let that run its course. At the end I had a valid abi-version.h file after all:

Phew, that's a relief! Thanks for testing again.


So, as far as I see it all our tests were (finally) successful and I can
proceed with the release. Great!

I'm currently working at the optimization flags we have (i.e. set) in
autoconf builds:

(a) add missing tests to set the same compiler flags
(b) finally output the flags to fltk-config

to make fltk-config --optim work as expected.

(b) is simple, (a) makes good progress.

If possible I'll commit this to branch-1.3.

[Rob McDonald]

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.

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.

FIND_PACKAGE(FLTK REQUIRED)
SET( FLTK_INCLUDE_DIR ${FLTK_INCLUDE_DIR} PARENT_SCOPE )
SET( FLTK_LIBRARIES ${FLTK_LIBRARIES} PARENT_SCOPE )

The result of this is to set:

FLTK_INCLUDE_DIR /Users/.../build/xcoderwdi-Libs/FLTK-prefix/include /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenGL.framework

FLTK_LIBRARIES -framework Carbon -framework Cocoa -framework ApplicationServices -lz /Users/.../build/xcoderwdi-Libs/FLTK-prefix/lib/libfltk_images.a /Users/.../build/xcoderwdi-Libs/FLTK-prefix/lib/libfltk_forms.a /Users/.../build/xcoderwdi-Libs/FLTK-prefix/lib/libfltk_gl.a /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenGL.framework /Users/.../build/xcoderwdi-Libs/FLTK-prefix/fltk.framework

Which seems reasonable.

There is a directory called FLTK.framework in the FLTK-prefix directory -- but notice the case difference. Renaming FLTK.framework to fltk.framework did not help the situation.

I get an error at the final link of my program....

ld: framework not found fltk
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The complete call (with some paths shortened and made private) is:

Linking CXX executable vsp

cd /Users/.../build/xcoderwdi-VSP/src/vsp && /Applications/CLion.app/Contents/bin/cmake/mac/bin/cmake -E cmake_link_script CMakeFiles/vsp.dir/link.txt --verbose=1

/usr/bin/c++   -std=c++11 -stdlib=libc++ -fPIC -O2 -g -DNDEBUG -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk -mmacosx-version-min=10.15 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/vsp.dir/common.cpp.o CMakeFiles/vsp.dir/main.cpp.o  -o vsp -F/Users/.../build/xcoderwdi-Libs/FLTK-prefix  ../geom_api/libgui_interface_g.a ../gui_and_draw/libgui_and_draw.a ../geom_core/libgeom_core.a ../geom_api/libgeom_api_g.a ../cfd_mesh/libcfd_mesh.a ../xmlvsp/libxmlvsp.a ../external/sixseries/libsixseries.a ../util/libutil.a ../external/tritri/libtritri.a ../external/clipper/libclipper.a ../external/angelscript/sdk/angelscript/lib/libAngelscript.a ../external/cartesian/libcartesian.a ../external/wavedragEL/libwavedragEL.a ../external/Pinocchio/Pinocchio/libpinocchio.a /Users/.../build/xcoderwdi-Libs/CPPTEST-prefix/lib/libcpptest.a /Users/.../build/xcoderwdi-Libs/LIBXML2-prefix/lib/libxml2.a -framework Carbon -framework Cocoa -framework ApplicationServices -lz /Users/.../build/xcoderwdi-Libs/FLTK-prefix/lib/libfltk_images.a /Users/.../build/xcoderwdi-Libs/FLTK-prefix/lib/libfltk_forms.a /Users/.../build/xcoderwdi-Libs/FLTK-prefix/lib/libfltk_gl.a -framework OpenGL -framework fltk -framework OpenGL -framework OpenGL /Users/.../build/xcoderwdi-Libs/CMINPACK-prefix/lib/libcminpack.a /Users/.../build/xcoderwdi-Libs/STEPCODE-prefix/src/STEPCODE/../sc-install/lib/libsdai_ap203.a /Users/.../build/xcoderwdi-Libs/STEPCODE-prefix/src/STEPCODE/../sc-install/lib/libstepeditor.a /Users/.../build/xcoderwdi-Libs/STEPCODE-prefix/src/STEPCODE/../sc-install/lib/libstepcore.a /Users/.../build/xcoderwdi-Libs/STEPCODE-prefix/src/STEPCODE/../sc-install/lib/libstepdai.a /Users/.../build/xcoderwdi-Libs/STEPCODE-prefix/src/STEPCODE/../sc-install/lib/libsteputils.a /Users/.../build/xcoderwdi-Libs/STEPCODE-prefix/src/STEPCODE/../sc-install/lib/libbase.a /Users/.../build/xcoderwdi-Libs/LIBIGES-prefix/lib/libiges_static.a /Users/.../build/xcoderwdi-Libs/TRIANGLE-prefix/lib/libtriangle-api.a /Users/.../build/xcoderwdi-Libs/TRIANGLE-prefix/lib/libtriangle.a ../vsp_graphic/libvsp_graphic.a /Users/.../build/xcoderwdi-Libs/GLEW-prefix/lib/libGLEWs.a ../external/glfont2/libglfont2.a ../external/stb/libstb_image.a /Users/.../build/xcoderwdi-Libs/EXPRPARSE-prefix/lib/libexprparse.a -framework OpenGL 

ld: framework not found fltk

clang: error: linker command failed with exit code 1 (use -v to see invocation)

Somewhere buried in that mess are:

-F/Users/.../build/xcoderwdi-Libs/FLTK-prefix 

-framework fltk

Which seem to be the right places.

I also edited the CMakeCache.txt and changed all occurrences of fltk.framework to FLTK.framework and tried again - same result, but in caps this time.

Any suggestions?

Rob

[Albrecht Schlosser]

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?

> SET( FLTK_INCLUDE_DIR ${FLTK_INCLUDE_DIR} PARENT_SCOPE )
> SET( FLTK_LIBRARIES ${FLTK_LIBRARIES} PARENT_SCOPE )

Okay, that looks fine.

> The result of this is to set:
> FLTK_INCLUDE_DIR /Users/.../build/xcoderwdi-Libs/FLTK-prefix/include
> /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenGL.framework
>
> FLTK_LIBRARIES -framework Carbon -framework Cocoa -framework
> ApplicationServices -lz
> /Users/.../build/xcoderwdi-Libs/FLTK-prefix/lib/libfltk_images.a
> /Users/.../build/xcoderwdi-Libs/FLTK-prefix/lib/libfltk_forms.a
> /Users/.../build/xcoderwdi-Libs/FLTK-prefix/lib/libfltk_gl.a
> /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenGL.framework
> /Users/.../build/xcoderwdi-Libs/FLTK-prefix/fltk.framework
>
> Which seems reasonable.

Yep, I agree so far.

> There is a directory called FLTK.framework in the FLTK-prefix directory
> -- but notice the case difference. Renaming FLTK.framework to
> fltk.framework did not help the situation.
>
> I get an error at the final link of my program....
>
> ld: framework not found fltk
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> The complete call (with some paths shortened and made private) is:

...

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.

[Albrecht Schlosser]

On 4/13/21 1:04 PM Albrecht Schlosser wrote:
> On 4/13/21 6:05 AM Rob McDonald wrote:
>>
>> 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.

> ...
> 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.

Note: In GitHub issue #164 [1] user MoAlyousef describes an alternate
way using the CMake FetchContent mechanism. In my comment [2] I posted a
modified and tested example CMakeLists.txt file.

I'm not sure if this is of any use for you. According to the CMake docs
this is "New in version 3.11".

At the time of my test it worked in FLTK 1.4 (Git master) but I
backported all that 1.4 CMake stuff to 1.3.6 (Git branch-1.3, as you
know) so this should work as well in the upcoming release.



[1] https://github.com/fltk/fltk/issues/164
[2] https://github.com/fltk/fltk/issues/164#issuecomment-732495144

[Rob McDonald]

On Tuesday, April 13, 2021 at 4:04:26 AM UTC-7 Albrecht Schlosser wrote:

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?

Yes, it appears that FLTK builds fine.  My program compiles fine, but it fails in the final link step on MacOS only.

The version we were using previously is https://github.com/fltk/fltk/commit/0c70362e63d6 

> 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.

I don't think this is the problem - I was mentioning it for context.

That said, External_Project_Add is a flexible CMake mechanism for bundling dependencies.  It allows you to drop another project into your build while keeping it very separate.  For example, it has options to download a source file directly from a project website, unzip that file to a temporary build directory, apply any patches that your project may need to make a dependency work, run ./configure or cmake on the dependency, build it, and then install it to a temporary directory.

It is a great way to package dependencies that are more complex than just a few files you want to add to a subdirectory of your project -- but you also don't want your downstream developers having to deal with the hassle of downloading, configuring, building, and installing every library that you deal with.  It also allows you to better control which library version was used to build.

Another clever use case is when your build process needs to use two different compilers.  Since ExternalProject_Add is a totally new build environment, it allows you to break a lot of cases where the first answer is 'cmake can't do that'.

One last fun use case -- I have used it recursively in a library before for testing.  The FLTK analog would be if FLTK had an application that you wanted to build as a test of the build process - lets say flsolitare.  You can set up flsolitare as an ExternalProject_Add to FLTK's build such that it behaves like a from-scratch project in its own build environment.  You can direct flsolitare's build to search for FLTK in the parent build's location.  

> 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.

Changing to

FIND_PACKAGE(FLTK REQUIRED CONFIG)

Makes it worse.  This command fails to find FLTK and set any of the required variables.

Rob

 

[Albrecht Schlosser]

On 4/13/21 7:00 PM Rob McDonald wrote:
>
> Yes, it appears that FLTK builds fine.  My program compiles fine, but it
> fails in the final link step on MacOS only.

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.

> That said, External_Project_Add is a flexible CMake mechanism for

> bundling dependencies.  It allows you ...

Thank you very much for your elaboration. I'll study this later (after
dinner).

> 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?
>

> Changing to
>
> FIND_PACKAGE(FLTK REQUIRED CONFIG)
>
> Makes it worse.  This command fails to find FLTK and set any of the
> required variables.

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

[Rob McDonald]

On Tuesday, April 13, 2021 at 11:38:31 AM UTC-7 Albrecht Schlosser wrote:

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 will try that out.

> 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?

Two ways.

I generally use what is called the SuperProject approach.

All my Libraries are in one CMakeLists.txt -- each added through ExternalProject_Add.  This project is called Libraries.

My application is in another CMakeLists.txt -- it searches for all the libraries using FindXXXX.cmake scripts -- with the hint given to start the search in the Libraries build directory.  This project is called Application.

There is a third CMakeLists.txt that can be used.  It adds Libraries and Application each as their own ExternalProject_Add.  This helps enforce that the projects must be totally built before they can be Found.

If you are a casual user of the application who just needs to build it on your platform, you likely use SuperProject - it should do everything in one mega process.

If you are a developer of the application, you probably don't want to re-build the Libraries all the time.  Instead, you should build the two projects manually / separately.  First the Libraries in a libraries build dir - then the application in another build directory -- pointed at Libraries to help FindXXX.cmake succeed.

My project is set up as a SuperProject - but as the developer, I almost always build in two parts.  In either case, FLTK is fully built and installed before I ever try running find_package().

 

What happens if you delete the entire build folder and build from scratch?

I have been doing this level of cleanup before every test.

 

> 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.

I had my CMake script print out the complete values of the variables it sets - those variables point at the directories I expect. 

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 will take a close look.  Thanks for the help. 

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

I've been using the ExternalProject_Add technique with FLTK for almost 10 years - on Linux, Windows, and MacOS.

From what I can tell -- everything is still working except for MacOS.  I do not think the ExternalProject_Add is the problem (FLTK appears to build by all accounts).

What is expected to be in a FLTK.framework directory?  Can you provide a listing of the files?  In a 'normal' install, where does this get put?  What about in an install where the user specifies the install directory?

Rob

 

[Rob McDonald]

OK, Substantial progress!

I went back and compared how FLTK was installing itself before vs. now.  I noticed that before, the framework files all went into:

install_dir/FLTK/.framework

and after, they went into:

install_dir/FLTK.framework

So, I tried this...

cd install_dir

mkdir FLTK

mv FLTK.framework FLTK/.framework

And then went and re-built my project -- everything worked.

So, what changed the install path from FLTK/.framework to FLTK.framework?  Why does this not cause other problems?  

Best,

Rob

[Albrecht Schlosser]

On 4/13/21 10:05 PM Rob McDonald wrote:
> On Tuesday, April 13, 2021 at 11:38:31 AM UTC-7 Albrecht Schlosser wrote:
>
> 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
> <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
> <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 will try that out.

I just committed an update that works on macOS as well -- with
find_package() in CONFIG mode, of course. ;-)

Okay, I see. Understood.

> I've been using the ExternalProject_Add technique with FLTK for almost
> 10 years - on Linux, Windows, and MacOS.
>
> From what I can tell -- everything is still working except for MacOS.
> I do not think the ExternalProject_Add is the problem (FLTK appears to
> build by all accounts).
>
> What is expected to be in a FLTK.framework directory?  Can you provide a
> listing of the files?  In a 'normal' install, where does this get put?
> What about in an install where the user specifies the install directory?

Here's a listing (tree) of the files in the FLTK.framework directory:

fltk-build/cmake-external-project/build$ tree
fltk/branch-1.3/bin/FLTK.framework/

fltk/branch-1.3/bin/FLTK.framework/
└── Resources
└── CMake
├── FLTK-Functions.cmake
├── FLTK-Targets-noconfig.cmake
├── FLTK-Targets.cmake
├── FLTKConfig.cmake
└── UseFLTK.cmake

2 directories, 5 files

This is from my example project "fltk-build/cmake-external-project" in
the CMake build folder "build" and lists the files generated in the
framework generated by FLTK. As you can see it's from the 'branch-1.3'
checkout, but the 'master' checkout is the same.

That said, I have no idea if this is all *correct* or if it is like any
macOS "standard" - but this is as it is now (in 1.3.6) and will likely
be in 1.4 once it gets released. Unless we learn that this is also wrong
and needs to be fixed...

Note: my demo projects show how you need to setup config mode in all
constellations. My gut feeling is that this is not perfect - too much
platform specific code in CMake files. However, this is the current
status of FLTK's CMake build system and of my knowledge. I hope this can
be simplified somehow.

[Albrecht Schlosser]

On 4/13/21 10:43 PM Rob McDonald wrote:
> OK, Substantial progress!
>
> I went back and compared how FLTK was installing itself before vs. now.
> I noticed that before, the framework files all went into:
>
> install_dir/FLTK/.framework
>
> and after, they went into:
>
> install_dir/FLTK.framework
>
> So, I tried this...
>
> cd install_dir
> mkdir FLTK
> mv FLTK.framework FLTK/.framework
>
> And then went and re-built my project -- everything worked.

Good, so far.

> So, what changed the install path from FLTK/.framework to
> FLTK.framework?  Why does this not cause other problems?

Answer 1: the change was caused by a bug fix in FLTK 1.4 which I now
backported to 1.3.6 together with all the other changes.
"FLTK/.framework" was just *wrong*, the correct naming must be
"FLTK.framework", like "OpenGL.framework".

Answer 2: What other problems do you expect?

Whatever you or anybody else did to circumvent the wrong naming should
be corrected when moving your program to 1.3.6. I tested both 1.4 and
1.3.6 with the same results, but ...

Note that the old FindFLTK.cmake included with CMake which is used by
find_package(FLTK ...) in *module* mode is broken since FLTK 1.3 (it was
designed for 1.1 and never changed).

The only "supported" usage of CMake since FLTK 1.3 is to use CONFIG mode
as documented in README.CMake.txt - with all constraints about not yet
being officially supported, i.e. it's experimental in FLTK 1.3 anyway.

[Rob McDonald]

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'.

I will keep trying with CONFIG mode to see if I can get that to work.

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

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.

Or possibly we need to just try it twice...

find_package(FLTK CONFIG) # Try to find CMake built FLTK first

if (NOT FLTK_FOUND)

    find_package(FLTK)          # Find ./configure FLTK as fallback

endif()

Rob

[Albrecht Schlosser]

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.

> I will keep trying with CONFIG mode to see if I can get that to work.

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.

(c) Yet another request was to provide pkg-config files to be installed
with FLTK. This would be another option for users to configure FLTK for
their apps.

There's definitely room for improvement, and discussions like this are
really helpful to see what FLTK users need.

Thanks for your input!

> Or possibly we need to just try it twice...
>
> find_package(FLTK CONFIG) # Try to find CMake built FLTK first
> if (NOT FLTK_FOUND)
>     find_package(FLTK)          # Find ./configure FLTK as fallback
> endif()

That would be a pragmatic solution. Maybe the way to go until a better
solution is available.

[Rob McDonald]

I now have FIND_PACKAGE(FLTK CONFIG) such that it returns FLTK_FOUND = 1.

However, it is not setting the variables that it should...

The output of this CMake script

MESSAGE( STATUS "FLTK_INSTALL_DIR" ${FLTK_INSTALL_DIR})
SET( CMAKE_PREFIX_PATH ${FLTK_INSTALL_DIR} ${ORIG_CMAKE_PREFIX_PATH} )
SET( FLTK_DIR ${FLTK_INSTALL_DIR}/bin/FLTK.framework/Resources/CMake/ )
MESSAGE( STATUS "FLTK_DIR" ${FLTK_DIR})
FIND_PACKAGE( FLTK CONFIG )
MESSAGE( STATUS "FLTK_FOUND " ${FLTK_FOUND} )
MESSAGE( STATUS "FLTK_INCLUDE_DIR " ${FLTK_INCLUDE_DIR} )
MESSAGE( STATUS "FLTK_LIBRARIES " ${FLTK_LIBRARIES} )
MESSAGE( STATUS "FLTK_FLUID_EXECUTABLE " ${FLTK_FLUID_EXECUTABLE} )
MESSAGE( STATUS "FLTK_WRAP_UI " ${FLTK_WRAP_UI} )

Is as follows:

-- FLTK_INSTALL_DIR/Users/ramcdona/Documents/OpenVSP/build/xcoderwdi-Libs/FLTK-prefix

-- FLTK_DIR/Users/ramcdona/Documents/OpenVSP/build/xcoderwdi-Libs/FLTK-prefix/bin/FLTK.framework/Resources/CMake/
-- FLTK_FOUND 1
-- FLTK_INCLUDE_DIR
-- FLTK_LIBRARIES
-- FLTK_FLUID_EXECUTABLE fluid
-- FLTK_WRAP_UI

Apparently only FLTK_FOUND and FLTK_FLUID_EXECUTABLE are set the way they are supposed to be.

Strangely, when I go to use FLTK_FLUID_EXECUTABLE later it is not set.  Apparently the PARENT_SCOPE promotion I do isn't working.

Digging into FLTKConfig.cmake, it defines FLTK_INCLUDE_DIRS not FLTK_INCLUDE_DIR.

When you use CONFIG mode, does the documentation at the top of FindFLTK.cmake no longer apply?  What is supposed to be set?

If different variables are set depending on how FLTK was built -- making a single CMake setup that works for both will be nearly impossible.

Rob

[Rob McDonald]

On Tuesday, April 13, 2021 at 2:44:14 PM UTC-7 Albrecht Schlosser wrote:

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.

I am still using FindFLTK.cmake from the CMake installation -- is there a different one that you think I should be using?

 > I will keep trying with CONFIG mode to see if I can get that to work.

okay...

Some progress reported in another message -- no great joy yet. 

> 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.

Absolutely.  And for the most part, the FLTK API is pretty stable and my program is able to be compiled against many different versions of FLTK.  So, if someone is installing on a Linux that tracks packages conservatively, I still expect FIND_PACKAGE(FLTK) to be able to find something (header files, shared libraries, and fluid) such that my program will build with the FLTK installed on the system.

My build system has a flag to either use the system installed library -- or the one bundled in ExternalProject_Add.  If there is a reason we know we need the new version - or if the system installed one does not work (or always on Mac and Windows) then you should used the bundled version.

In all of these cases, FIND_PACKAGE is a reasonable way to discover libraries -- in fact it is the 100% correct way in CMake for more than a decade.  Whether the library is built with CMake or not.  And FLTK's has been broken for a decade and any time someone brings it up, they get told that it is not supported and do not do that. 

> 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...

I know my opinion on this is unpopular.  I know FLTK is a community effort.  I don't even get a vote -- much less am I the FLTK dictator.

However, maintaining multiple meta build systems is a ridiculous waste of resources for an effort constrained project.  The only thing dumber than maintaining both ./configure and CMake approaches is to maintain a whole bunch of project file formats for every IDE imaginable.  Oh wait, FLTK did that until recently....

The only sane thing is to use CMake for what it is intended.  Go all in on _one_ system.  Stop dividing resources.

I know this is impossible because someone is still using FLTK on an abacus and other people are worried that CMake is somehow hard to use.

End of rant...

 

(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.

This _absolutely_ must be a part of the solution.  Of course it will be old on a lot of machines -- but if someone had maintained it at some point in the last decade, all those old computers would have a decent file by now.

In the meantime, FLTK can provide a FindFLTK.cmake script that projects (like mine) can bundle locally -- we can use the local version until CMake distribution has decent penetration that we can stop carrying our own version.

Perhaps this exists - and I'm not using it - and that is part of the problem....

Rob

[Albrecht Schlosser]

On 4/14/21 12:08 AM Rob McDonald wrote:
> I now have FIND_PACKAGE(FLTK CONFIG) such that it returns FLTK_FOUND = 1.
>
> However, it is not setting the variables that it should...

> ... > When you use CONFIG mode, does the documentation at the top of

> FindFLTK.cmake no longer apply?  What is supposed to be set?

Good questions.

I'll look into this tomorrow, it's now after midnight here.

Have a nice afternoon. Good night. ;-)

[Rob McDonald]

I do appreciate the help.  And the remarkable responsiveness from Germany.

Rob

[Rob McDonald]

Albrecht,

I've extended your external-project example to follow the pattern I'm using with SuperProjects and whatnot.  It is overkill for a small project like this, but it works well for me for a big project with a bunch of complex dependencies.

https://github.com/ramcdona/fltk-build

You can either build the SuperProject, or build the Lib first and then the App.  If you do it in two-steps, you'll need to pass -DLIBRARY_PATH=/full/path/to/place/where/you/built/Lib to cmake for the App step.  

This example successfully compiles -- but it also exhibits the problems I am seeing.

Namely - several variables that are supposed to be set by FIND_PACAGE( FLTK CONFIG ) are not set.

In the longer run, I think it would be good to extend this simple example to one that uses *.fl files managed by CMake.

Although I have mostly moved away from using fluid in my program, there are still a few places I use it.  In my past experience, the hardest thing for FindFLTK.cmake on various random machines was always finding fluid...  We could usually find the headers and libraries, but often not fluid.  I believe this is almost always because they had installed the fltk package - but not the fltk-dev package...

Thanks again for all the help,

Rob

[Albrecht Schlosser]

On 4/14/21 4:01 AM Rob McDonald wrote:

> I've extended your external-project example to follow the pattern I'm
> using with SuperProjects and whatnot.  It is overkill for a small
> project like this, but it works well for me for a big project with a
> bunch of complex dependencies.
>
> https://github.com/ramcdona/fltk-build

Thank you very much. This was something I was going to ask you to do,
now you did it already. I did not yet try it due to doing other stuff
today, but I will definitely and try to learn how FLTK users would do
it. Personally I'm building only small FLTK projects (I used a bigger
commercial FLTK project ca. 2003 - 2012) so I didn't have much
experience in using things like ExternalProject.

> This example successfully compiles -- but it also exhibits the problems
> I am seeing.
>
> Namely - several variables that are supposed to be set by FIND_PACAGE(
> FLTK CONFIG ) are not set.

Thanks for the list in another message. I'll see if I can improve this -
maybe even for 1.3.6, but this will likely take a little more time than
I anticipated.

> In the longer run, I think it would be good to extend this simple
> example to one that uses *.fl files managed by CMake.

That's my plan...

> Although I have mostly moved away from using fluid in my program, there

> are still a few places I use it. ...

>
> Thanks again for all the help,

Welcome.

Note: I'm now looking around to decide what I can do before the 1.3.6
release and what must be postponed. I'm reading CMake docs and studying
other FindXXX.cmake files. This is really essential before I answer your
other questions and before I can come to a decision what to do in the
short term and the long term.

So please don't expect more replies to this (your) topic soon. I'm
working on it ... ... ...

[Albrecht Schlosser]

On 4/14/21 5:49 PM Albrecht Schlosser wrote:
> On 4/14/21 4:01 AM Rob McDonald wrote:
>> Namely - several variables that are supposed to be set by FIND_PACAGE(
>> FLTK CONFIG ) are not set.
>
> Thanks for the list in another message. I'll see if I can improve this -
> maybe even for 1.3.6, but this will likely take a little more time than
> I anticipated.

> ...

> Note: I'm now looking around to decide what I can do before the 1.3.6
> release and what must be postponed. I'm reading CMake docs and studying
> other FindXXX.cmake files. This is really essential before I answer your
> other questions and before I can come to a decision what to do in the
> short term and the long term.

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).

Rob, here are a few further facts and questions...

The plan is:

(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).

[Rob McDonald]

On Thursday, April 15, 2021 at 12:58:52 PM UTC-7 Albrecht Schlosser wrote:

Phew, that was hard stuff, but I can report some success!

Fabulous!  Thanks much.

 

I managed to modify the CMake module FindFLTK.cmake so you can use both
module mode (default) or config mode (either explicitly or implicitly).

Great.  This should help a lot for either 1) minimal surprise or 2) systems with FLTK built with ./configure 

(1) Modify our generated CMake files so you can use them by executing
standard find_package(FLTK) commands.

Great 

 

(2) Modify FindFLTK.cmake to make this work with (1).

Great 

 

(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?

This may actually be more common than not...

This should be no problem.

I usually modify CMAKE_MODULE_PATH to point to a local 'cmake' directory anyway -- it gives a good way to organize local CMake scripts.  I believe this is very common practice.  Something like this...

set( CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake ${CMAKE_MODULE_PATH} )

When I carry a local version of FindXXXX.cmake, I usually change the name to something like FindFLTK_MYPROJECT.cmake -- that way, there is no possible ambiguity as to which version I am running and it communicates to any reader of the code that I am using a local or modified script rather than the one that ships with CMake.  However, that is something reasonably left up to the user of FLTK.

Many FindXXXX.cmake scripts allow the user to set some variable before running find_package() to pass some sort of hints to find_package.  Passing FLTK_DIR is a fine example of this -- nobody should be surprised by it.

I believe it would be best to make the script work with FLTK_DIR point to the top level of an FLTK installation directory (rather than a path deeper into said installation).  I believe this is what most users will expect.

All of CMake's commands like find_path and find_library allow you to pass multiple starting points for the search.  So, you should be able to have ${FLTK_DIR} and ${FLTK_DIR}/deeper/relative/path/to/config/file in that list and everything should be good.

 

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).

I don't think that dropping support for 1.1 should be too big of an issue.

If it is, there are several solutions...  We could ask the CMake project to keep the current version as a FindFLTK1_1.cmake script.  Or perhaps you could embed the old version of the file behind IF (VERSION) logic of some sort.

If someone is still using FLTK 1.1, they probably have control over the machine (they aren't using a system-installed FLTK on an actively maintained / officially supported Linux distribution). So, we can also reasonably assume that they have full control over the CMake version -- they won't un-knowingly be running old FLTK 1.1 and brand-new CMake 3.20.

Rob

[Albrecht Schlosser]

On 4/16/21 8:00 PM Rob McDonald wrote:
> On Thursday, April 15, 2021 at 12:58:52 PM UTC-7 Albrecht Schlosser wrote:
>
> Phew, that was hard stuff, but I can report some success!
>
> Fabulous!  Thanks much.
>
> I managed to modify the CMake module FindFLTK.cmake so you can use both
> module mode (default) or config mode (either explicitly or implicitly).
>
> Great.  This should help a lot for either 1) minimal surprise or 2)
> systems with FLTK built with ./configure

Yes, after much research, many thoughts and experiments I came to the
conclusion that this is the only way to go.

> (3) As long as this modified FindFLTK.cmake file is not yet brought

> upstream ... 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.
>

> 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
>

> This may actually be more common than not...
>
> This should be no problem.
>
> I usually modify CMAKE_MODULE_PATH to point to a local 'cmake' directory
> anyway -- it gives a good way to organize local CMake scripts.  I
> believe this is very common practice.  Something like this...
>
> set( CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake ${CMAKE_MODULE_PATH} )

Yep, we're doing this in FLTK as well. I think this is only used for
FindSDL2.cmake (which is used for special driver builds, not general
purpose), but anyway.

> Many FindXXXX.cmake scripts allow the user to set some variable before
> running find_package() to pass some sort of hints to find_package.
> Passing FLTK_DIR is a fine example of this -- nobody should be surprised
> by it.

Yes, I thought so too, however... There's a lot of confusion in the
existing FindFLTK.cmake (3.16.3), like this (with line numbers):

107 # If FLTK_INCLUDE_DIR is already defined we assigne its value to
FLTK_DIR
108 if(FLTK_INCLUDE_DIR)
109 set(FLTK_DIR ${FLTK_INCLUDE_DIR})
110 endif()

Then, below:

117 if(NOT FLTK_DIR)
118 # Get the system search path as a list.
119 file(TO_CMAKE_PATH "$ENV{PATH}" FLTK_DIR_SEARCH2)

The following code overwrites FLTK_DIR again with FLTK_INCLUDE_DIR (the
opposite way) which is (or should IMHO be) a derived ("calculated")
variable. Then it looks for FLTKConfig.cmake and, if found, executes
(includes) it, and later:

172 set(FLTK_INCLUDE_DIR ${FLTK_DIR})
173 link_directories(${FLTK_LIBRARY_DIRS})

Now FLTK_INCLUDE_DIR is assigned the ${FLTK_DIR} value.

[ Sorry, now I'm confused! ]

And, BTW, this variable should - according to CMake developer docs - be
named FLTK_INCLUDE_DIRS (plural). But we can also return
FLTK_INCLUDE_DIR for backwards compatibility with the same value. That's
what the docs suggest anyway (and would make your build happy ;-))

And I would also say that

link_directories(${FLTK_LIBRARY_DIRS})

is
(a) ancient stuff (use target_link_directories() instead)
and
(b) should NOT be done in FindFLTK.cmake. The find module should only
/return/ the variable but not set /global/ (link_directories) attributes.

And so on...

It's really confusing in a way that I'm thinking a full rewrite would be
better than trying to "fix" it.

But that's again stuff for another day...

> I believe it would be best to make the script work with FLTK_DIR point
> to the top level of an FLTK installation directory (rather than a path
> deeper into said installation).  I believe this is what most users will
> expect.

Yes, in my new script this works (the old FindFLTK module would not).
This was very annoying and I found this really surprising. Now that I
know what was wrong I could fix it in my own version.

> All of CMake's commands like find_path and find_library allow you to
> pass multiple starting points for the search.  So, you should be able to
> have ${FLTK_DIR} and ${FLTK_DIR}/deeper/relative/path/to/config/file in
> that list and everything should be good.

Yep, from my new file, for instance:

163 find_file(FLTK_CMAKE_CONFIG_FILE FLTKConfig.cmake
164 PATHS ${FLTK_DIR}
165 PATH_SUFFIXES
166 share/fltk
167 lib/fltk
168 )
169 if (FLTK_CMAKE_CONFIG_FILE)
170 set (FLTK_BUILT_WITH_CMAKE 1)
171 endif ()

Line 166 (share/fltk) is the relative /installation/ directory of
FLTKConfig.cmake whereas it's directly in the /build/ folder (no
subdir). Both instances are found now. Apple frameworks still need to be
implemented and tested.

> 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.

As I wrote above, this meanwhile led me to the assumption that a full
rewrite would be the best - and my goal is to make it work for FLTK >=
1.3.x (x still to be determined) and of course 1.4.0 and later.

> 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).
>
> I don't think that dropping support for 1.1 should be too big of an issue.
>
> If it is, there are several solutions...  We could ask the CMake project
> to keep the current version as a FindFLTK1_1.cmake script.  Or perhaps
> you could embed the old version of the file behind IF (VERSION) logic of
> some sort.

Both approaches would have backwards compatibility issues. Perhaps they
would add the new one as FindFLTK1.3.cmake or such. The "workaround"
would be to provide it with FLTK so users can use it with their own builds.

> If someone is still using FLTK 1.1, they probably have control over the
> machine (they aren't using a system-installed FLTK on an actively
> maintained / officially supported Linux distribution).

Surprise, surprise! Current Debian still ships both FLTK 1.1 and FLTK
1.3 in different install locations!

> So, we can also
> reasonably assume that they have full control over the CMake version --
> they won't un-knowingly be running old FLTK 1.1 and brand-new CMake 3.20.

Hopefully.

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.

[Rob McDonald]

On Friday, April 16, 2021 at 1:26:51 PM UTC-7 Albrecht Schlosser wrote:

[ Sorry, now I'm confused! ]

Yes, I got dizzy at about this point as well...

 

(b) should NOT be done in FindFLTK.cmake. The find module should only
/return/ the variable but not set /global/ (link_directories) attributes.

Strong agree

 

Surprise, surprise! Current Debian still ships both FLTK 1.1 and FLTK
1.3 in different install locations!

Wow.  That is special.

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.

Everything you describe sounds great.  Thanks very much.

Let me know if there is anything I can do to assist.

Rob

 

[Albrecht Schlosser]

Welcome.

> Let me know if there is anything I can do to assist.

FYI: I gave up my intention to change anything in FLTK 1.3.6 and to
provide a new FindFLTK.cmake module *now*. As you may have seen FLTK
1.3.6rc1 is now released.


However, I modified our FLTKConfig.cmake file slightly so it returns
both 'FLTK_INCLUDE_DIRS' (plural, the new and "correct" naming AFAICT)
and the "old" variable 'FLTK_INCLUDE_DIR' (singular, as in
FindFLTK.cmake) for compatibility.


I'm still investigating and once the new FindFLTK.cmake is kinda ready
I'll post it here (likely in a new thread) and then I'd like you and
others to test it.

Before I can do this I need to do more tests and I'll also contact the
CMake guys on how to do this best and how to (maybe) get a new
FindFLTK.cmake module upstream. If I do it, I'd like to do it correct
for "modern CMake" (with fallback for older consumers, of course).

The biggest problem I'm seeing with this is backwards compatibility. We
don't know what users (and distributors like the Debian people) did.

One example on Debian Buster with installed libfltk (1.3):

/usr/lib/fltk/CMakeCache.txt:

---- snip ----
# Fake cmake cache (the Debian build uses configure) to appease
# CMake's picky FindFLTK.cmake.

//Inverted to compensate for FindFLTK.cmake's own inversion(!)
FLTK_USE_SYSTEM_JPEG:BOOL=FALSE
FLTK_USE_SYSTEM_PNG:BOOL=FALSE
FLTK_USE_SYSTEM_ZLIB:BOOL=FALSE
---- snip ----

What they do here is to "invert" the logic to compensate for a bug in
"CMake's picky FindFLTK.cmake" which is indeed broken. But that
"compensation" leads to the next problem if (when!) you install a newer
CMake version that *fixes* the bug. Shudder!

The fact that they install a "Fake cmake cache" is IMHO more than
questionable too.

[Rob McDonald]

Thanks for this update.  I'll hold off on testing rc1 until I hear back from you.

Not sure what to do about that Debian ugliness.  Does the package identify the packager?  Perhaps it is worth looping them in on the pending changes.

Somebody had to think that was a good idea -- and perhaps they had an idea what to do if / when the world was a better place.

Rob

[Albrecht Schlosser]

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.

> Not sure what to do about that Debian ugliness.  Does the package
> identify the packager?  Perhaps it is worth looping them in on the
> pending changes.

The packager is known and I remember that he filed some STR's and was
helpful in the past. I could contact him but I don't want to do this
before I have a working new version or at least a clear concept to discuss.

> Somebody had to think that was a good idea -- and perhaps they had an
> idea what to do if / when the world was a better place.

Yes, maybe. Or maybe not.

>
> On Monday, April 26, 2021 at 2:22:36 PM UTC-7 Albrecht Schlosser wrote:

> ... > FYI: I gave up my intention to change anything in FLTK 1.3.6 and to

[Rob McDonald]

On Monday, April 26, 2021 at 3:46:19 PM UTC-7 Albrecht Schlosser wrote:

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.

Thanks for the clarification.

Running FindPackage(FLTK CONFIG)  and then printing out the expected variables, I get...

-- FLTK_FOUND 1

-- FLTK_INCLUDE_DIR /Users/.../FLTK-prefix/include

-- FLTK_INCLUDE_DIRS /Users/.../FLTK-prefix/include

-- FLTK_LIBRARIES

-- FLTK_FLUID_EXECUTABLE fluid

-- FLTK_WRAP_UI

So, it appears that FLTK_LIBRARIES is not being set.  Also, I have great skepticism about FLTK_FLUID_EXECUTABLE here.  I would expect it to provide a fully qualified path to fluid rather than just the executable name.

Also, note no success message 'Found FLTK:' is printed.

When I run without CONFIG set, I get.....

-- Found FLTK: /Users/.../FLTK-prefix/lib/libfltk_images.a;/Users/.../FLTK-prefix/lib/libfltk_forms.a;/Users/.../FLTK-prefix/lib/libfltk_gl.a;/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenGL.framework;/Users/.../FLTK-prefix/fltk.framework

-- FLTK_FOUND TRUE

-- FLTK_INCLUDE_DIR /Users/.../FLTK-prefix/include/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenGL.framework

-- FLTK_INCLUDE_DIRS

-- FLTK_LIBRARIES -framework Carbon -framework Cocoa -framework ApplicationServices -lz/Users/.../FLTK-prefix/lib/libfltk_images.a/Users/.../FLTK-prefix/lib/libfltk_forms.a/Users/.../FLTK-prefix/lib/libfltk_gl.a/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenGL.framework/Users/.../FLTK-prefix/fltk.framework

-- FLTK_FLUID_EXECUTABLE /Users/.../FLTK-prefix/bin/fluid.app/Contents/MacOS/fluid

-- FLTK_WRAP_UI 1

It more or less behaves as expected.  Except as discussed before the issue I don't understand about the fltk.framework path that doesn't work properly.

Rob

[Bob Tolbert]

Build failure on latest macOS/XCode

On macOS 11.3/Intel, updated 4/27/2021.

XCode 12.5 updated 4/27/2021.

using 1.3.6RC1 download

$ tar -jxvf fltk-1.3.6rc1-source.tar.bz2

$ cd fltk-1.3.6rc1

$ mkdir build && cd build

$ cmake ..

$ make

- snip -

[ 14%] Linking C static library ../lib/libfltk_png.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../lib/libfltk_png.a(arm_init.c.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../lib/libfltk_png.a(filter_neon_intrinsics.c.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../lib/libfltk_png.a(palette_neon_intrinsics.c.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../lib/libfltk_png.a(arm_init.c.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../lib/libfltk_png.a(filter_neon_intrinsics.c.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../lib/libfltk_png.a(palette_neon_intrinsics.c.o) has no symbols
[ 14%] Built target fltk_png
Scanning dependencies of target fltk
[ 14%] Building CXX object src/CMakeFiles/fltk.dir/Fl.cxx.o
In file included from /Users/bob/build/fltk-1.3.6rc1/src/Fl.cxx:67:
In file included from /Users/bob/build/fltk-1.3.6rc1/FL/x.H:32:
In file included from /Users/bob/build/fltk-1.3.6rc1/FL/mac.H:50:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:23:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:19:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:24:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/math.h:309:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/type_traits:417:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/cstddef:37:
/Users/bob/build/fltk-1.3.6rc1/version:1:1: error: expected unqualified-id
1.3.6
^
In file included from /Users/bob/build/fltk-1.3.6rc1/src/Fl.cxx:67:
In file included from /Users/bob/build/fltk-1.3.6rc1/FL/x.H:32:
In file included from /Users/bob/build/fltk-1.3.6rc1/FL/mac.H:50:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:23:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:19:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:24:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/math.h:309:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/type_traits:418:
/Users/bob/build/fltk-1.3.6rc1/version:1:1: error: expected unqualified-id
1.3.6
^
In file included from /Users/bob/build/fltk-1.3.6rc1/src/Fl.cxx:67:
In file included from /Users/bob/build/fltk-1.3.6rc1/FL/x.H:32:
In file included from /Users/bob/build/fltk-1.3.6rc1/FL/mac.H:50:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:23:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:19:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:24:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/math.h:310:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/limits:121:
/Users/bob/build/fltk-1.3.6rc1/version:1:1: error: expected unqualified-id
1.3.6
^
3 errors generated.
make[2]: *** [src/CMakeFiles/fltk.dir/Fl.cxx.o] Error 1
make[1]: *** [src/CMakeFiles/fltk.dir/all] Error 2
make: *** [all] Error 2

happy to try anything else that might help.

Bob Tolbert

[Albrecht Schlosser]

On 4/27/21 7:38 PM Bob Tolbert wrote:
> Build failure on latest macOS/XCode
>
> On macOS 11.3/Intel, updated 4/27/2021.
> XCode 12.5 updated 4/27/2021.

Thank you very much for your report!

This is only a question and has nothing to do with the build issue: you
write "macOS/XCode" but you're using cmake + make to build FLTK. I
assume you installed Xcode to get the build tools but in your build
you're using make (not Xcode). Right?

> using 1.3.6RC1 download
>
> $ tar -jxvf fltk-1.3.6rc1-source.tar.bz2
> $ cd fltk-1.3.6rc1
> $ mkdir build && cd build
> $ cmake ..
> $ make
> - snip -
> [ 14%] Linking C static library ../lib/libfltk_png.a
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
> file: ../lib/libfltk_png.a(arm_init.c.o) has no symbols

...

FTR: All these "ranlib: file: ... has no symbols" warnings are known and
can be ignored.

> [ 14%] Building CXX object src/CMakeFiles/fltk.dir/Fl.cxx.o
> In file included from /Users/bob/build/fltk-1.3.6rc1/src/Fl.cxx:67:
> In file included from /Users/bob/build/fltk-1.3.6rc1/FL/x.H:32:
> In file included from /Users/bob/build/fltk-1.3.6rc1/FL/mac.H:50:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:23:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:19:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:24:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/math.h:309:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/type_traits:417:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/cstddef:37:
> /Users/bob/build/fltk-1.3.6rc1/version:1:1: error: expected unqualified-id
> 1.3.6
> ^

This is a silly error, I assume depending on the compiler and case
sensitivity of the file system.

Question: is your file system case sensitive or not?

This is only for (my) info, but it can make a difference and I'd like to
know if this is the case. On my system (Big Sur on Apple Silicon (M1))
with a case /sensitive/ file system the error doesn't appear but it can
also depend on the compiler tools.

Anyway, the fault is that in this scenario the source directory is used
as one of the '-I' commandline switches and it happens that

#include <version>

in one or more system headers erroneously includes the file 'VERSION'
whose contents is "1.3.6" and compilation fails.

Solution: please rename the file 'VERSION' to 'fltk_version.dat' as it
is in 1.4.0 development (git master). There was a reported issue but I
renamed that file only in 1.4.0 and not in branch-1.3. :-(

> happy to try anything else that might help.

Could you please try to build again (or just restart the build) after
renaming that file?

TIA, Albrecht

[Albrecht Schlosser]

On 4/27/21 6:07 PM Rob McDonald wrote:
> On Monday, April 26, 2021 at 3:46:19 PM UTC-7 Albrecht Schlosser wrote:
>
> 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).

> ...

>
> Thanks for the clarification.
>
> Running FindPackage(FLTK CONFIG)  and then printing out the expected
> variables, I get...
>
> -- FLTK_FOUND 1
> -- FLTK_INCLUDE_DIR /Users/.../FLTK-prefix/include
> -- FLTK_INCLUDE_DIRS /Users/.../FLTK-prefix/include
> -- FLTK_LIBRARIES
> -- FLTK_FLUID_EXECUTABLE fluid
> -- FLTK_WRAP_UI
>
> So, it appears that FLTK_LIBRARIES is not being set.

Yes, that's obviously the case, but that's one of the points I could not
address now (see also my note above: "The only relevant changes you
should expect..."). The reason is that this would have needed more
changes than I could do in this release. It may look simple to set these
variables, but please trust me, it's not if you want to do it right.

> Also, I have great skepticism about FLTK_FLUID_EXECUTABLE here.
> I would expect it to provide a fully qualified path to fluid
> rather than just the executable name.

It's neither a full path nor "just the executable name", it's a CMake
"target" (or at least it should be).

if(TARGET fluid)
message(STATUS "fluid is a target")
endif()

should show you that.

What's the difference? Let me say, it's the difference between "old" and
"modern" CMake. Historically you would name libraries and executables
and, if in question, provide full paths in CMake variables. In "modern"
CMake you use CMake targets in your app build rather than library names.
CMake targets can have lots of attributes, for instance the "location"
but also "usage requirements".

The existing FLTKConfig.cmake is in parts "modern CMake" because it
returns CMake targets. The old FindFLTK.cmake returns "variables" instead.

I know this may not be very helpful, but if you look at our
README.CMake.txt with that in mind you may notice the difference.

"The CMake Export/Import facility can be thought of as an automated
fltk-config. For example, if you link your program to the FLTK library,
it will automatically link in all of its dependencies. ..."

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.)

> Also, note no success message 'Found FLTK:' is printed.

I don't know where this message comes from (find_package() or
FindFLTK.cmake?) but I'll check that for my future development.

> When I run without CONFIG set, I get.....
>
> -- Found FLTK:
> /Users/.../FLTK-prefix/lib/libfltk_images.a;/Users/.../FLTK-prefix/lib/libfltk_forms.a;/Users/.../FLTK-prefix/lib/libfltk_gl.a;/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenGL.framework;/Users/.../FLTK-prefix/fltk.framework
> -- FLTK_FOUND TRUE
> -- FLTK_INCLUDE_DIR
> /Users/.../FLTK-prefix/include/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenGL.framework
> -- FLTK_INCLUDE_DIRS
> -- FLTK_LIBRARIES -framework Carbon -framework Cocoa -framework
> ApplicationServices

BTW: I think from the line above you only really need "-framework Cocoa".

> -lz/Users/.../FLTK-prefix/lib/libfltk_images.a/Users/.../FLTK-prefix/lib/libfltk_forms.a/Users/.../FLTK-prefix/lib/libfltk_gl.a/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenGL.framework/Users/.../FLTK-prefix/fltk.framework
> -- FLTK_FLUID_EXECUTABLE
> /Users/.../FLTK-prefix/bin/fluid.app/Contents/MacOS/fluid
> -- FLTK_WRAP_UI 1
>
> It more or less behaves as expected.  Except as discussed before the
> issue I don't understand about the fltk.framework path that doesn't work
> properly.

I have no direct recommendation for you here. Maybe stick to the old
find_package() with your build system. I don't know what to do with the
macOS framework issue.

[Rob McDonald]

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.)

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.

It now seems that I not only need to add the word CONFIG - but I also need to go through and excise the use of FLTK_LIBRARIES and whatnot and instead switch to the target names.

If this checks out, I can give it a go (still have problems with platforms built with ./configure), but it certainly isn't the way I was trying to do things.

 

 

BTW: I think from the line above you only really need "-framework Cocoa".

That may be -- but it seems harmless.  Part of the point of using the CMake find_package stuff is that as a user, you hopefully don't have to pay close attention to what gets returned in the variables.  Somehow whatever is needed for whatever platform and compiler should be returned...  So, if something extra or wrong is being returned, I suspect it is another issue with the CMake scripts.

Rob

[Albrecht Schlosser]

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.