1.4.4 build fails on OpenBSD

39 views
Skip to first unread message

wea...@gmail.com

unread,
Dec 10, 2025, 4:55:25 AM (7 days ago) Dec 10
to fltk.general
Hi all,

I tried to build FLTK 1.4.4 (from git) on OpenBSD, but it fails.
Here are the details:
OS: OpenBSD amd64
compiler: clang 19.1.7
cmake 3.31.8
I have installed fltk version 1.3.9

configuration:
cmake -DCMAKE_BUILD_TYPE=Debug -B build/debug
(configuration succeeds)
build output:
In file included from /home/iantal/programming/fltk/src/Fl.cxx:24:
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:94:40: error: no member named 'is_resizable' in 'Fl_Window'; did you mean 'resizable'?
   94 |   int is_resizable() { return pWindow->is_resizable(); }
      |                                        ^~~~~~~~~~~~
      |                                        resizable
/usr/local/include/FL/Fl_Group.H:152:14: note: 'resizable' declared here
  152 |   Fl_Widget* resizable() const {return resizable_;}
      |              ^
In file included from /home/iantal/programming/fltk/src/Fl.cxx:24:
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:94:31: error: cannot initialize return object of type 'int' with an rvalue of type 'Fl_Widget *'
   94 |   int is_resizable() { return pWindow->is_resizable(); }
      |                               ^~~~~~~~~~~~~~~~~~~~~~~
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:100:45: error: 'no_fullscreen_x' is a private member of 'Fl_Window'
  100 |   int* no_fullscreen_x() { return &pWindow->no_fullscreen_x; }
      |                                             ^
/usr/local/include/FL/Fl_Window.H:66:7: note: implicitly declared private here
   66 |   int no_fullscreen_x;
      |       ^
In file included from /home/iantal/programming/fltk/src/Fl.cxx:24:
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:101:45: error: 'no_fullscreen_y' is a private member of 'Fl_Window'
  101 |   int* no_fullscreen_y() { return &pWindow->no_fullscreen_y; }
      |                                             ^
/usr/local/include/FL/Fl_Window.H:70:7: note: implicitly declared private here
   70 |   int no_fullscreen_y;
      |       ^
In file included from /home/iantal/programming/fltk/src/Fl.cxx:24:
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:102:45: error: 'no_fullscreen_w' is a private member of 'Fl_Window'
  102 |   int* no_fullscreen_w() { return &pWindow->no_fullscreen_w; }
      |                                             ^
/usr/local/include/FL/Fl_Window.H:74:7: note: implicitly declared private here
   74 |   int no_fullscreen_w;
      |       ^
In file included from /home/iantal/programming/fltk/src/Fl.cxx:24:
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:103:45: error: 'no_fullscreen_h' is a private member of 'Fl_Window'
  103 |   int* no_fullscreen_h() { return &pWindow->no_fullscreen_h; }
      |                                             ^
/usr/local/include/FL/Fl_Window.H:78:7: note: implicitly declared private here
   78 |   int no_fullscreen_h;
      |       ^
In file included from /home/iantal/programming/fltk/src/Fl.cxx:24:
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:109:42: error: no member named 'show_next_window_iconic' in 'Fl_Window'
  109 |   char show_iconic() { return Fl_Window::show_next_window_iconic(); }
      |                               ~~~~~~~~~~~^
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:110:41: error: no type named 'show_next_window_iconic' in 'Fl_Window'
  110 |   void show_iconic(char c) { Fl_Window::show_next_window_iconic(c); }
      |                              ~~~~~~~~~~~^
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:111:32: error: no member named 'flx_' in 'Fl_Window'
  111 |   void flx(Fl_X *x) { pWindow->flx_ = x; }
      |                       ~~~~~~~  ^
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:112:48: error: 'cursor_default' is a private member of 'Fl_Window'
  112 |   Fl_Cursor cursor_default() { return pWindow->cursor_default; }
      |                                                ^
/usr/local/include/FL/Fl_Window.H:117:13: note: implicitly declared private here
  117 |   Fl_Cursor cursor_default;
      |             ^
In file included from /home/iantal/programming/fltk/src/Fl.cxx:24:
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:116:21: error: no member named 'as_overlay_window' in 'Fl_Window'
  116 |     return pWindow->as_overlay_window() ? pWindow->as_overlay_window()->overlay_ : NULL;
      |            ~~~~~~~  ^
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:116:52: error: no member named 'as_overlay_window' in 'Fl_Window'
  116 |     return pWindow->as_overlay_window() ? pWindow->as_overlay_window()->overlay_ : NULL;
      |                                           ~~~~~~~  ^
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:120:18: error: no member named 'as_overlay_window' in 'Fl_Window'
  120 |     if (pWindow->as_overlay_window()) pWindow->as_overlay_window()->overlay_ = o;
      |         ~~~~~~~  ^
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:120:48: error: no member named 'as_overlay_window' in 'Fl_Window'
  120 |     if (pWindow->as_overlay_window()) pWindow->as_overlay_window()->overlay_ = o;
      |                                       ~~~~~~~  ^
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:124:38: error: 'set_flag' is a protected member of 'Fl_Widget'
  124 |   void set_popup_window() { pWindow->set_flag(Fl_Window::POPUP); }
      |                                      ^
/usr/local/include/FL/Fl_Widget.H:149:8: note: declared protected here
  149 |   void set_flag(unsigned int c) {flags_ |= c;}
      |        ^
In file included from /home/iantal/programming/fltk/src/Fl.cxx:24:
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:124:58: error: no member named 'POPUP' in 'Fl_Window'
  124 |   void set_popup_window() { pWindow->set_flag(Fl_Window::POPUP); }
      |                                               ~~~~~~~~~~~^
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:125:46: error: 'flags' is a protected member of 'Fl_Widget'
  125 |   bool popup_window() const {return pWindow->flags() & Fl_Window::POPUP;}
      |                                              ^
/usr/local/include/FL/Fl_Widget.H:147:16: note: declared protected here
  147 |   unsigned int flags() const {return flags_;}
      |                ^
In file included from /home/iantal/programming/fltk/src/Fl.cxx:24:
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:125:67: error: no member named 'POPUP' in 'Fl_Window'
  125 |   bool popup_window() const {return pWindow->flags() & Fl_Window::POPUP;}
      |                                                        ~~~~~~~~~~~^
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:159:40: error: no member named 'is_maximized_' in 'Fl_Window'
  159 |   void is_maximized(bool b) { pWindow->is_maximized_(b); }
      |                               ~~~~~~~  ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
*** Error 1 in . (src/CMakeFiles/fltk.dir/build.make:79 'src/CMakeFiles/fltk.dir/Fl.cxx.o': cd /home/iantal/programming/fltk/build/debug/src...)
*** Error 2 in . (CMakeFiles/Makefile2:524 'src/CMakeFiles/fltk.dir/all': make -s -f src/CMakeFiles/fltk.dir/build.make src/CMakeFiles/fltk....)
*** Error 2 in /home/iantal/programming/fltk/build/debug (Makefile:136 'all': make -s -f CMakeFiles/Makefile2 all)

============================
If you look at it, the source of the problem is that the compilation uses includes from the installed fltk: /usr/local/include/FL.
I guess the build system is not prepared for this case. Do you have a workaround or solution for this? 

Regards,
Antal

Manolo

unread,
Dec 10, 2025, 6:33:14 AM (6 days ago) Dec 10
to fltk.general
I have built here with CMake under Ubuntu FLTK 1.4 current from git in presence of an installed FLTK 1.3.11
and encountered no problem.


Ian MacArthur

unread,
Dec 10, 2025, 7:29:05 AM (6 days ago) Dec 10
to fltk.general
On Wednesday, 10 December 2025 at 09:55:25 UTC Antal wrote:
 
I tried to build FLTK 1.4.4 (from git) on OpenBSD, but it fails.
Here are the details:
OS: OpenBSD amd64
compiler: clang 19.1.7
cmake 3.31.8
I have installed fltk version 1.3.9
============================
If you look at it, the source of the problem is that the compilation uses includes from the installed fltk: /usr/local/include/FL.
I guess the build system is not prepared for this case. Do you have a workaround or solution for this? 


Hi Antal,

Hmm - how did you manage that, I wonder? 

I have _many_ versions of FLTK in "working" folders (from 1.3.x to 1.5.x in various 32 and 64-bit forms and so on), along with something truly ancient (1.3.4-1) installed and they all seem to be happy and build just fine.
I don't have any BSD system I can test on however - does BSD do something weird with include paths perhaps? Does anyone know?

 

wea...@gmail.com

unread,
Dec 10, 2025, 7:56:51 AM (6 days ago) Dec 10
to fltk.general
I don't have any BSD system I can test on however - does BSD do something weird with include paths perhaps? Does anyone know?

I put cmake in trace mode in both Linux and OpenBSD. On my Linux system the FLTK includes are installed under: /usr/include , on OpenBSD /usr/local/include.
On Linux the /usr/include does not seem to be added to the list of includes, but on OpenBSD /usr/local/include is added. I think the responsible CMake variable is CMAKE_SYSTEM_INCLUDE_PATH. 
In case of Linux the UnixPaths.cmake is called, on OpenBSD an OpenBSD specific one is used. It seems that the OpenBSD specific cmake is different in cmake 4.1 (Linux) and 3.31 (OpenBSD). I guess I'll just remove the installed version. It may not b worth further investigation. 
 

Albrecht Schlosser

unread,
Dec 10, 2025, 8:11:48 AM (6 days ago) Dec 10
to fltkg...@googlegroups.com
On 12/10/25 10:55 wea...@gmail.com wrote:
 tried to build FLTK 1.4.4 (from git) on OpenBSD, but it fails.
Here are the details:
OS: OpenBSD amd64
compiler: clang 19.1.7
cmake 3.31.8
I have installed fltk version 1.3.9

Was this FLTK version installed by the OpenBSD package system, or did you build and install it yourself? I'm asking because your log shows that it's installed in /usr/local which is IMHO unusual, but I don't know if this is "normal" on OpenBSD?



configuration:
cmake -DCMAKE_BUILD_TYPE=Debug -B build/debug
(configuration succeeds)
build output:
In file included from /home/iantal/programming/fltk/src/Fl.cxx:24:
/home/iantal/programming/fltk/src/Fl_Window_Driver.H:94:40: error: no member named 'is_resizable' in 'Fl_Window'; did you mean 'resizable'?
   94 |   int is_resizable() { return pWindow->is_resizable(); }
      |                                        ^~~~~~~~~~~~
      |                                        resizable
/usr/local/include/FL/Fl_Group.H:152:14: note: 'resizable' declared here
  152 |   Fl_Widget* resizable() const {return resizable_;}
      |              ^

[more similar messages elided]


============================
If you look at it, the source of the problem is that the compilation uses includes from the installed fltk: /usr/local/include/FL.

I see. That should never happen, the build of FLTK should NOT look at installed FLTK headers at all.


I guess the build system is not prepared for this case. Do you have a workaround or solution for this?

There's no known workaround because it shouldn't happen at all. We need to investigate why this happens on your system. Let's do some tests.

First of all, make sure that you prepare the CMake build in an empty folder (in your case it was `build/debug` relative to the source dir which is fine (but please try again after removing this folder).

Please post output of the entire confuguration process here.

Please execute `echo $PATH` so we can see if there's anything unusual. I have only

/usr/local/sbin
/usr/local/bin


from `/usr/local`.

[ Just now I read your new message, containing "It may not be worth further investigation." I'd like to see the output of the build system anyway. ]

If it's true that `/usr/local/include` is included in the compiler command *before* the FLTK source folder, then there is a problem. To see this for sure, please run the build with CMake. You can do this from the source folder like this:

Step 1: execute `cmake --build build/debug` and let it run until it finishes (may be a parallel build)
Step 2: execute `cmake --build build/debug -j 1` and let it run until it finishes. This ensures that the next step errors out in the first compilation process
Step 3: execute `cmake --build build/debug -j 1 -v`. This should output the commandline and error messages of the first and only compilation

I need to see this full output, please copy and paste it to a new message.

I don't have an OpenBSD system available, but I do have a FreeBSD system which I can use for further tests, but it's important to see what's going on on your system. Thanks

Albrecht Schlosser

unread,
Dec 10, 2025, 8:23:09 AM (6 days ago) Dec 10
to fltkg...@googlegroups.com
On 12/10/25 13:56 wea...@gmail.com wrote:
I don't have any BSD system I can test on however - does BSD do something weird with include paths perhaps? Does anyone know?

I put cmake in trace mode in both Linux and OpenBSD. On my Linux system the FLTK includes are installed under: /usr/include , on OpenBSD /usr/local/include.
On Linux the /usr/include does not seem to be added to the list of includes, but on OpenBSD /usr/local/include is added. I think the responsible CMake variable is CMAKE_SYSTEM_INCLUDE_PATH.

Can you check the value of CMAKE_SYSTEM_INCLUDE_PATH in both setups, i.e. Linux and OpenBSD, and post it here? Please tell us which version is from which system and CMake version.

A simple way to see if it's in the cache is (in the build folder):

$ cmake -LAH . | grep CMAKE_SYSTEM_INCLUDE_PATH

or

$ grep CMAKE_SYSTEM_INCLUDE_PATH CMakeCache.txt

IMHO it shouldn't be in the cache, and this is what I see on my Linux system (empty output or only empty lines).


In case of Linux the UnixPaths.cmake is called, on OpenBSD an OpenBSD specific one is used. It seems that the OpenBSD specific cmake is different in cmake 4.1 (Linux) and 3.31 (OpenBSD).

Which `UnixPaths.cmake` ? Where is it located?


I guess I'll just remove the installed version. It may not b worth further investigation.

It may resolve your problem, but I'd like to find out why this happens and how it can be prevented. I'm sure you're not the only FLTK user on OpenBSD.


Albrecht Schlosser

unread,
Dec 10, 2025, 8:42:11 AM (6 days ago) Dec 10
to fltkg...@googlegroups.com
I would also like to know where your CMake program is installed on
OpenBSD. Is it also in /usr/local ?

Please post the output of `which cmake` and/or `type cmake` or find
where it is installed.

wea...@gmail.com

unread,
Dec 11, 2025, 12:39:30 AM (6 days ago) Dec 11
to fltk.general
Ok, first here are the details from my OpenBSD system.
I installed FLTK 1.3.9 with the package manager, and it is installed under "/usr/local/".
cmake is installed under /usr/loca/bin, also this is installed with the package manager.
=== version ===========
$ cmake -version
cmake version 3.31.8
=====cmake module path=====
/usr/local/share/cmake/Modules/Platform/UnixPaths.cmake
========= PATH ======
$ echo $PATH
/home/iantal/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin
===================CMake configuration=======================================
here is the cmake configuration process with an empty build folder:
$ cmake -S . -B build/debug -DCMAKE_BUILD_TYPE=Debug
-- The C compiler identification is Clang 19.1.7
-- The CXX compiler identification is Clang 19.1.7
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of short
-- Check size of short - done
-- Check size of int
-- Check size of int - done
-- Check size of long
-- Check size of long - done
-- Check size of long long
-- Check size of long long - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "2.4.3")
-- Looking for POSIX compatible scandir
-- POSIX compatible scandir - found
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Found ZLIB: /usr/lib/libz.so.7.1 (found version "1.3.1.1")
-- Found PNG: /usr/local/lib/libpng.so.18.2 (found version "1.6.52")
-- Looking for png.h
-- Looking for png.h - found
-- Found JPEG: /usr/local/lib/libjpeg.so.71.0 (found version "62")
-- Checking for module 'wayland-client>=1.18'
--   Found wayland-client, version 1.24.0
-- Checking for module 'wayland-cursor'
--   Found wayland-cursor, version 1.24.0
-- Checking for module 'wayland-protocols>=1.15'
--   Package 'wayland-protocols' not found
-- Checking for module 'xkbcommon'
--   Found xkbcommon, version 1.13.1
-- Not all software modules 'wayland-client>=1.18 wayland-cursor wayland-protocols>=1.15 xkbcommon' are present
-- Consequently, FLTK_BACKEND_WAYLAND is turned off.
-- Found X11: /usr/X11R6/include
-- Looking for XOpenDisplay in /usr/X11R6/lib/libX11.so.19.0;/usr/X11R6/lib/libXext.so.13.0
-- Looking for XOpenDisplay in /usr/X11R6/lib/libX11.so.19.0;/usr/X11R6/lib/libXext.so.13.0 - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Looking for glXGetProcAddressARB
-- Looking for glXGetProcAddressARB - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Configuration Summary for FLTK 1.4.4 generated by CMake 3.31.8 --

-- The following OPTIONAL packages have been found:

 * ZLIB
 * PNG
 * JPEG

-- The following OPTIONAL packages have not been found:

 * Doxygen

-- Static libraries    will be built in: /home/iantal/programming/fltk/build/debug/lib
-- Shared libraries    will not be built (set FLTK_BUILD_SHARED_LIBS=ON to build)
-- The forms library   will be built in: /home/iantal/programming/fltk/build/debug/lib
-- The OpenGL library  will be built in: /home/iantal/programming/fltk/build/debug/lib
-- fluid               will be built in: /home/iantal/programming/fltk/build/debug/bin
-- fltk-options        will be built in: /home/iantal/programming/fltk/build/debug/bin
-- Test programs       will be built in: /home/iantal/programming/fltk/build/debug/bin/test
-- Example programs    will not be built (set FLTK_BUILD_EXAMPLES=ON to build)
--
-- Build configuration      Debug
-- Installation prefix      /usr/local
-- Bundled Libraries        JPEG     = System: /usr/local/lib/libjpeg.so.71.0
--                          PNG      = System: /usr/local/lib/libpng.so.18.2
--                          ZLIB     = System: /usr/lib/libz.so.7.1
-- Use Wayland              No (X11 is used)
-- All drawing uses Cairo   No
-- Use Pango                No
-- Use Xft                  Yes
-- Fl_Cairo_Window support  No
-- Use std::                No
-- End of Configuration Summary --

-- Configuring done (12.9s)
-- Generating done (1.2s)
-- Build files have been written to: /home/iantal/programming/fltk/build/debug

======= CMAKE_SYSTEM_INCLUDE_PATH======
I executed cmake -LAH | grep ... in build/debug and I found that CMAKE_SYSTEM_INCLUDE_PATH is not found. Not in CMakeCache.txt as well.
I may have been off track with CMAKE_SYSTEM_INCLUDE_PATH, maybe this is not the key, but I saw this in the trace while configuring the build with cmake
/usr/local/share/cmake/Modules/Platform/OpenBSD.cmake(32):  if($ENV{LOCALBASE} )
/usr/local/share/cmake/Modules/Platform/OpenBSD.cmake(34):  else()
/usr/local/share/cmake/Modules/Platform/OpenBSD.cmake(35):  set(OPENBSD_LOCALBASE /usr/local )
/usr/local/share/cmake/Modules/Platform/OpenBSD.cmake(37):  if($ENV{X11BASE} )
/usr/local/share/cmake/Modules/Platform/OpenBSD.cmake(39):  else()
/usr/local/share/cmake/Modules/Platform/OpenBSD.cmake(40):  set(OPENBSD_X11BASE /usr/X11R6 )
/usr/local/share/cmake/Modules/Platform/OpenBSD.cmake(43):  list(APPEND CMAKE_SYSTEM_PREFIX_PATH ${OPENBSD_LOCALBASE} )

=========== cmake build Step 1=============
=== std out ===
[ 0%] Building CXX object src/CMakeFiles/fltk.dir/Fl.cxx.o
=== std err ===
*** Error 2 in . (CMakeFiles/Makefile2:524 'src/CMakeFiles/fltk.dir/all': /usr/bin/make -s -f src/CMakeFiles/fltk.dir/build.make src/CMakeFi...)
*** Error 2 in /home/iantal/programming/fltk/build/debug (Makefile:136 'all': /usr/bin/make -s -f CMakeFiles/Makefile2 all)

==== cmake build Step 2 ====
=== std out ===
[  0%] Building CXX object src/CMakeFiles/fltk.dir/drivers/PostScript/Fl_PostScript_image.cxx.o
=== std err ===
In file included from /home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:21:
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_Graphics_Driver.H:92:7: error: redefinition of 'Fl_PostScript_Graphics_Driver'
   92 | class Fl_PostScript_Graphics_Driver : public Fl_Graphics_Driver {
      |       ^
/usr/local/include/FL/Fl_PostScript.H:61:17: note: previous definition is here
   61 | class FL_EXPORT Fl_PostScript_Graphics_Driver : public Fl_Graphics_Driver {
      |                 ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:693:37: error: out-of-line definition of 'draw_pixmap' does not match any declaration in 'Fl_PostScript_Graphics_Driver'
  693 | void Fl_PostScript_Graphics_Driver::draw_pixmap(Fl_Pixmap * pxm,int XP, int YP, int WP, int HP, int cx, int cy){
      |                                     ^~~~~~~~~~~
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:694:7: error: use of undeclared identifier 'scale_for_image_'
  694 |   if (scale_for_image_(pxm, XP, YP, WP, HP, cx, cy)) return;
      |       ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:708:37: error: out-of-line definition of 'draw_rgb' does not match any declaration in 'Fl_PostScript_Graphics_Driver'
  708 | void Fl_PostScript_Graphics_Driver::draw_rgb(Fl_RGB_Image * rgb,int XP, int YP, int WP, int HP, int cx, int cy)
      |                                     ^~~~~~~~
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:710:7: error: use of undeclared identifier 'scale_for_image_'
  710 |   if (scale_for_image_(rgb, XP, YP, WP, HP, cx, cy)) return;
      |       ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:712:16: error: no member named 'data_w' in 'Fl_RGB_Image'
  712 |   int w = rgb->data_w();
      |           ~~~  ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:713:16: error: no member named 'data_h' in 'Fl_RGB_Image'
  713 |   int h = rgb->data_h();
      |           ~~~  ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:724:37: error: out-of-line definition of 'draw_bitmap' does not match any declaration in 'Fl_PostScript_Graphics_Driver'
  724 | void Fl_PostScript_Graphics_Driver::draw_bitmap(Fl_Bitmap * bitmap,int XP, int YP, int WP, int HP, int cx, int cy) {
      |                                     ^~~~~~~~~~~
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:725:7: error: use of undeclared identifier 'scale_for_image_'
  725 |   if (scale_for_image_(bitmap, XP, YP, WP, HP, cx, cy)) return;
      |       ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:726:16: error: no member named 'data_w' in 'Fl_Bitmap'
  726 |   WP = bitmap->data_w(), HP = bitmap->data_h();
      |        ~~~~~~  ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:726:39: error: no member named 'data_h' in 'Fl_Bitmap'
  726 |   WP = bitmap->data_w(), HP = bitmap->data_h();
      |                               ~~~~~~  ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:742:36: error: out-of-line definition of 'scale_for_image_' does not match any declaration in 'Fl_PostScript_Graphics_Driver'
  742 | int Fl_PostScript_Graphics_Driver::scale_for_image_(Fl_Image *img, int XP, int YP, int WP, int HP, int cx,int cy) {
      |                                    ^~~~~~~~~~~~~~~~
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:744:27: error: no member named 'start_image' in 'Fl_Graphics_Driver'
  744 |   if (Fl_Graphics_Driver::start_image(img, XP, YP, WP, HP, cx, cy, X, Y, W, H)) {
      |       ~~~~~~~~~~~~~~~~~~~~^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:749:81: error: no member named 'data_w' in 'Fl_Image'
  749 |   clocale_printf("GS %d %d TR  %f %f SC GS\n", X-cx, Y-cy, float(img->w())/img->data_w(), float(img->h())/img->data_h());
      |                                                                            ~~~  ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:749:112: error: no member named 'data_h' in 'Fl_Image'
  749 |   clocale_printf("GS %d %d TR  %f %f SC GS\n", X-cx, Y-cy, float(img->w())/img->data_w(), float(img->h())/img->data_h());
      |                                                                                                           ~~~  ^
15 errors generated.
*** Error 1 in . (src/CMakeFiles/fltk.dir/build.make:2725 'src/CMakeFiles/fltk.dir/drivers/PostScript/Fl_PostScript_image.cxx.o': cd /home/i...)
*** Error 2 in . (CMakeFiles/Makefile2:524 'src/CMakeFiles/fltk.dir/all': /usr/bin/make -s -f src/CMakeFiles/fltk.dir/build.make src/CMakeFi...)
*** Error 2 in /home/iantal/programming/fltk/build/debug (Makefile:136 'all': /usr/bin/make -s -f CMakeFiles/Makefile2 all)
=== cmake build Step 3 ===
=== std out===
Change Dir: '/home/iantal/programming/fltk/build/debug'

Run Build Command(s): /usr/local/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile -j1
/usr/local/bin/cmake -S/home/iantal/programming/fltk -B/home/iantal/programming/fltk/build/debug --check-build-system CMakeFiles/Makefile.cmake 0
/usr/local/bin/cmake -E cmake_progress_start /home/iantal/programming/fltk/build/debug/CMakeFiles /home/iantal/programming/fltk/build/debug//CMakeFiles/progress.marks
/usr/bin/make  -f CMakeFiles/Makefile2 all
/usr/bin/make  -f src/CMakeFiles/fltk.dir/build.make src/CMakeFiles/fltk.dir/depend
cd /home/iantal/programming/fltk/build/debug && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /home/iantal/programming/fltk /home/iantal/programming/fltk/src /home/iantal/programming/fltk/build/debug /home/iantal/programming/fltk/build/debug/src /home/iantal/programming/fltk/build/debug/src/CMakeFiles/fltk.dir/DependInfo.cmake "--color="
Dependencies file "src/CMakeFiles/fltk.dir/drivers/PostScript/Fl_PostScript_image.cxx.o.d" is newer than depends file "/home/iantal/programming/fltk/build/debug/src/CMakeFiles/fltk.dir/compiler_depend.internal".
Consolidate compiler generated dependencies of target fltk
/usr/bin/make  -f src/CMakeFiles/fltk.dir/build.make src/CMakeFiles/fltk.dir/build
[  0%] Building CXX object src/CMakeFiles/fltk.dir/drivers/PostScript/Fl_PostScript_image.cxx.o
cd /home/iantal/programming/fltk/build/debug/src && /usr/bin/c++ -DFL_LIBRARY -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/usr/local/include -I/home/iantal/programming/fltk/build/debug/src/.. -I/home/iantal/programming/fltk/src/.. -I/usr/X11R6/include/freetype2 -I/usr/X11R6/include -g   -D_THREAD_SAFE -D_REENTRANT -MD -MT src/CMakeFiles/fltk.dir/drivers/PostScript/Fl_PostScript_image.cxx.o -MF CMakeFiles/fltk.dir/drivers/PostScript/Fl_PostScript_image.cxx.o.d -o CMakeFiles/fltk.dir/drivers/PostScript/Fl_PostScript_image.cxx.o -c /home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx

===std err===
In file included from /home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:21:
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_Graphics_Driver.H:92:7: error: redefinition of 'Fl_PostScript_Graphics_Driver'
   92 | class Fl_PostScript_Graphics_Driver : public Fl_Graphics_Driver {
      |       ^
/usr/local/include/FL/Fl_PostScript.H:61:17: note: previous definition is here
   61 | class FL_EXPORT Fl_PostScript_Graphics_Driver : public Fl_Graphics_Driver {
      |                 ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:693:37: error: out-of-line definition of 'draw_pixmap' does not match any declaration in 'Fl_PostScript_Graphics_Driver'
  693 | void Fl_PostScript_Graphics_Driver::draw_pixmap(Fl_Pixmap * pxm,int XP, int YP, int WP, int HP, int cx, int cy){
      |                                     ^~~~~~~~~~~
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:694:7: error: use of undeclared identifier 'scale_for_image_'
  694 |   if (scale_for_image_(pxm, XP, YP, WP, HP, cx, cy)) return;
      |       ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:708:37: error: out-of-line definition of 'draw_rgb' does not match any declaration in 'Fl_PostScript_Graphics_Driver'
  708 | void Fl_PostScript_Graphics_Driver::draw_rgb(Fl_RGB_Image * rgb,int XP, int YP, int WP, int HP, int cx, int cy)
      |                                     ^~~~~~~~
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:710:7: error: use of undeclared identifier 'scale_for_image_'
  710 |   if (scale_for_image_(rgb, XP, YP, WP, HP, cx, cy)) return;
      |       ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:712:16: error: no member named 'data_w' in 'Fl_RGB_Image'
  712 |   int w = rgb->data_w();
      |           ~~~  ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:713:16: error: no member named 'data_h' in 'Fl_RGB_Image'
  713 |   int h = rgb->data_h();
      |           ~~~  ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:724:37: error: out-of-line definition of 'draw_bitmap' does not match any declaration in 'Fl_PostScript_Graphics_Driver'
  724 | void Fl_PostScript_Graphics_Driver::draw_bitmap(Fl_Bitmap * bitmap,int XP, int YP, int WP, int HP, int cx, int cy) {
      |                                     ^~~~~~~~~~~
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:725:7: error: use of undeclared identifier 'scale_for_image_'
  725 |   if (scale_for_image_(bitmap, XP, YP, WP, HP, cx, cy)) return;
      |       ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:726:16: error: no member named 'data_w' in 'Fl_Bitmap'
  726 |   WP = bitmap->data_w(), HP = bitmap->data_h();
      |        ~~~~~~  ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:726:39: error: no member named 'data_h' in 'Fl_Bitmap'
  726 |   WP = bitmap->data_w(), HP = bitmap->data_h();
      |                               ~~~~~~  ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:742:36: error: out-of-line definition of 'scale_for_image_' does not match any declaration in 'Fl_PostScript_Graphics_Driver'
  742 | int Fl_PostScript_Graphics_Driver::scale_for_image_(Fl_Image *img, int XP, int YP, int WP, int HP, int cx,int cy) {
      |                                    ^~~~~~~~~~~~~~~~
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:744:27: error: no member named 'start_image' in 'Fl_Graphics_Driver'
  744 |   if (Fl_Graphics_Driver::start_image(img, XP, YP, WP, HP, cx, cy, X, Y, W, H)) {
      |       ~~~~~~~~~~~~~~~~~~~~^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:749:81: error: no member named 'data_w' in 'Fl_Image'
  749 |   clocale_printf("GS %d %d TR  %f %f SC GS\n", X-cx, Y-cy, float(img->w())/img->data_w(), float(img->h())/img->data_h());
      |                                                                            ~~~  ^
/home/iantal/programming/fltk/src/drivers/PostScript/Fl_PostScript_image.cxx:749:112: error: no member named 'data_h' in 'Fl_Image'
  749 |   clocale_printf("GS %d %d TR  %f %f SC GS\n", X-cx, Y-cy, float(img->w())/img->data_w(), float(img->h())/img->data_h());
      |                                                                                                           ~~~  ^
15 errors generated.
*** Error 1 in . (src/CMakeFiles/fltk.dir/build.make:2725 'src/CMakeFiles/fltk.dir/drivers/PostScript/Fl_PostScript_image.cxx.o')
*** Error 2 in . (CMakeFiles/Makefile2:524 'src/CMakeFiles/fltk.dir/all')
*** Error 2 in /home/iantal/programming/fltk/build/debug (Makefile:136 'all')

Manolo

unread,
Dec 11, 2025, 5:33:11 AM (6 days ago) Dec 11
to fltk.general
I can use here FreeBSD in a VM which, as OpenBSD, tends to put installed packages in /usr/local.
I see as reported for OpenBSD:
- FLTK branch-1.4 from git builds OK if no FLTK version is installed.
- Building fails if FreeBSD's FLTK package (1.3.10) is installed.
- The cause of the failure is that the building procedure includes FLTK header files from /usr/local/include/FL/
which contains 1.3 stuff conflicting with 1.4

@Albrecht:  I don't understand why FLTK+CMake does this poor job under Unix whereas it builds correctly under Linux. 
I can test things under FreeBSD if you ask.

@OP: Your logs show that CMake refrains from building FLTK for Wayland because package wayland-protocols
is not found in your system. Adding this package (named "wayland-protocols" at least under FreeBSD)
would fix that. Resulting FLTK-based apps would be ready to run either as X11 clients or as Wayland clients without any change.

wea...@gmail.com

unread,
Dec 11, 2025, 6:20:04 AM (5 days ago) Dec 11
to fltk.general
I made progress. It is a workaround. Honestly, I asked chatgpt and here is the answer that solved my problem:
"CMakeLists uses #include <FL/...> but doesn’t set target_include_directories(... BEFORE)
Meaning system paths win."
...
the solution:
"cmake -DCMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE=ON .."

wea...@gmail.com

unread,
Dec 11, 2025, 8:09:35 AM (5 days ago) Dec 11
to fltk.general
I found something interesting: if I disable using system JPEG and PNG compilation works fine. In this case the bundled jpeg, png and zlib (automagically) libraries are used. Probably these libraries pulled in the /usr/local/include. I'll check what happens on Linux for comparison.

Albrecht Schlosser

unread,
Dec 11, 2025, 11:06:31 AM (5 days ago) Dec 11
to fltkg...@googlegroups.com
On 12/11/25 11:33 Manolo wrote:
> I can use here FreeBSD in a VM which, as OpenBSD, tends to put
> installed packages in /usr/local.
> I see as reported for OpenBSD:
> - FLTK branch-1.4 from git builds OK if no FLTK version is installed.
> - Building fails if FreeBSD's FLTK package (1.3.10) is installed.
> - The cause of the failure is that the building procedure includes
> FLTK header files from /usr/local/include/FL/
> which contains 1.3 stuff conflicting with 1.4
>
> @Albrecht:  I don't understand why FLTK+CMake does this poor job under
> Unix whereas it builds correctly under Linux.

I'm guessing:
Maybe because under OpenBSD the installation path of libraries is in
/usr/local which is (usually) not the case, and (again maybe) one of the
CMake files on OpenBSD triggers inclusion of /usr/local/include before
the other libraries. As the OP (weanti) wrote in a later message, a
specific CMake variable can prevent this. But anyway, I wonder why this
happens in the first place.

We can - again maybe - set this variable in the FLTK CMake files, but
this needs investigation. I don't want to fix one build and break other
builds. Maybe we should just document this.

Unfortunately the documentation about
`CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE` is pretty sparse. It doesn't
tell why (i.e. in which cases) this is needed. Well, it's obvious in
this case, but why does it happen here and not elsewhere?

> I can test things under FreeBSD if you ask.

That would be great, thanks for the offer. I have an older FreeBSD VM
but I'm not very familiar with this OS. It would likely take some time
for me to get it up and running again, so yes, I'd appreciate your help.
TIA.

I'll try to investigate further, checking my CMake book, etc.. Maybe
this can give some insights...

Albrecht Schlosser

unread,
Dec 11, 2025, 11:17:00 AM (5 days ago) Dec 11
to fltkg...@googlegroups.com
Awesome !

Yes, sometimes AI systems can find answers where you would otherwise need a long time to find the proper place. Whether the answer is useful or not, that's another point.

In this case it's at least - as you say - a workaround.

I'll investigate further, see also my reply to Manolo's post. In general I wonder why the default (absence of this variable) is to put system paths before specific project directories at all. This seems to be wrong, but maybe it has some use cases. I'm particularly interested when (in which CMake version [1] ) and why (to fix what?) this variable has been introduced. And why the default is not `ON` (backwards compatibility only?).

[1] AI answer: CMake 3.11. I'll check the release notes...

Albrecht Schlosser

unread,
Dec 12, 2025, 1:36:51 PM (4 days ago) Dec 12
to fltkg...@googlegroups.com
On 12/11/25 17:06 'Albrecht Schlosser' wrote:
On 12/11/25 11:33 Manolo wrote:
I can use here FreeBSD in a VM which, as OpenBSD, tends to put installed packages in /usr/local.
I see as reported for OpenBSD:
- FLTK branch-1.4 from git builds OK if no FLTK version is installed.
- Building fails if FreeBSD's FLTK package (1.3.10) is installed.
- The cause of the failure is that the building procedure includes FLTK header files from /usr/local/include/FL/
which contains 1.3 stuff conflicting with 1.4

@Albrecht:  I don't understand why FLTK+CMake does this poor job under Unix whereas it builds correctly under Linux.


[...]


I can test things under FreeBSD if you ask.

That would be great, thanks for the offer. I have an older FreeBSD VM but I'm not very familiar with this OS. It would likely take some time for me to get it up and running again, so yes, I'd appreciate your help. TIA. 

I got my FreeBSD VM up and running (and upgraded to current packages).

I can confirm the issue on FreeBSD:

1. Build works as expected if no system FLTK package is installed
2. Build breaks as soon as FLTK is installed (`pkg install fltk-1.3.10`)
3. `cmake -DCMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE=ON` fixes the build.

I'm now looking further into the details, i.e. whether we can use other CMake means to avoid this issue in the first place.


I'll try to investigate further, checking my CMake book, etc.. Maybe this can give some insights... 

Unfortunately my book didn't help but I found some online references. Digging deeper ...

wea...@gmail.com

unread,
Dec 12, 2025, 6:04:20 PM (4 days ago) Dec 12
to fltk.general


Unfortunately my book didn't help but I found some online references. Digging deeper ...

Hi all,
since I'm lazy and don't really like reading long boring docs  I skipped reading the whole damn cmake documentation, so I debugged cmake code. I did some debugging and I *may* have some clues:
* on OpenBSD the /usr/local/include is added to the include list because of system libpng and libjpeg
* based on the code (cmake 4.2.1)  the system includes are automatically moved to the end of the list of includes without any variable or flag setting ( see cmLocalGenerator.cxx: GetDirectoriesImplicit: MoveSystemIncludesToEnd() ). There is an internal cache that should store system includes, but on OpenBSD it is empty. Can't tell you why it's empty
* this "system include stuff" can be workarounded: there is a variable CMAKE_<lang>_STANDARD_INCLUDE_DIRECTORIES (lang=C, CXX, ...). If something is in this variable it willbe stored as sytem include. I haven't tested this, but according to the code the paths in this variable shall have lower priority

Can't tell why it's working fine on Linux. On Linux the /usr/include is not even added to the include paths, but libpng and libjpeg are found there... 

wea...@gmail.com

unread,
Dec 12, 2025, 6:10:28 PM (4 days ago) Dec 12
to fltk.general
* this "system include stuff" can be workarounded: there is a variable CMAKE_<lang>_STANDARD_INCLUDE_DIRECTORIES (lang=C, CXX, ...). If something is in this variable it willbe stored as sytem include. I haven't tested this, but according to the code the paths in this variable shall have lower priority
Yep, setting this variable works fine too.FLTK compiles if I set it to "/usr/local/include" 

e...@ohnezutaten.de

unread,
Dec 13, 2025, 4:38:58 AM (4 days ago) Dec 13
to fltk.general, wea...@gmail.com
Am Samstag, 13. Dezember 2025, 00:04 schrieb wea...@gmail.com:
> [...]
> Can't tell why it's working fine on Linux. On Linux the /usr/include is not
> even added to the include paths, but libpng and libjpeg are found there...

I guess because it is the default search path of compilers. The tool "pkg-
config" skips it as well if you ask for the "--cflags" of "libjpeg" for example
(on my Linux system). But it doesn't skip it, if the package is located in "/
usr/local" instead as in your case with "libpng" and "libjpeg".

Jürgen


Albrecht Schlosser

unread,
Dec 13, 2025, 11:57:44 AM (3 days ago) Dec 13
to fltkg...@googlegroups.com
On 12/13/25 00:10 wea...@... wrote:
* this "system include stuff" can be workarounded: there is a variable CMAKE_<lang>_STANDARD_INCLUDE_DIRECTORIES (lang=C, CXX, ...). If something is in this variable it willbe stored as sytem include. I haven't tested this, but according to the code the paths in this variable shall have lower priority
Yep, setting this variable works fine too.FLTK compiles if I set it to "/usr/local/include"

Thanks for investigating further. I appreciate all input very much because it may help to find the "best" (?) solution. That solution would be enabled for all platforms w/o manual, platform specific coding.

My take on your workaround: good to know, but this would require (us) to know which include directories need to be added to this variable. This doesn't seem to be sensible for all platforms we build for. Basically NOT TO HAVE to know this is the reason why we use CMake: CMake should find such platform specifics out.

I found another approach: the CMake command target_include_directories() offers an argument called 'BEFORE' which puts specific include directories (those included in this specific command) *before* system include directories.

My idea is to use this feature for some of our include directories, particularly the FLTK header include directories. This would likely also be needed for the bundled image libs (png, jpeg) and zlib, but that needs to be investigated. I'm currently busy with other stuff but I'll do this when time permits.

Hint: if you want to try it yourself (maybe to provide a patch?), then the most likely file to check is CMake/fl_add_library.cmake in line 121 and maybe at other places later:
115-  # Special handling for the core 'fltk' library,
116-  # no matter if it's SHARED or STATIC
117-  # FIXME: maybe this should be in src/CMakeLists.txt (?)
118-
119-  if(LIBNAME STREQUAL "fltk")
120-
121:    target_include_directories(${TARGET_NAME} PUBLIC BEFORE  # add this here
122-      $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/..>
123-      $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/..>
124-      $<INSTALL_INTERFACE:include>
125-    )

If this worked on your system that'd be great. I can't try it myself right now but your help would be appreciated. TIA.

wea...@gmail.com

unread,
Dec 13, 2025, 3:46:46 PM (3 days ago) Dec 13
to fltk.general
Hint: if you want to try it yourself (maybe to provide a patch?), then the most likely file to check is CMake/fl_add_library.cmake in line 121 and maybe at other places later:
115- # Special handling for the core 'fltk' library, 116- # no matter if it's SHARED or STATIC 117- # FIXME: maybe this should be in src/CMakeLists.txt (?) 118- 119- if(LIBNAME STREQUAL "fltk") 120- 121: target_include_directories(${TARGET_NAME} PUBLIC BEFORE # add this here 122- $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/..> 123- $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/..> 124- $<INSTALL_INTERFACE:include> 125- ) If this worked on your system that'd be great. I can't try it myself right now but your help would be appreciated. TIA.

This worked! Thank you. The correct syntax seems to be that "BEFORE" is before PUBLIC, more precisely after the target name. 

Albrecht Schlosser

unread,
Dec 14, 2025, 8:57:39 AM (2 days ago) Dec 14
to fltkg...@googlegroups.com
On 12/13/25 21:46 wea...@gmail.com wrote:

Hint: if you want to try it yourself (maybe to provide a patch?), then the most likely file to check is CMake/fl_add_library.cmake in line 121 and maybe at other places later:
115- # Special handling for the core 'fltk' library, 116- # no matter if it's SHARED or STATIC 117- # FIXME: maybe this should be in src/CMakeLists.txt (?) 118- 119- if(LIBNAME STREQUAL "fltk") 120- 121: target_include_directories(${TARGET_NAME} PUBLIC BEFORE # add this here 122- $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/..> 123- $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/..> 124- $<INSTALL_INTERFACE:include> 125- ) If this worked on your system that'd be great. I can't try it myself right now but your help would be appreciated. TIA.

This worked! Thank you. 

Welcome, and thanks for your feedback.


The correct syntax seems to be that "BEFORE" is before PUBLIC, more precisely after the target name.

Yes, I noticed this myself when I gave it a try. However, it didn't work on my system. The only thing that worked for me was, as you found out,

  cmake -DCMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE=ON ..

There must be something else going on, but I didn't have enough time to dig deeper. I have another suspicion though which I need to investigate: see GitHub PR #1270:
https://github.com/fltk/fltk/pull/1270

This PR is more complicated than it may seem at first glance, which is why I didn't fix it yet. But I think, now the time has come... (but please don't hold your breath, there's more to do in my (FLTK) pipeline).

Reply all
Reply to author
Forward
0 new messages