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.
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)? 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/ _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
