Well if you had it working before that is a bit concerning, but I am not sure
if it is a regression or something wrong with my environment. I would like a
jenkins setup if possible. As for only doing work on linux, since I am pretty
much the only one doing work on the autotools branch right now, I just kind of
do whatever I feel needs work, so I'd rather not limit myself. My main
objectives right now are increased portability, getting dtinfo to work, and
fixing our issues with variable substitution (setting CC to clang or tcc on
linux causes the build to fail). I would like to write out the builtin libc
tools baked into dthelp (this rswinton guy really likes reinventing the wheel)
and writing out some ifdefs to be feature checks instead, but I understand that
getting CDE to actually build is the priority right now.
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 28, 2021 4:01 PM, Jon Trulson <j...@radscan.com> wrote:
> On 3/28/21 2:39 PM, Chase wrote:
>
>> 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
>
> Well, crap. I had been testing it occasionally (needed gmake though) with
> success, but not recently. Guess maybe I should add the fbsd12 vm agent to
> the jenkins build for autotools-conversion.
>
> I use it for master build testing, but not autotools as that's still a work
> in progress. Maybe time to change that...?
>
> Or maybe we don't care for now and address the BSD issues once linux works?
> What's your thought on that?
>
> -jon
>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Sunday, March 28, 2021 1:55 PM, Jon Trulson
>> [<j...@radscan.com>](mailto: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
>
> --
> 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
