Just attempted it and I can't build anything with or without the patch, aclocal
says it needs gnu m4, but I already have gnu m4 installed...
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 28, 2021 1:55 PM, Jon Trulson <j...@radscan.com> wrote:
> 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>](mailto: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
