Switching between build options (libpng).

[pvr...@btinternet.com]

I had a difficult problem recently. 

I have been using CMake to build FLTK for my own app. I had been switching between using -D FLTK_USE_SYSTEM_LIBPNG=ON and =OFF and settled on =ON in both Windows and Debian flows after various struggles getting a version of PNG that allowed my build. My app uses the system libpng to write a PNG file.

Yesterday I tried to install a third-party app which also uses FLTK. This uses .configure as its build flow. This build failed when linking looking for methods fltk_png.... I rebuilt and reinstalled FLTK with FLTK_USE_SYSTEM_LIBPNG=OFF and the third-part app built and installed OK. However my app now failed to find the methods png.... 

I reverted to =ON and tried to find what the other app was looking for. I eventually found that the the png* method calls were #defines (to the fltk_png* form) in a file in /usr/local/include/FL/images/. It seems that this got included in the build of the third-party app regardless of whether FLTK is build with or without SYSTEM_LIBPNG. 

I have a couple of questions.

1) How should I know whether to include the images/* file in my build if FLTK is not built with SYSTEM_LIBPNG? I am just using "find_package(FLTK CONFIG REQUIRED)" and that appears now to set the correct libraries and include directories for me. 

2) When I rebuild with ...SYSTEM_LIBPNG=ON, the directory /usr/local/include/FL/images is NOT removed. Should it? Or is there a deeper clean command I should have used between the two versions of build - other than "cmake --fresh -B build"?

By removing /usr/local/include/FL/images and building ...SYSTEM_LIBPNG=ON I was able to get both apps to build and install.

Regards Phil.

[Albrecht Schlosser]

I apologize for top-posting, but I can't imagine how I could add my comments next to your particular statements (which is not your fault, it's just because this problem is - as you wrote - difficult). Or maybe not, if you adhere to some "rules" of best practices.

1. First of all, it's not a good idea to have one version of FLTK "installed" in a default system location and trying to build an application using another build or install location, or maybe other combinations of different FLTK builds (maybe one for 1.3, and another one for 1.4). The general recommendation for using different FLTK builds is simple: never install any of these builds in default system locations to avoid such conflicts in the first place. If you build/install FLTK in non-system locations and use the full path for building your specific applications, then there should be no conflicts. I'm doing this all the time...

> When I rebuild with ...SYSTEM_LIBPNG=ON, the directory /usr/local/include/FL/images is NOT removed. Should it?

2. You're missing one very important point in this statement. You don't build directly in '/usr/local/include/FL/...', do you?

What you are missing is the install step in this process. But there is another option in FLTK's build system: uninstall. So, if you had executed the `uninstall` step (e.g. `make uninstall`) with the old/previous build settings (!), i.e. before you even reconfigure the build, then that would (or at least should) have removed all the previous build artifacts. However, just installing another build over the previous build location does not remove any old files, and it would not even know which files to remove. Therefore it can't remove any files in the 'FL/images' folder when you build and install w/o the bundled image libraries.

One aspect of `fltk-config` is that it tries to be smart and checks the existence of some files in or below the main install location. That's how it works. If there are files left from a previous install, then fltk-config will very likely make wrong decisions.

Note: fltk-config is no longer necessary and should not be used if you build FLTK (and your application) with CMake.


3. Since FLTK 1.4 we definitely recommend to

(a) build FLTK with CMake
(b) build FLTK applications with CMake as well, and
(c) use CMake's CONFIG (NO_MODULE) mode to find FLTK
(d) use "modern CMake" to build applications, i.e. to link to `fltk::fltk` etc. to benefit from CMake's knowledge of include and link directories rather than using CMake variables like FLTK_INCLUDE_DIRECTORIES or similar.

With all these recommendations above you don't use fltk-config at all, and this is way better and more reliable than to try to use `fltk-config`, particularly if it was installed in a system location. *IF* you want/need to use fltk-config for different FLTK builds nevertheless, then you should at least take care to use the full path of fltk-config to use the specific version of the build.


4. Last but not least: even with CMake's features to change build options there can be unexpected issues because CMake caches results of previous searches in its CMakeCache.txt of the build folder. Therefore it can be necessary to clean the entire CMake build folder to remove cached values (or at least to remove CMakeCache.txt).


I'm aware that you may not be able or want to follow all recommendations above, particularly if you have to use another build system for a particular application. However, not installing FLTK in default system locations and using the full path for `fltk-config` should improve the situation. This implies not to install FLTK packages from the Linux distro etc. if you need different FLTK versions on the same system because these packages will be installed in system locations.

I hope this helps. Somehow.

[pvr...@btinternet.com]

Thanks Albrecht

---

From: 'Albrecht Schlosser' via fltk.general <fltkg...@googlegroups.com>

Sent: Monday, December 1, 2025 5:10 PM

To: fltkg...@googlegroups.com <fltkg...@googlegroups.com>

Subject: Re: [fltk.general] Switching between build options (libpng).

 

I apologize for top-posting, but I can't imagine how I could add my comments next to your particular statements (which is not your fault, it's just because this problem is - as you wrote - difficult). Or maybe not, if you adhere to some "rules" of best practices.

Not a problem.

1. First of all, it's not a good idea to have one version of FLTK "installed" in a default system location and trying to build an application using another build or install location, or maybe other combinations of different FLTK builds (maybe one for 1.3, and another one for 1.4). The general recommendation for using different FLTK builds is simple: never install any of these builds in default system locations to avoid such conflicts in the first place. If you build/install FLTK in non-system locations and use the full path for building your specific applications, then there should be no conflicts. I'm doing this all the time...

That's one feature I've not really got to grips with. How to distinguish which particular install to use at any particular time?  Specifically, if I am compiling a third party application from source. That will usually rely on libraries like FLTK only having one version in a system, I assume.

> When I rebuild with ...SYSTEM_LIBPNG=ON, the directory /usr/local/include/FL/images is NOT removed. Should it?

2. You're missing one very important point in this statement. You don't build directly in '/usr/local/include/FL/...', do you?

I have been loose with occasionally using 'build' to include 'install'. 

What you are missing is the install step in this process. But there is another option in FLTK's build system: uninstall. So, if you had executed the `uninstall` step (e.g. `make uninstall`) with the old/previous build settings (!), i.e. before you even reconfigure the build, then that would (or at least should) have removed all the previous build artifacts. However, just installing another build over the previous build location does not remove any old files, and it would not even know which files to remove. Therefore it can't remove any files in the 'FL/images' folder when you build and install w/o the bundled image libraries.

This is the missing step, I think. I have built and installed FLTK using 'cmake --build ....' and 'cmake --install....'. I couldn't see any 'cmake --uninstall.....' documented anywhere. 

One aspect of `fltk-config` is that it tries to be smart and checks the existence of some files in or below the main install location. That's how it works. If there are files left from a previous install, then fltk-config will very likely make wrong decisions.

I understand and respect that now. It's the commands required to uninstall the previous installation that I was not able to find. 

Note: fltk-config is no longer necessary and should not be used if you build FLTK (and your application) with CMake.

3. Since FLTK 1.4 we definitely recommend to

(a) build FLTK with CMake

(b) build FLTK applications with CMake as well, and

(c) use CMake's CONFIG (NO_MODULE) mode to find FLTK

(d) use "modern CMake" to build applications, i.e. to link to `fltk::fltk` etc. to benefit from CMake's knowledge of include and link directories rather than using CMake variables like FLTK_INCLUDE_DIRECTORIES or similar.

The code for my application (in CMakeLists.txt) is:-

  set(CMAKE_MODULE_PATH ../ ./)

   find_package(FLTK CONFIG REQUIRED)

   if (FLTK_FOUND)

     message(STATUS "FLTK found: ${FLTK_VERSION}")

     message(STATUS "FLTK include dir: ${FLTK_INCLUDE_DIR}")

     message(STATUS "FLTK libraries: ${FLTK_LIBRARIES}")

   else()

     message(FATAL_ERROR "FLTK not found")

   endif()

As I am trying to keep this portable across a number of systems (W10, W11 and Debian) I do not want to add any file location information. I then used the CMake FLTK_* variables rather than hard coding a list of fltk::fltk etc. libraries.  

With all these recommendations above you don't use fltk-config at all, and this is way better and more reliable than to try to use `fltk-config`, particularly if it was installed in a system location. *IF* you want/need to use fltk-config for different FLTK builds nevertheless, then you should at least take care to use the full path of fltk-config to use the specific version of the build.

The problem I faced was that although I build and installed FLTK using CMake; built and installed MY application with CMake: the third party application had to be built using a flow with a .configure file.

4. Last but not least: even with CMake's features to change build options there can be unexpected issues because CMake caches results of previous searches in its CMakeCache.txt of the build folder. Therefore it can be necessary to clean the entire CMake build folder to remove cached values (or at least to remove CMakeCache.txt).

If I can get away with just removing CMakeCache.txt then I will try that, rather than removing the whole build tree. Thanks.

I'm aware that you may not be able or want to follow all recommendations above, particularly if you have to use another build system for a particular application. However, not installing FLTK in default system locations and using the full path for `fltk-config` should improve the situation. This implies not to install FLTK packages from the Linux distro etc. if you need different FLTK versions on the same system because these packages will be installed in system locations.

I hope this helps. Somehow.

Having more than one installation of FLTK was an option I was trying to avoid. As the third-party application requires a maximum version of 1.4 and I would like my development to proceed with 1.5 I don't think I have a choice.

On 11/30/25 21:01 'pvr...@btinternet.com' via fltk.general wrote:

I had a difficult problem recently. 

I have been using CMake to build FLTK for my own app. I had been switching between using -D FLTK_USE_SYSTEM_LIBPNG=ON and =OFF and settled on =ON in both Windows and Debian flows after various struggles getting a version of PNG that allowed my build. My app uses the system libpng to write a PNG file.

Yesterday I tried to install a third-party app which also uses FLTK. This uses .configure as its build flow. This build failed when linking looking for methods fltk_png.... I rebuilt and reinstalled FLTK with FLTK_USE_SYSTEM_LIBPNG=OFF and the third-part app built and installed OK. However my app now failed to find the methods png.... 

I reverted to =ON and tried to find what the other app was looking for. I eventually found that the the png* method calls were #defines (to the fltk_png* form) in a file in /usr/local/include/FL/images/. It seems that this got included in the build of the third-party app regardless of whether FLTK is build with or without SYSTEM_LIBPNG. 

I have a couple of questions.

1) How should I know whether to include the images/* file in my build if FLTK is not built with SYSTEM_LIBPNG? I am just using "find_package(FLTK CONFIG REQUIRED)" and that appears now to set the correct libraries and include directories for me. 

2) When I rebuild with ...SYSTEM_LIBPNG=ON, the directory /usr/local/include/FL/images is NOT removed. Should it? Or is there a deeper clean command I should have used between the two versions of build - other than "cmake --fresh -B build"?

By removing /usr/local/include/FL/images and building ...SYSTEM_LIBPNG=ON I was able to get both apps to build and install.

Regards Phil.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fltkgeneral/b87eee6a-bae7-4548-85f5-dfb5ea6822fc%40aljus.de.

[Ian MacArthur]

On Sunday, 30 November 2025 at 20:01:21 UTC Phil wrote:

I had a difficult problem recently. 

I have been using CMake to build FLTK for my own app. I had been switching between using -D FLTK_USE_SYSTEM_LIBPNG=ON and =OFF and settled on =ON in both Windows and Debian flows after various struggles getting a version of PNG that allowed my build. My app uses the system libpng to write a PNG file.

Phil,

This bit ("various struggles getting a version of PNG that allowed my build")  puzzled me a bit - what problems were you hitting?

I've been mixing and matching random versions of PNG for years and it has mostly Just Worked, the API (and ABI, maybe?) seems to have been pretty solid for a long time, so I was (am) puzzled about what _didn't_ work.

Further, in my experience, depending on "system PNG" on Windows rarely goes well in the long term, since there isn't really a "system PNG" on WinXX machines by default and eventually I always trip over a machine that does not have it installed...

[pvr...@btinternet.com]

---

From: fltkg...@googlegroups.com <fltkg...@googlegroups.com> on behalf of Ian MacArthur <imaca...@gmail.com>

Sent: Tuesday, December 2, 2025 10:40 AM

To: fltk.general <fltkg...@googlegroups.com>

Subject: [fltk.general] Re: Switching between build options (libpng).

 

The problem I hit was that my app has the feature to create and write out a PNG file. If I built using FLTK_USE_SYSTEM_LIBPNG=OFF, then when linking, it failed to find the methods png_..... So I built and installed FLTK with FLTK_USE_SYSTEM_LIBPNG=ON and my app then linked OK. So I had left it at that until I then encountered the problem in this conversation. 

While diagnosing the problem in this conversation, I found that the third-party app I was now building somehow included a file that was in /usr/local/include/FL/images that used #defines to map png_.... methods to their equivalent fltk_png_.... methods. What I haven't found in the documentation is how to include this file with the CMake build flow. So it is probably supposed to be hidden to the user and should just work. 

It may be that because I had tried to install one configuration on top of a previous one without properly uninstalling the first, my CMake build had got confused. I hadn't encountered the problem when I just used a Makefile which used the output of fltk-config. 

Phil.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/fltkgeneral/de653968-fc35-4c6a-9b64-acc6b42353a7n%40googlegroups.com.