[Github-comments] [geany/geany] RFC: Include Scintilla version in debug info (Discussion #3108)

Robert Di Pardo notifications at xxxxx
Sat Jan 22 12:37:53 UTC 2022


> 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


-- 
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/discussions/3108#discussioncomment-2022492
You are receiving this because you are subscribed to this thread.

Message ID: <geany/geany/repo-discussions/3108/comments/2022492 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20220122/1023abf3/attachment-0001.htm>


More information about the Github-comments mailing list