The debug information at Help > Debug Messages should report the Scintilla version Geany was linked against.
Lexilla should have its own entry as well, given its divergent release cadence.
Issues could be more easily traced to a precise library version.
Users could locate this otherwise obscure information without leaving the app.
The main problem is how to expose the libraries' versions at compile time. I've had some luck with the following approach:
write a script to parse the content of scintilla[/lexilla]/version.txt and return the appropriate version (based on input) in semver format
call the script in configure.ac via the m4_esyscmd macro, assigning the script output to preprocessor definitions for each version
use the definitions in src/libmain.c to extend Geany's debug output
My concern is that step 2 may be disruptive to the build workflow. Some potential issues that come to mind:
builds targeting Windows would need access to a POSIX shell (if they don't already . . . I've never tried to package Geany
calling m4_esyscmd on a failing script does not crash autoreconf 1. But aborting in that case might be better than generating an incomplete config.h header
This thread is here to gather input, especially with regard to the acceptability of using m4_esyscmd in the build.
A search for similar topics found only an open RFC about documenting lexer properties.
"The error output of shell-command is not a part of the expansion: it will appear along with the error output of m4." https://www.gnu.org/software/m4/manual/html_node/Esyscmd.html#index-esyscmd
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.