On 3/28/21 9:52 AM, Chase wrote:
So it sounds like the makefile incompatibilities have been solved, and now it's
an issue of the code itself having problems with compatibility, so if you would
like to fix and maintain unixware support, be my guest. The makefiles appear to
have incompatibilites commented out and replaced with portable statements, so
maybe the *BSDs will be able to use their native make now? In any case, I'd
like to have this merged.
Have you tried this on a BSD system like FreeBSD?
As for a lightweight system v, I think solaris would be your best bet, but why
not go for a modern opensolaris fork that is actually maintained like DilOS or
Tribblix (theres even a video of this one running CDE on youtube)?
Agree on that...
-jon
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 28, 2021 1:27 AM, Lev <int...@mailbox.org> wrote:
Hi Chase,
Apologies, I haven't been able to spend as much time working on CDE and the
Korn shell as I would like recently.
I wanted to let you know that I couldn't use the autoconf v. 2.63 bundled
with Oracle Linux 6 (i386):
configure.ac:3: error: possibly undefined macro: AC_CONFIG_MACRO_DIRS
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
Like last time, I had to hack the configure script to work around missing
dependencies, but I encountered this Xinerama-related build failure
right away:
/bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H
-I. -I../../include -DANSICPP -DMULTIBYTE -DNLS16 -DOSMAJORVERSION=4
-DOSMINORVERSION=15 -g -c -o DtXinerama.lo DtXinerama.c libtool:
compile: cc -DHAVE_CONFIG_H -I. -I../../include -DANSICPP -DMULTIBYTE
-DNLS16 -DOSMAJORVERSION=4 -DOSMINORVERSION=15 -g -c DtXinerama.c -KPIC
-DPIC -o .libs/DtXinerama.o UX:acomp: ERROR:
"../../include/DtXinerama.h", line 38: cannot find include file:
<X11/extensions/Xinerama.h> UX:acomp: ERROR:
"../../include/DtXinerama.h", line 43: Syntax error before or at:
XineramaScreenInfo UX:acomp: ERROR: "../../include/DtXinerama.h", line
43: cannot recover from previous errors
However, I was able to compile a randomly selected library (DtMrm),
which seems like a major improvement. Thanks!
Although UnixWare has been convenient for me to test against on hardware
I own, my preference would be to have a lean, open source SVR4 system
someday that anyone can use. What do you think of Solaris? I've been
running version 8 lately and found it to be pretty similar to UnixWare,
but I do not know what the legal situation is with the earlier source
code releases.
Also, I found out that libXfont is not taking advantage of FreeType's
support for using the now unpatented bytecode interpreter. I think it is
a rather substantial improvement and could help with internationalizing
CDE, because some of the free Microsoft web fonts, like Tahoma, support
many Unicode scripts within a single font. Also, the CJK bitmaps, MS
Gothic, SimSun, PMingLiu, and Gulim, take heavy advantage of the
bytecode interpreter from my understanding. I've attached a patch and
some examples.
--8<---------------cut here---------------start------------->8---
--- src/Freetype/ftfuncs.c
+++ src/FreeType/ftfuncs.c
@@ -3136,7 +3136,7 @@
int face_number, ttcap_spacing;
struct TTCapInfo tmp_ttcap;
struct TTCapInfo *ins_ttcap;
- FT_Int32 load_flags = FT_LOAD_DEFAULT; /* orig: FT_LOAD_RENDER |
FT_LOAD_MONOCHROME */
- FT_Int32 load_flags = FT_LOAD_TARGET_MONO; /* orig: FT_LOAD_RENDER |
FT_LOAD_MONOCHROME */
char dynStrRealFileName = NULL; / foo.ttc */
char dynStrFTFileName = NULL; / :1:foo.ttc */
char *dynStrTTCapCodeRange = NULL;
--8<---------------cut here---------------end--------------->8---
Unlike bitmap fonts that have to be digitally recast for each pixel
size, using a bytecoded TrueType font would allow for arbitrary scaling
using the X11 core font subsystem. I imagine that it would look quite
nice on a HiDPI display.
Thanks,
Lev
P.S.: For anyone else interested in obscure Unix systems, I've gotten
the Jam build system to work with old K&R compilers, even ones like
ULTRIX/VAX's that do not support string literal concatenation, etc.
It also now features support for recursively scanning includes for IFFE
headers and generating the appropriate configuration.
It's on GitHub at lkujaw/jam.
Chase writes:
Here is also another patch that might hopefully make some progress on
generating makefiles with unportable statements, lev, would you care to tell me
if this commit changes anything when building on unixware with a pregenerated
configure script?
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 14, 2021 6:52 PM, Chase via cdesktopenv-devel
cdesktopenv-devel@lists.sourceforge.net wrote:
ugh, CTRL+enter is never consistent between apps.
1. libmmdb.a is now built inside DtMmdb, since building sources outside of the
directory messes up dependency tracking
2. the pmaker and dfiles programs seem to generate files that have no
differences between platforms, so therefor lets just commit them.
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 14, 2021 6:49 PM, Chase nicetry...@protonmail.ch wrote:
Some notes:
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 14, 2021 4:48 PM, Jon Trulson j...@radscan.com wrote:
Go ahead and post a patch... Not sure when I can take a look, but the likely
issue is the order of the libraries on the link line.
-jon
On 3/11/21 4:06 PM, Chase via cdesktopenv-devel wrote:
By the way, I have made Makefile.am for the dtinfo program (not dtinfogen) that
compile, but I can't get the convenience libraries to work, they keep
outputting missing symbols as errors. I can provide a patch if anyone is
interested/willing to take a look.
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, March 9, 2021 6:15 PM, Chase nicetry...@protonmail.ch wrote:
The wiki says the user should create /var/spool/calendar for proper calendar
functioning, lets do this for the user instead upon installation.
Thank you for your time,
-Chase
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
--
Jon Trulson
"Entropy. It isn't what it used to be."
-- Sheldon
X-No-Archive: Yes - savehttp://groups.google.com/
--
Jon Trulson
"Entropy. It isn't what it used to be."
-- Sheldon
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
