On 2025-05-12 01:58, Stefan Heinzmann via Iup-users wrote:
> Hi Brenton,
>
> thank you very much for your detailed reply. I was aware of your
> project, from the mailing list. However, I have difficulties seeing how
> it addresses the main problem I referred to. In my opinion, the kernel
> version should be completely immaterial, as you can have any
> distribution on any kernel (within reason), and I don't understand how a
> library like this can depend on the kernel version. Something looks
> distinctly wrong.
>
> Ubuntu does have certain kernel versions associated with each release,
> and that appears to be what tecmake relies on. But this is only true for
> host installs of Ubuntu, not even when running an Ubuntu-based
> container, and certainly not with other distributions.
>
> Your approach to finding the right Webkit version is going in the right
> direction, as it doesn't appear to depend on the kernel, but on the
> distribution, but in a way it is even more cumbersome, as there are at
> least as many distributions. You effectively still require Ubuntu.
> [...]
[Apologies for typos; my morning coffee is still kicking in.]
G'day Stefan,
As I said, not only does lglicua work on specified versions of:
* Debian-based systems:
- Debian, Ubuntu, LinuxMint, MX and Kali;
but it also works on specified versions of:
* Red Hat versions:
- CentOS-7, CentOS-Stream-7, CentOS-Stream-8, Rocky.
This is all done with the modified tecmake.mak and tec_uname
files that I quoted excerpts from, as well as with more
build tailoring and package naming in
LGLICUA/svn/assistant-database.lua.
Stuffed if I know where you got your idea:
> You effectively still require Ubuntu.
(FYI, I develop on LinuxMint, an Ubuntu derivative...)
I stomp on the package build files when package building is
initiated from within the Assistant (inside LGLICUA/build,
"quirky" script named "./q"). If you try to build
independently, you will miss out on the changeover. If you
were to look at the sources as checked out from the repository
(note that the Assistant also uses the SVN repository, as it
often taken months for fixes to be bundled up into a new
release), then you would see the Tecgraf versions of the build
system, verbatim. The Assistant explicitly overrides these at
the last possible moment, when the build command is given, as
it knows that the SVN version is This may
have caused confusion.
--------------------
As new distributions get released, and as packages are updated,
it's quite possible that some of the connections that are quoted
in my script may break; I know that there are assumptions, and
that some of them may be brittle.
But, especially when looking across the spread of distributions
above, I tried, and tried, and tried to find some common ground
where, for a specified package, you could directly query an
"oracle" to find out, for a library package (e.g. webkit2-gtk),
details such as:
* Exact Distro package manager name (e.g. webkit2-gtk-4.0);
* Include path(s) (compiler -I<PATH>);
* Library path(s) (compiler -L<PATH>); and/or
* Exact library name(s) to feed to the linker.
Some distributions (I forget which) do provide facilities for
these sorts of queries, but it can't be depended on. My hacking
of tec_uname was done only after I'd exhausted all other avenues
I could find (a non-trivial search spanning multiple weeks).
--------------------
I've appealed to Antonio Scuri, the maintainer of many things in
Tecgraf, including IM/CD/IUP. While we sorted out quite a number
of things in the early days of my involvement, consideration of my
input has gradually dried up. I suspect that:
1. As I noted in my previous message, I had the freedom to
look at the build system from a GNU/Linux-only
perspective, whereas the original system supports a
wider range of OSes/VMs/emulations/clients. Scuri may
be loathe to perform the merger, and I don't know of
any specification of the entire set of environments,
packages and ultimately behaviours that tecmake.mak
etc. might be required to support;
2. CD and IM, and to a lesser extent, IUP, are somewhat
stalled and/or marked for no further development; and
3. Tecmake.mak, and other build files, are used in other
projects inside Tecgraf, and so maintaining
compatibility with these overrides any suggested
improvements to the build system.
Scuri's had a year to look at my last lglicua release (0.1-beta1),
and hasn't seen fit to change the packages at all. (I still
reckon that my use of Make's "filter" builtin is better than
the current heavy use of "findstring".)
[Source warnings have also increased, as compilers, especially
GCC, have become better at flow tracing, dodgy construct
identification, and also have more verbose error messages.
Sadly, sometimes library sources have been incorporated when at
a particular version, then tailored to fit in to the IM/CD/IUP
framework. Newer versions of these libraries have been modified
to address the improved diagnostic capabilities of compilers,
but re-engineering the connection, by removing the old internal
sources, and then referencing the code as an external library,
is a BIG task, and the incentives for doing so (e.g. code
hygiene practices such as warning-free compilation), are not
compelling.]
cheers,
s-b etc etc etc
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
