### Suggestion
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].
### Example
### Motivation
Issues could be more easily traced to a precise library version. Users could locate this otherwise obscure information without leaving the app.
### Implementation
The main problem is how to expose the libraries' versions at compile time. I've had some luck with the following approach:
1. write a script to parse the content of `scintilla[/lexilla]/version.txt` and return the appropriate version (based on input) in semver format
2. call the script in `configure.ac` via the [`m4_esyscmd`] macro, assigning the script output to preprocessor definitions for each version
3. use the definitions in `src/libmain.c` to extend Geany's debug output
### Questions
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].
[^1]: "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
[divergent release cadence]: https://groups.google.com/g/scintilla-interest/c/1VWWqoJ_kmA/m/mfqpF1tjAgAJ [`m4_esyscmd`]: https://www.gnu.org/software/m4/manual/html_node/Esyscmd.html#index-esyscmd [documenting lexer properties]: https://github.com/geany/geany/issues/2517
Scintilla and Lexilla are compiled into Geany, Geany does not link against them. So other than development versions in Git there is a one to one relationship between Geany version and Scintilla/Lexilla versions. So I'm not sure adding more to the debug output would add much value.
If there was a need for this the `update-scintilla.sh` script could use the `version.txt` file contents to edit a string to be displayed when an update happened, not at configure time.
I would probably accept a well done patch that implements this.
@kugel- just to be clear, "this" == `update-scintilla.sh` or `configure`?
I guess I would prefer if we'd just someting like
``` static unsigned int ver[2] = { #include "scintilla/version.txt" , #include "scintilla/lexilla/version.txt" }
… sprintf(buf, "Scintilla version %d.%d.%d", ver[0]/100, (ver[0]/10)%10, ver[0]%10)) sprintf(buf, "Lexilla version %d.%d.%d", ver[1]/100, (ver[1]/10)%10, ver[1]%10)) ```
or define some preprocessor symbol via Makefile (-DSCI_VER=$(file < scintilla/version.txt) but in a portable fashion)
Why not do it in `update-scintilla.sh` rather than doing it in every make? Then the meson build does not need updating as well.
as long as it works and doesn't add to the complexity of importing new scintillas, why not?!
@kugel- BTW your runtime suggestion is fine too.
But one question that applies to both it and any script is how to know where the digits in the `version.txt` split, past contents have been `3211`. So without human intervention how will a script/program know if it is 3.21.1 (correct) or 3.2.11 (incorrect) or something else?
If it needs human intervention it can't be runtime or makefile or configure, it could only be at `update-scintilla.sh` time.
But one question that applies to both it and any script is how to know where the digits in the `version.txt` split, past contents have been `3211`. So without human intervention how will a script/program know if it is 3.21.1 (correct) or 3.2.11 (incorrect) or something else?
The "script" I had in mind is just a `sed` one-liner, based on Neil's own suggestion from a while back:
$ sed -e "s/(.)(.)(.)/\1.\2.\3/" < ~/merc/scintilla/version.txt
https://groups.google.com/g/scintilla-interest/c/6Ertem36m_M/m/kvKhJQReAQAJ
Of course this assumes a single-digit major and minor number; the micro version can be any length. Dealing with double-digit major/minor increments might be unavoidable, but it would most likely be a rare occurrence.
If it needs human intervention it can't be runtime or makefile or configure, it could only be at update-scintilla.sh time.
I wouldn't suggest changing `update-scintilla.sh` for such a trivial feature. If the preference is to keep `config.h` generation as it is — and assuming 5.1.xx doesn't jump to 5.10.xx anytime soon — the least intrusive solution might look something like this:
```diff diff --git a/src/Makefile.am b/src/Makefile.am index 8acddfb8..cf7abcda 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -20,6 +20,7 @@ AM_CPPFLAGS = \ -DGTK \ -DGEANY_PRIVATE \ -DG_LOG_DOMAIN=""Geany"" \ + -DSCI_VER=""`sed -e 's/(.)(.)(.)/\1.\2.\3/' < $(top_srcdir)/scintilla/version.txt`"" \ @GTK_CFLAGS@ @GTHREAD_CFLAGS@ \ $(MAC_INTEGRATION_CFLAGS)
diff --git a/src/libmain.c b/src/libmain.c index d316f440..3d5437f0 100644 --- a/src/libmain.c +++ b/src/libmain.c @@ -93,6 +93,10 @@ static gchar *original_cwd = NULL;
static const gchar geany_lib_versions[] = "GTK %u.%u.%u, GLib %u.%u.%u";
+#ifdef SCI_VER +static const gchar geany_scintilla_version[] = "Scintilla %s"; +#endif + static gboolean want_plugins;
/* command-line options */ @@ -1105,6 +1109,10 @@ gint main_lib(gint argc, gchar **argv) gtk_major_version, gtk_minor_version, gtk_micro_version, glib_major_version, glib_minor_version, glib_micro_version);
+#ifdef SCI_VER + geany_debug(geany_scintilla_version, SCI_VER); +#endif + os_info = utils_get_os_info_string(); if (os_info != NULL) { ``` _Lexilla version left out for brevity_
The "script" I had in mind is just a sed one-liner, based on Neil's own suggestion from a while back:
$ sed -e "s/(.)(.)(.)/\1.\2.\3/" < ~/merc/scintilla/version.txt
With all due respect to Neil, is he guaranteeing there will not be a 5.1.10, its up to 5.1.6 already? Remember as I pointed out there was a 3.21.1.
To be clear, I do not want it part of configure or make, it is something that changes once when Scintilla changes and there is a shell script `update-scintilla.sh` to run when doing that upgrade, thats the correct place to do it.
When importing Scintilla and Lexilla `version.txt` convert to a string literal with the dots and import it as @kugel- showed above. Can even write to a `version.h` file if you don't want to change `version.txt`
Good idea! I agree with @elextr that parsing and adding the Scintilla/Lexilla version in the build system is rather overkill and complicates the Meson integration unnecessarily. Adding it in `update-scintilla.sh` seems much simpler to me and is fully sufficient as this script is always used when the Scintilla/Lexilla versions ever change in Geany.
The sed script won't work with either 5.1.10 [...]
It works better without a third capture group:
```sh-session $ echo '5110' | sed -e 's/(.)(.)/\1.\2./' 5.1.10
$ echo '515678901234' | sed -e 's/(.)(.)/\1.\2./' 5.1.5678901234 ```
[...] or 3.21.1.
For major/minor increments, just add more dots where needed:
```sh-session $ echo '3211' | sed -e 's/(.)(..)/\1.\2./' 3.21.1
$ echo '515678901234' | sed -e 's/(..)(..)/\1.\2./' 51.56.78901234 ```
When importing Scintilla and Lexilla `version.txt` convert to a string literal with the dots and import it as @kugel- showed above.
I looked at that, but was more interested in the afterthought suggestion:
or define some preprocessor symbol via Makefile (-DSCI_VER=$(file < scintilla/version.txt) but in a portable fashion)
I hear consensus that a build time intervention ain't gonna happen. As for directly including the version files, I think something less ugly can be worked out, such as:
write to a `version.h` file if you don't want to change `version.txt`
Good idea; even better if `version.h` contained actual preprocessor definitions. Here's a way that `update-scintilla.sh` could generate them:
```diff diff --git a/scripts/update-scintilla.sh b/scripts/update-scintilla.sh index 75d3834c..4a183344 100755 --- a/scripts/update-scintilla.sh +++ b/scripts/update-scintilla.sh @@ -53,6 +53,28 @@ copy_to() done || exit 1 }
+parse_version() +{ + # TODO: change to /(.)(..)/\1.\2./ when 5.10.x is released + printf '"%s"' $(sed -e 's/(.)(.)/\1.\2./' "$1") +} + +(cat <<EOL +#ifndef SCI_VERSION_H +#define SCI_VERSION_H 1 +#define SCI_VERSION $(parse_version 'scintilla/version.txt') +#endif +EOL +) > "$SCI_SRC"/version.h + +(cat <<EOL +#ifndef LEX_VERSION_H +#define LEX_VERSION_H 1 +#define LEX_VERSION $(parse_version 'scintilla/lexilla/version.txt') +#endif +EOL +) > "$LEX_SRC"/version.h + # purge executbale bits umask 111 # copy everything from scintilla but lexers @@ -66,12 +88,14 @@ copy_to scintilla/gtk "$SCI_SRC"/gtk/*.h copy_to scintilla/gtk "$SCI_SRC"/gtk/*.list copy_to scintilla "$SCI_SRC"/License.txt copy_to scintilla "$SCI_SRC"/version.txt +copy_to scintilla "$SCI_SRC"/version.h copy_to scintilla/lexilla/src "$LEX_SRC"/src/*.cxx copy_to scintilla/lexilla/include "$LEX_SRC"/include/*.h copy_to scintilla/lexilla/lexlib "$LEX_SRC"/lexlib/*.cxx copy_to scintilla/lexilla/lexlib "$LEX_SRC"/lexlib/*.h copy_to scintilla/lexilla/ "$LEX_SRC"/License.txt copy_to scintilla/lexilla/ "$LEX_SRC"/version.txt +copy_to scintilla/lexilla/ "$LEX_SRC"/version.h # now copy the lexers we use git -C scintilla/lexilla/lexers/ ls-files *.cxx | while read f; do copy_to "scintilla/lexilla/lexers" "$LEX_SRC/lexers/$f" ``` [^1]
I'm not overly fond of the version parsing kludge, but I think the goal should be approximating the convenience of proper version strings, the way Geany's `VERSION` macro already expands to sensible text.
There's ultimately no painless way around this until Scintilla starts declaring its version in a header like other development libraries. I haven't researched it, but chances are it's been requested and denied before. Asking again can't be any worse than waiting for Debian's ["libscintilla-dev" package](https://pkgs.org/search/?q=libscintilla-dev).
[^1]: Alternatively, copy version.h instead of version.txt
As for directly including the version files, I think something less ugly can be worked out
I was too harsh. The earlier suggestion was really no worse than the version parsing you'll find in Lexilla's [development scripts]:
```python # Discover version information version = (lexillaDir / "version.txt").read_text().strip() versionDotted = version[0] + '.' + version[1] + '.' + version[2] versionCommad = versionDotted.replace(".", ", ") + ', 0' ```
or [Scintilla's]:
```python class ScintillaData: def __init__(self, scintillaRoot): # Discover version information self.version = (scintillaRoot / "version.txt").read_text().strip() self.versionDotted = self.version[0] + '.' + self.version[1] + '.' + \ self.version[2] self.versionCommad = self.versionDotted.replace(".", ", ") + ', 0' ```
But then, how does SciTE manage all those version numbers in the About dialog?
[Ah!]
```cpp #ifndef SCITE_H #define SCITE_H
// Version numbers and dates #define VERSION_SCITE "5.1.6" #define VERSION_WORDS 5, 1, 6, 0 #define COPYRIGHT_DATES "December 1998-December 2021" #define COPYRIGHT_YEARS "1998-2021" #define VERSION_SCINTILLA "5.1.5" #define VERSION_LEXILLA "5.1.4" ```
[development scripts]: https://github.com/ScintillaOrg/lexilla/blob/a35a59845e793d9d37d249cf097e71f... [Scintilla's]: https://sourceforge.net/p/scintilla/code/ci/da6ead58cc1bdb16a4ee063497c3d25e... [Ah!]: https://sourceforge.net/p/scintilla/scite/ci/93067c476e2c34e8620ad73cdfe842c...
I haven't researched it, but chances are it's been requested and denied before.
You already linked to at least one case above, where Neil made his suggestion.
The earlier suggestion was really no worse than the version parsing you'll find in Lexilla's development scripts: or Scintilla's:
Interesting, perhaps Neil intends to never let versions get above one digit any more. Maybe check if its specified anywhere, or ask him to confirm if not?
Well then perhaps your `sed -e 's/(.)(.)/\1.\2./' "$1"` is ok for now and see if Neil confirms single digit only.
Having to edit the script is not really viable, might be ok for experienced experts like @kugel- but a first timer might not notice, so hope its going to be single digits forevermore.
Ah!
So how are those defines generated? Can we steal it :smile:?
hope its going to be single digits forevermore
Perhaps not that long, but the foreseeable future would be a safe bet.
So how are those defines generated?
With Neil's weapon of choice, naturally:
```python def UpdateVersionNumbers(sci, pathSciTE, lexVersion, scintillaVersion): pathHeader = pathSciTE / "src" / "SciTE.h" UpdateLineInFile(pathHeader, '#define VERSION_SCITE', '#define VERSION_SCITE "' + sci.versionDotted + '"') UpdateLineInFile(pathHeader, "#define VERSION_WORDS", "#define VERSION_WORDS " + sci.versionCommad) UpdateLineInFile(pathHeader, '#define COPYRIGHT_DATES', '#define COPYRIGHT_DATES "December 1998-' + sci.myModified + '"') UpdateLineInFile(pathHeader, '#define COPYRIGHT_YEARS', '#define COPYRIGHT_YEARS "1998-' + sci.yearModified + '"') UpdateLineInFile(pathHeader, '#define VERSION_LEXILLA', '#define VERSION_LEXILLA "' + lexVersion + '"') UpdateLineInFile(pathHeader, '#define VERSION_SCINTILLA', '#define VERSION_SCINTILLA "' + scintillaVersion + '"') ```` https://sourceforge.net/p/scintilla/scite/ci/default/tree/scripts/RegenerateSource.py#l94
The interesting thing is where the parameters lexVersion and scintillaVersion come from, and for Scintilla at least, it shares the `ScintillaData` code pasted above, so one digit limitation.
So ok, lets go with the one digit thing for now.
@rdipardo can you make a PR?
Thanks but I like to keep my GitHub clean of spurious forks.
Nonetheless I look forward to finding out what "the one digit thing" refers to. It can't be a shell function, which is demonstrably not limited to single-digit micro segments (and is adaptable to wider major/minor ones).
That leaves one of the following:
- chopping up the bytes of `version.txt` right inside a source file - adapting Neil's python script, with its dependency chain of external modules, one of them living inside Scintilla's script directory, and a new `__pycache__` entry for `.gitignore`
There's a new upstream ticket on the version header issue: https://github.com/ScintillaOrg/lexilla/issues/142
github-comments@lists.geany.org