Minor Feature request.

[Gonzalo Garramulo]

When building CMake's libjpeg, libpng, etc. libraries with the system
path ones, would it be possible to print out the path to them instead of
just "System".

--
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 4/7/24 19:30 Gonzalo Garramulo wrote:

When building CMake's libjpeg, libpng, etc. libraries with the system path ones, would it be possible to print out the path to them instead of just "System".

OK, you mean in the "Configuration Summary" at the end of the CMake configure process, and you would like to see the real library paths, is this correct?

If that's what you want: I believe this could work.

What if we use the "Builtin" libs instead? I think this doesn't need to be changed because the library path is output a few lines above. Is this OK for you?

```

Static libraries will be built in /path/to/fltk/build/debug/lib

[...]

Build configuration : Debug

Image Libraries : JPEG = Builtin <-- keep, see above for path ?

: PNG = System <-- output the actual path ?

: ZLIB = System <-- output the actual path ?

```

I'm not sure yet what to do if both a static and a shared system lib exists, or which one will be "found" by CMake. I'll check this...

[Gonzalo Garramulo]

El 7/4/24 a las 15:30, 'Albrecht Schlosser' via fltk.coredev escribió:

OK, you mean in the "Configuration Summary" at the end of the CMake configure process, and you would like to see the real library paths, is this correct?

Yep!

If that's what you want: I believe this could work.

What if we use the "Builtin" libs instead? I think this doesn't need to be changed because the library path is output a few lines above. Is this OK for you?

Yes, Built-in is just fine as is.

```

Static libraries will be built in /path/to/fltk/build/debug/lib

[...]

Build configuration : Debug

Image Libraries : JPEG = Builtin <-- keep, see above for path ?

: PNG = System <-- output the actual path ?

: ZLIB = System <-- output the actual path ?

```

I'm not sure yet what to do if both a static and a shared system lib exists, or which one will be "found" by CMake. I'll check this...

CMake will find the shared libs, as it is the unix convention.  That's the one that should be printed out.

-- 
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 4/7/24 19:30 Gonzalo Garramulo wrote:

> When building CMake's libjpeg, libpng, etc. libraries with the system
> path ones, would it be possible to print out the path to them instead
> of just "System".

Yup, done in commit 265e5cd77b30581e7701927930d8fa887e0361df.

Please report any issues with this commit here.

[Gonzalo Garramuño]

On 8/4/24 14:00, 'Albrecht Schlosser' via fltk.coredev wrote:
>
> Please report any issues with this commit here.

Tried it on Linux.  The report was good, but, probably not related,
compilation failed with:

/FLTK-prefix/src/FLTK/src/Fl_Graphics_Driver.cxx
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Graphics_Driver.cxx:
In constructor ‘Fl_Scalable_Graphics_Driver::Fl_Scalable_Graphics_Driver()’:
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Graphics_Driver.cxx:748:3:
error: ‘fontsize_’ was not declared in this scope
  748 |   fontsize_ = -1;
      |   ^~~~~~~~~
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Graphics_Driver.cxx:
In member function ‘virtual void
Fl_Scalable_Graphics_Driver::font(Fl_Font, Fl_Fontsize)’:
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Graphics_Driver.cxx:866:3:
error: ‘fontsize_’ was not declared in this scope
  866 |   fontsize_ = size;
      |   ^~~~~~~~~
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Graphics_Driver.cxx:
In member function ‘virtual Fl_Fontsize
Fl_Scalable_Graphics_Driver::size()’:
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Graphics_Driver.cxx:883:10:
error: ‘fontsize_’ was not declared in this scope
  883 |   return fontsize_;
      |          ^~~~~~~~~
[33/530] Building CXX object src/CMakeFiles/fltk.dir/Fl_Help_View.cxx.o
FAILED: src/CMakeFiles/fltk.dir/Fl_Help_View.cxx.o
/usr/bin/c++ -DFL_LIBRARY -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE
-I/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/install/include
-I/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK-build/src/..
-I/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/..
-I/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/install/include/freetype2
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/libmount
-I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo
-I/usr/include/pixman-1 -I/usr/include/libpng16 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid
-I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gio-unix-2.0
-I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -fPIC
-I/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK-build/src
-O3 -DNDEBUG -MD -MT src/CMakeFiles/fltk.dir/Fl_Help_View.cxx.o -MF
src/CMakeFiles/fltk.dir/Fl_Help_View.cxx.o.d -o
src/CMakeFiles/fltk.dir/Fl_Help_View.cxx.o -c
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Help_View.cxx
In file included from
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Help_View.cxx:61:
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Help_View.cxx:
In member function ‘void Fl_Help_View::add_link(const char*, int, int,
int, int)’:
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/flstring.h:88:21:
error: ‘fl_strlcpy’ was not declared in this scope; did you mean
‘fl_strlcat’?
   88 | #    define strlcpy fl_strlcpy
      |                     ^~~~~~~~~~
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Help_View.cxx:409:3:
note: in expansion of macro ‘strlcpy’
  409 |   strlcpy(temp->filename, n, sizeof(temp->filename));
      |   ^~~~~~~
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Help_View.cxx:
In member function ‘void Fl_Help_View::add_target(const char*, int)’:
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/flstring.h:88:21:
error: ‘fl_strlcpy’ was not declared in this scope; did you mean
‘fl_strlcat’?
   88 | #    define strlcpy fl_strlcpy
      |                     ^~~~~~~~~~
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Help_View.cxx:443:3:
note: in expansion of macro ‘strlcpy’
  443 |   strlcpy(temp->name, n, sizeof(temp->name));
      |   ^~~~~~~
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Help_View.cxx:
In member function ‘void Fl_Help_View::format()’:
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/flstring.h:88:21:
error: ‘fl_strlcpy’ was not declared in this scope; did you mean
‘fl_strlcat’?
   88 | #    define strlcpy fl_strlcpy
      |                     ^~~~~~~~~~
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/FLTK-prefix/src/FLTK/src/Fl_Help_View.cxx:1369:13:
note: in expansion of macro ‘strlcpy’
 1369 |             strlcpy(linkdest, a

...etc...

--
Gonzalo Garramuño
ggar...@gmail.com

[imm]

Gonzalo,

Is it possible you have a mix of 1.3 & 1.4 headers getting found?

That's kind of what that looks like...

--
Ian
From my Fairphone FP3
   

[Gonzalo Garramuño]

On 8/4/24 15:20, imm wrote:
>
> Is it possible you have a mix of 1.3 & 1.4 headers getting found?
>
> That's kind of what that looks like...

You kind of guessed right.  It was older 1.4 headers getting found.

Sorry for the noise.

--
Gonzalo Garramuño
ggar...@gmail.com

[Gonzalo Garramuño]

On 8/4/24 14:00, 'Albrecht Schlosser' via fltk.coredev wrote:

I sent it to the cloud (GitHub Actions).  On Windows, with MSVC 2019, it
did not pick them up. I go:


-- Image Libraries          JPEG = System: LIB_jpeg-NOTFOUND
--                          PNG  = System: LIB_png-NOTFOUND
--                          ZLIB = System: LIB_zlib-NOTFOUND

The libraries are in my CMAKE_PREFIX_PATH, but with their windows names:

$ cd install/lib

$ ls *png*
libpng16_static.lib

libpng:
libpng16.cmake libpng16-release.cmake

$ ls *zlib*
zlib.lib

$ ls *jpeg*
jpeg-static.lib  turbojpeg-static.lib

Albrecht, you may need to use find_library( LIB_zlib NAMES z zlib etc..
) to detect their MSVC 2019 static and shared names.  Look at the
Find*.cmake package files that ship with cmake.

--
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 4/8/24 22:02 Gonzalo Garramuño wrote:

On 8/4/24 14:00, 'Albrecht Schlosser' via fltk.coredev wrote:

On 4/7/24 19:30 Gonzalo Garramulo wrote:

When building CMake's libjpeg, libpng, etc. libraries with the system
path ones, would it be possible to print out the path to them instead
of just "System".

Yup, done in commit 265e5cd77b30581e7701927930d8fa887e0361df.

Please report any issues with this commit here.

I sent it to the cloud (GitHub Actions).  On Windows, with MSVC 2019, it did not pick them up. I go:


-- Image Libraries          JPEG = System: LIB_jpeg-NOTFOUND
--                          PNG  = System: LIB_png-NOTFOUND
--                          ZLIB = System: LIB_zlib-NOTFOUND

This shouldn't happen at all. If the libs are not found, then FLTK should fall back to using the bundled libs. Maybe there's something wrong with the search or the report. I'll check this.

The libraries are in my CMAKE_PREFIX_PATH, but with their windows names:

$ cd install/lib

$ ls *png*
libpng16_static.lib

libpng:
libpng16.cmake libpng16-release.cmake

$ ls *zlib*
zlib.lib

$ ls *jpeg*
jpeg-static.lib  turbojpeg-static.lib

Albrecht, you may need to use find_library( LIB_zlib NAMES z zlib etc.. ) to detect their MSVC 2019 static and shared names.  Look at the Find*.cmake package files that ship with cmake.

Gonzalo, thanks for this report. I see what you mean but I can't pursue this right now. Please open a GitHub Issue and report there what you found and how you setup your build, e.g. CMAKE_PREFIX_PATH and more (all relevant parameters, CMake variables etc.).

Questions regarding the library filenames you posted above:

1. How would we find the '*16*' versions of libpng? On Unix/Linux systems there's usually a symbolic link from a non-versioned name to the versioned name which we can use. In your case we can't guess.

2. It looks like you have two jpeg libs, 'jpeg-static.lib' and 'turbojpeg-static.lib'. According to their names these would be two different static libs of 'libjpeg'. How could any build system decide which one of these you *want* to use?

3. What are these two files 'libpng16.cmake' and 'libpng16-release.cmake' good for? According to their names they don't look like CMake CONFIG files which should be named PNGConfig.cmake or similar, AFAICT.

If you know anything about the "usual" (Windows) names of all these libs then please report whatever can help to find the right libs. However, what you wrote above doesn't look like something that could (or should) be included in the search. For instance, both the "turbo" and the "-static" part of 'turbojpeg-static.lib' look pretty "random" (well, I know libturbojpeg, yes, but I hope you get what I mean). There must be a better way to specify the libraries if you have special needs. That's my gut feeling so far but I don't know of a solution.

Anyway, I'll take a look at CMake's Find* modules to see what they are doing. If these Find modules work we could probably use them rather than just using find_library(...). Looking around ...

Hmm, for instance FindJPEG.cmake does NOT look for any name including 'turbo':

$ egrep -i -B0 -A3 'turbo|static' /usr/share/cmake-3.25/Modules/FindJPEG.cmake
set(jpeg_names ${JPEG_NAMES} jpeg jpeg-static libjpeg libjpeg-static)
foreach(name ${jpeg_names})
  list(APPEND jpeg_names_debug "${name}d")
endforeach()

Maybe they add wildcards later, I didn't check that yet, but anyway, please open an issue, as written before, and add as much info as you can.

Thanks in advance.

[Gonzalo Garramuño]

On 8/4/24 18:50, 'Albrecht Schlosser' via fltk.coredev wrote:

Questions regarding the library filenames you posted above:

1. How would we find the '*16*' versions of libpng? On Unix/Linux systems there's usually a symbolic link from a non-versioned name to the versioned name which we can use. In your case we can't guess.

Use find_package(PNG).   It will handle that for you looking for extension names.

2. It looks like you have two jpeg libs, 'jpeg-static.lib' and 'turbojpeg-static.lib'. According to their names these would be two different static libs of 'libjpeg'. How could any build system decide which one of these you *want* to use?

I could be wrong, but I believe they are the same.  turbojpeg keeps backwards compatibility with libjpeg.

3. What are these two files 'libpng16.cmake' and 'libpng16-release.cmake' good for? According to their names they don't look like CMake CONFIG files which should be named PNGConfig.cmake or similar, AFAICT.

Not sure.

Thanks in advance.

I opened Issue #949 with a project using ExternalProject_Add of the FLTK libraries I mentioned.  It is a tad convoluted, but you should be able to follow it.  You can run it on all platforms.  For Windows you will need MSys64 and MSVC2019 or MSVC2022 (I added .bat files for them).

-- 
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 4/9/24 02:03 Gonzalo Garramuño wrote:

On 8/4/24 18:50, 'Albrecht Schlosser' via fltk.coredev wrote:

Questions regarding the library filenames you posted above:

1. How would we find the '*16*' versions of libpng? On Unix/Linux systems there's usually a symbolic link from a non-versioned name to the versioned name which we can use. In your case we can't guess.

Use find_package(PNG).   It will handle that for you looking for extension names.

OK, I'll look into it...

2. It looks like you have two jpeg libs, 'jpeg-static.lib' and 'turbojpeg-static.lib'. According to their names these would be two different static libs of 'libjpeg'. How could any build system decide which one of these you *want* to use?

I could be wrong, but I believe they are the same.  turbojpeg keeps backwards compatibility with libjpeg.

There's nothing like "the same" regarding two libraries. Yes, turbojpeg may be backwards compatible (API-wise), but I'd assume that the ABI is not the same. Therefore, if you link to one library and compile with the headers of the other library you'll get undefined behavior and can expect crashes. Didn't you recently report that using an older FLTK 1.4 header mix with current 1.4 caused you problems, IIRC in this thread???

I opened Issue #949 with a project using ExternalProject_Add of the FLTK libraries I mentioned.  It is a tad convoluted, but you should be able to follow it.  You can run it on all platforms.  For Windows you will need MSys64 and MSVC2019 or MSVC2022 (I added .bat files for them).

I looked into your project on issue #949, and indeed, it's too complex for a quick test. In particular I'm hesitating to download libs from other sources than the original ones (PNG, IIRC) and I don't want to install packages like 'nasm' on my test system(s) just for testing your project.

I'll look into it anyway but I'd rather use a simpler project if you could provide one that:

- downloads sources only from the original repos (see e.g. our documentation/src/bundled-libs.dox)
- does not need to install any packages like nasm
- uses the stock libjpeg rather than turbojpeg for simplicity and consistency with our build
- whatever else you can simplify.

I appreciate your testing and help, but please keep in mind: the easier your "simple" test projects are for devs, the faster you will likely get a solution.

That said, if I can look at a demo project and decide to use it in about half an hour or less and if it works (i.e. I can see the expected results), then I'll probably give it a try shortly, but if it takes longer to evaluate it - or I need to modify it for my needs - then I can't do it until I have a larger time frame available. Sorry to say that, but that is real life...

[Gonzalo Garramuño]

On 9/4/24 11:10, 'Albrecht Schlosser' via fltk.coredev wrote:
>
> There's nothing like "the same" regarding two libraries.

Agreed.

> Didn't you recently report that using an older FLTK 1.4 header mix
> with current 1.4 caused you problems, IIRC in this thread???
>

Guilty as charged.  But you cannot do anything against human stupidity
:D  Just look for:

find_package(JPEG)

if the system jpeg found is libturbo-jpeg, jpeg8 or jpeg6, it shouldn't
be FLTK's concern.

> I'll look into it anyway but I'd rather use a simpler project if you
> could provide one that:
>
> - downloads sources only from the original repos (see e.g. our
> documentation/src/bundled-libs.dox)

I honestly missed that.  I'll see if we can use the latest PNG as they
now compile it with CMake.

> - does not need to install any packages like nasm

That might be an issue for libturbo-jpeg.  Have to check.

> - uses the stock libjpeg rather than turbojpeg for simplicity and
> consistency with our build

That's difficult also, as, IIRC, libjpeg does not compile natively on
the latest MSVC.

> - whatever else you can simplify.

Probably not much, unfortunately.  You need to have a SuperBuild so that
all .lib files are installed in the install location.


--
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 4/9/24 18:55 Gonzalo Garramuño wrote:
> ...  Just look for:

>
> find_package(JPEG)
>
> if the system jpeg found is libturbo-jpeg, jpeg8 or jpeg6, it
> shouldn't be FLTK's concern.

Agreed.

> [...]

>> - uses the stock libjpeg rather than turbojpeg for simplicity and
>> consistency with our build
>
> That's difficult also, as, IIRC, libjpeg does not compile natively on
> the latest MSVC.

Sure? I'm not aware of any substantial changes in our bundled version of
libjpeg aside from symbol prefixing and maybe a few '#define's or small
mods to suppress compiler warnings. However, my personal builds are
still with VS2019, hence I can't tell if this changed in VS2022.

That said, we're using our own hand-crafted CMakeLists.txt for libjpeg
(as for all bundled libs), this may make a difference.

> You need to have a SuperBuild so that all .lib files are installed in
> the install location.

The superbuild is not a problem per se, as long as the rest looks
plausible. Thanks for updating the GitHub Issue!

[Gonzalo Garramuño]

On 4/9/2024 4:00 PM, 'Albrecht Schlosser' via fltk.coredev wrote:
>
> Sure? I'm not aware of any substantial changes in our bundled version of
> libjpeg aside from symbol prefixing and maybe a few '#define's or small
> mods to suppress compiler warnings. However, my personal builds are
> still with VS2019, hence I can't tell if this changed in VS2022.

Actually, it *does* compile, but it requires a Unix environment if you
want to set up the install location, as you have to run "configure
--prefix" and that's exactly what I need to do.

Anyway, I updated again the .zip file with the official JPEG9 (latest
from this year) in addition to libturbo-jpeg.  If you use the "runme.sh"
bash script, you can switch from one to the other. I also added a
variable to easily compile Release or Debug.  As I said, building JPEG9
requires a MSys64 environment.  libjpeg-turbo does not need that, just
cmake.

I only tested building statically, but I think I added the code for
shared builds (DLLs) too.

--
Gonzalo Garramuño
ggar...@gmail.com