|
|
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'.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/5b32af56-21fd-c58f-29db-7cce9275023b%40online.de.
[ Direct Link to Message ] | |
|
| |