FLTK logo

[fltk.coredev] RFC: introduce public config header <FL/fl_config.h>

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

RFC: introduce public config header <FL/fl_config.h> Albrecht Schlosser Aug 29, 2021  
  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 ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.