[Gretl-devel] Re: Small Windows build hiccup
Am 08.11.2019 um 23:26 schrieb Allin Cottrell:
On Fri, 8 Nov 2019, Sven Schreiber wrote:
> (BTW, I'm noticing that in the subdir language-specs
there's nothing
> about gretl/hansl. Should such a language spec be submitted upstream to
> GTK, or is it already in newer versions?)
It's not in newer versions, and maybe we should submit it upstream.
Though since hansl functions typically grow per release we'd probably
want to rely on our own version anyway so that's not a high priority.
Right. Personally I'm indeed working with gretl's own editor most of the
time, but I thought that people on Linux perhaps would like to use a
GTK-editor of their own choice, with the correct syntax highlighting.
But I guess we whould wait and see if there's actually demand for that.
> - line 32:
> Is the given path ${TARGET}/share/locale/$lang/LC_MESSAGES correct in
> this context? I see the directory ${TARGET}/locale (without "share"),
> but I'm not sure when exactly it was created. -- Ah, but in line 101 I
> see some alias being created, so I guess that solves it (?).
Not sure I fully understand. We put gtk/glib message catalogs under
share/locale (where they're expected) but put gretl catalogs just under
locale (there being no need for another layer of directory structure
inside a stand-alone package).
Forget it; first I thought it didn't match the existing structure
(because I found the co-existence of share/locale and locale a little
confusing).
> - line 42:
> libsvm.dll is not present in ${SYSBIN} here.
We don't use that any more -- update needed!
Ah, OK.
> - line 80: replace gtk-2.0 with gtk-3.0
Maybe! But I think that may be gone, or may have been moved more
substantially. What it does, I don't know.
(Talking about im-multipress.conf.) Well here on my setup I am actually
seeing the file $SYSBASE/etc/gtk-3.0/im-multipress.conf so that's why I
suggested this change. It is actually the only file in this path/dir.
> So much for that. Allin, do you think it makes sense to already
> incorporate these changes somehow in the source that creates the
> install-runtime.sh file (conditional on win32 && GTK3 of course), or
> should I first change the created file manually?
I'd recommend experimenting with a manual edit of the generated file
first, but if all goes well we can generalize the mechanism for
generating the file. That means modifying both install-runtime.sh.in and
the information it's fed from the configure script.
OK.
thanks,
sven