RFC: introduce public config header <FL/fl_config.h>
103 views
Skip to first unread message
Albrecht Schlosser
Aug 29, 2021, 9:44:48 AM8/29/21
to fltk.coredev
Hi all,
there are some reasons why I believe we should have a public header that reflects some build option dependent macros.
TL;DR:
This header would be included by <FL/Fl.H> and help to solve several issues. Users wouldn't need to change their code. See details below.
Are there any objections (or proposals for a better file name)?
Please vote (ASAP), even if you're undecided or don't care (abstain (0) is a valid vote).
Of course, my vote is +1.
Reasoning:
We have some public headers that try to *guess* the platform and do something according to the result. This could be avoided if we had such a header.
This header shall replace (and include) the current FL/abi-version.h header file and will be generated by configure and CMake, resp.
The FLTK ABI version belongs into this config header because it's a configure/CMake option.
We can optionally move the FLTK version macros to this header as well. This would have an advantage for users building their own apps with CMake (specifics are OT here, but I may explain if there's demand).
The most important "guess" is the platform type which we know by configure, particularly the macro USE_X11.
This header shall only contain macros defined by FLTK configure (build) options, not related configurations found by system inspection. The latter (typically like HAVE_PNG etc.) shall be kept in the private header config.h. The only notable exception is USE_X11 which is kinda "hybrid": it's a configure option on some platforms (Windows/Cygwin and macOS) and *currently* the default configuration on Unix/Linux. In the future the latter will likely be a full configure option as well (alternative is Wayland).
We know at configure time which type of Cairo configuration the FLTK lib is built for, but currently the user needs to #define FLTK_HAVE_CAIRO to enable Cairo in the public header <FL/Fl.H>, i.e. *before* FL/Fl.H gets included. This is a long-standing issue because fluid generates code to '#include <FL/Fl.H>' always as the very first #include statement. Hence the user is forced to define FLTK_HAVE_CAIRO on the commandline in their build configuration. This would no longer be necessary.
There may be other build options worth to be added to this public configuration header (later), e.g. whether this lib was built with Pango support or not, basically many of the '--enable-something' or respective CMake options.
Last but not least: are other libraries provide such public configuration headers as well, e.g. jpeg, png, ...
Summary:
As a first step I propose to add at least the following macros:
- USE_X11 -> renamed to FLTK_USE_X11
- FLTK_HAVE_CAIRO
- FLTK_USE_CAIRO -> renamed to FLTK_HAVE_CAIROEXT for consistency [1]
- FL_ABI_VERSION
I volunteer to do this as soon as we have enough votes. TIA.
[1] FLTK_USE_CAIRO is a misnomer, intended to be used if FLTK did all drawings with Cairo (see README.Cairo.txt). This is not the case and the related configure option is '--enable-cairoext' and in CMake 'OPTION_CAIROEXT'.
there are some reasons why I believe we should have a public header that reflects some build option dependent macros.
TL;DR:
This header would be included by <FL/Fl.H> and help to solve several issues. Users wouldn't need to change their code. See details below.
Are there any objections (or proposals for a better file name)?
Please vote (ASAP), even if you're undecided or don't care (abstain (0) is a valid vote).
Of course, my vote is +1.
Reasoning:
We have some public headers that try to *guess* the platform and do something according to the result. This could be avoided if we had such a header.
This header shall replace (and include) the current FL/abi-version.h header file and will be generated by configure and CMake, resp.
The FLTK ABI version belongs into this config header because it's a configure/CMake option.
We can optionally move the FLTK version macros to this header as well. This would have an advantage for users building their own apps with CMake (specifics are OT here, but I may explain if there's demand).
The most important "guess" is the platform type which we know by configure, particularly the macro USE_X11.
This header shall only contain macros defined by FLTK configure (build) options, not related configurations found by system inspection. The latter (typically like HAVE_PNG etc.) shall be kept in the private header config.h. The only notable exception is USE_X11 which is kinda "hybrid": it's a configure option on some platforms (Windows/Cygwin and macOS) and *currently* the default configuration on Unix/Linux. In the future the latter will likely be a full configure option as well (alternative is Wayland).
We know at configure time which type of Cairo configuration the FLTK lib is built for, but currently the user needs to #define FLTK_HAVE_CAIRO to enable Cairo in the public header <FL/Fl.H>, i.e. *before* FL/Fl.H gets included. This is a long-standing issue because fluid generates code to '#include <FL/Fl.H>' always as the very first #include statement. Hence the user is forced to define FLTK_HAVE_CAIRO on the commandline in their build configuration. This would no longer be necessary.
There may be other build options worth to be added to this public configuration header (later), e.g. whether this lib was built with Pango support or not, basically many of the '--enable-something' or respective CMake options.
Last but not least: are other libraries provide such public configuration headers as well, e.g. jpeg, png, ...
Summary:
As a first step I propose to add at least the following macros:
- USE_X11 -> renamed to FLTK_USE_X11
- FLTK_HAVE_CAIRO
- FLTK_USE_CAIRO -> renamed to FLTK_HAVE_CAIROEXT for consistency [1]
- FL_ABI_VERSION
I volunteer to do this as soon as we have enough votes. TIA.
[1] FLTK_USE_CAIRO is a misnomer, intended to be used if FLTK did all drawings with Cairo (see README.Cairo.txt). This is not the case and the related configure option is '--enable-cairoext' and in CMake 'OPTION_CAIROEXT'.
Lauri Kasanen
Aug 29, 2021, 12:24:34 PM8/29/21
to fltkc...@googlegroups.com
On Sun, 29 Aug 2021 15:44:46 +0200
Albrecht Schlosser <Albrech...@online.de> wrote:
> Hi all,
>
> there are some reasons why I believe we should have a public header that
> reflects some build option dependent macros.
>
> _*TL;DR:*_
Albrecht Schlosser <Albrech...@online.de> wrote:
> Hi all,
>
> there are some reasons why I believe we should have a public header that
> reflects some build option dependent macros.
>
>
> This header would be included by <FL/Fl.H> and help to solve several
> issues. Users wouldn't need to change their code. See details below.
+1
> This header would be included by <FL/Fl.H> and help to solve several
> issues. Users wouldn't need to change their code. See details below.
- Lauri
duncan
Aug 29, 2021, 12:41:49 PM8/29/21
to fltk.coredev
there are some reasons why I believe we should have a public header that reflects some build option dependent macros.
. . .
This header would be included by <FL/Fl.H> and help to solve several issues. . . . .
Stupid question perhaps, but why generate an <FL/fl_config.h> that's included in <FL/Fl.H> ?
Can't configure/CMake add these items directly into the top of <FL/Fl.H> ?
D.
Albrecht Schlosser
Aug 29, 2021, 1:18:33 PM8/29/21
to fltkc...@googlegroups.com
Not a stupid question. Well, there are some reasons.
(1) It would make things more complicated than necessary. We need two different input files that have to be prepared in parallel (logically consistent) as source for the generation. configure and CMake need different input to generate the same output. You'll see what I mean if you compare configh.cmake.in and configh.in.
(2) The syntax of the input file for configure prohibits to mix constant #define statements (as in Fl.H) with input to the generator source. It would be at least the very hard to maintain.
(3) The generated file(s) must be in a different directory than the original source files (CMake out of source build). Although we could manage this for a complete header file Fl.H it seems better manageable (to me) to split this.
(4) One thing I mentioned in my original post was to enable a special feature for CMake users when building their own projects. This feature requires to parse a file by CMake code to get the FLTK version. This is an option I'm planning for the near future. It's less error prone to parse a very short file than a much longer one.
(5) It's always been that way (with abi-version.h). No, that's a joke. But seriously, what I've seen in other libs is that they also provide a (short) config header rather than one header file including "everything".
Point (1) should be enough. I wrote the other points only to emphasize that I believe it's not thinking further about it. But thanks for the question anyway.
Finally my proposal will (a) extend and rename abi-version.h to fl_config.h or (b) rename and extend it, whatever you like. ;-)
PS: Duncan, your vote as long time FLTK dev would be appreciated as well. Thanks.
(1) It would make things more complicated than necessary. We need two different input files that have to be prepared in parallel (logically consistent) as source for the generation. configure and CMake need different input to generate the same output. You'll see what I mean if you compare configh.cmake.in and configh.in.
(2) The syntax of the input file for configure prohibits to mix constant #define statements (as in Fl.H) with input to the generator source. It would be at least the very hard to maintain.
(3) The generated file(s) must be in a different directory than the original source files (CMake out of source build). Although we could manage this for a complete header file Fl.H it seems better manageable (to me) to split this.
(4) One thing I mentioned in my original post was to enable a special feature for CMake users when building their own projects. This feature requires to parse a file by CMake code to get the FLTK version. This is an option I'm planning for the near future. It's less error prone to parse a very short file than a much longer one.
(5) It's always been that way (with abi-version.h). No, that's a joke. But seriously, what I've seen in other libs is that they also provide a (short) config header rather than one header file including "everything".
Point (1) should be enough. I wrote the other points only to emphasize that I believe it's not thinking further about it. But thanks for the question anyway.
Finally my proposal will (a) extend and rename abi-version.h to fl_config.h or (b) rename and extend it, whatever you like. ;-)
PS: Duncan, your vote as long time FLTK dev would be appreciated as well. Thanks.
Manolo
Aug 30, 2021, 10:11:28 AM8/30/21
to fltk.coredev
Le dimanche 29 août 2021 à 15:44:48 UTC+2, Albrecht Schlosser a écrit :
Hi all,
there are some reasons why I believe we should have a public header that reflects some build option dependent macros.
My vote is +1 to add FL/fl_config.h
duncan
Aug 30, 2021, 1:48:14 PM8/30/21
to fltk.coredev
Stupid question perhaps, but why generate an <FL/fl_config.h> that's included in <FL/Fl.H> ?Can't configure/CMake add these items directly into the top of <FL/Fl.H> ?
Not a stupid question. Well, there are some reasons.
(1) It would make things more complicated than necessary. We need two different input files that have to be prepared in parallel (logically consistent) as source for the generation. configure and CMake need different input to generate the same output. You'll see what I mean if you compare configh.cmake.in and configh.in.
. . .
I knew you would have already thought it through and would have an answer ready to hand :-)
PS: Duncan, your vote as long time FLTK dev would be appreciated as well. Thanks.
I might have been following FLTK for a long time, but I wouldn't really consider
myself a true dev as I've only really tinkered with the documentation.
I leave the real FLTK internals to the professionals :-)
But seeing as you explained, and asked me so nicely, you can have my +1 too :-)
D.
Albrecht Schlosser
Aug 31, 2021, 10:06:45 AM8/31/21
to fltkc...@googlegroups.com
On 8/29/21 3:44 PM Albrecht Schlosser wrote:
>
> there are some reasons why I believe we should have a public header
> that reflects some build option dependent macros.
>
>
> there are some reasons why I believe we should have a public header
> that reflects some build option dependent macros.
>
> Please vote (ASAP), even if you're undecided or don't care (abstain
> (0) is a valid vote).
>
> Of course, my vote is +1.
So far we got 4 votes with a total result of +4. Thanks to all who voted.
> (0) is a valid vote).
>
> Of course, my vote is +1.
I'm going to implement this new feature as described.
Manolo
Jan 4, 2022, 5:39:44 AM1/4/22
to fltk.coredev
@Albrecht To continue the logic of the present RFC, I would suggest to move #include <FL/fl_config.h> from
FL/platform.H to FL/platform_types.h.
Since platform.H includes platform_types.h, nothing will break, and code using the Fl_Offscreen type
defined in platform_types.h, will always see the correct, platform-dependent, definition of this type.
If you agree, I can do this change, after having clarified where exactly #include <FL/Fl_Export.H>
should be positioned.
Albrecht Schlosser
Jan 4, 2022, 11:19:42 AM1/4/22
to fltkc...@googlegroups.com
On 1/4/22 11:39 AM Manolo wrote:
> @Albrecht To continue the logic of the present RFC, I would suggest to
> move #include <FL/fl_config.h> from
> FL/platform.H to FL/platform_types.h.
> Since platform.H includes platform_types.h, nothing will break, and
> code using the Fl_Offscreen type
> defined in platform_types.h, will always see the correct,
> platform-dependent, definition of this type.
>
> If you agree, I can do this change,
Feel free to do this. I wouldn't mind if it was included in both files
> @Albrecht To continue the logic of the present RFC, I would suggest to
> move #include <FL/fl_config.h> from
> FL/platform.H to FL/platform_types.h.
> Since platform.H includes platform_types.h, nothing will break, and
> code using the Fl_Offscreen type
> defined in platform_types.h, will always see the correct,
> platform-dependent, definition of this type.
>
> If you agree, I can do this change,
because <FL/fl_config.h> has its own include guards anyway.
If you edit these two files (FL/platform_types.h and FL/platform.H)
please make sure that we *use* the new feature and replace '#else //
X11' with '#elif defined(FLTK_USE_X11)'. This would fix an omission of
my patch.
I'm not sure if we should add another '#else' case though. In earlier
versions we had something like "#error unsupported platform" or similar
but I'd tend to leave this open without warning or error. Maybe an empty
'#else' clause just for documentation?
> after having clarified where exactly #include <FL/Fl_Export.H>
> should be positioned.
<FL/fl_config.h> or whatever.
Manolo
Jan 4, 2022, 12:40:03 PM1/4/22
to fltk.coredev
Le mardi 4 janvier 2022 à 17:19:42 UTC+1, Albrecht Schlosser a écrit :
On 1/4/22 11:39 AM Manolo wrote:
> @Albrecht To continue the logic of the present RFC, I would suggest to
> move #include <FL/fl_config.h> from
> FL/platform.H to FL/platform_types.h.
> Since platform.H includes platform_types.h, nothing will break, and
> code using the Fl_Offscreen type
> defined in platform_types.h, will always see the correct,
> platform-dependent, definition of this type.
>
> If you agree, I can do this change,
Feel free to do this. I wouldn't mind if it was included in both files
because <FL/fl_config.h> has its own include guards anyway.
If you edit these two files (FL/platform_types.h and FL/platform.H)
please make sure that we *use* the new feature and replace '#else //
X11' with '#elif defined(FLTK_USE_X11)'. This would fix an omission of
my patch.
I'm not sure if we should add another '#else' case though. In earlier
versions we had something like "#error unsupported platform" or similar
but I'd tend to leave this open without warning or error. Maybe an empty
'#else' clause just for documentation?
I've left the 'if' clause without 'else'.
> after having clarified where exactly #include <FL/Fl_Export.H>
> should be positioned.
This is independent of the other stuff and can be before or after
<FL/fl_config.h> or whatever.
Yes, I see that too now.
Manolo
Jan 4, 2022, 1:13:16 PM1/4/22
to fltk.coredev
and, to continue in the same logic, I would also suggest to create a new file
FL/x11.H and to put there the X11-specific part of FL/platform.H which would
then contain, in essence :
# include <FL/platform_types.h> // will bring in FL/fl_config.h
# ifdef _WIN32
# include "win32.H"
# elif defined(__APPLE__)
# include "mac.H"
# elif defined(__ANDROID__)
# include "android.H"
# elif defined(FLTK_USE_X11)
# include "win32.H"
# elif defined(__APPLE__)
# include "mac.H"
# elif defined(__ANDROID__)
# include "android.H"
# elif defined(FLTK_USE_X11)
# include "x11.H"
# endif
//
// cross-platform declarations
//
……
Albrecht Schlosser
Jan 4, 2022, 1:52:01 PM1/4/22
to fltkc...@googlegroups.com
On 1/4/22 7:13 PM Manolo wrote:
> and, to continue in the same logic, I would also suggest to create a
> new file
> FL/x11.H and to put there the X11-specific part of FL/platform.H ...
> and, to continue in the same logic, I would also suggest to create a
> new file
Good point, +1
Feel free to do this as well. TIA
Manolo
Jan 5, 2022, 1:51:10 AM1/5/22
to fltk.coredev
Done (fc1efc7).
Reply all
Reply to author
Forward
0 new messages