Hi Jon, Thanks for the explanation, I can understand wanting to switch to a more common build system. Could I volunteer to maintain a branch of CDE for what might be considered legacy systems? I would really like the opportunity to work on improving CDE, including making dtterm more VT100 compatible.
Kind regards, Lev > On Jan 18, 2021, at 17:48, Jon Trulson <j...@radscan.com> wrote: > > On 1/18/21 9:31 AM, Lev via cdesktopenv-devel wrote: >> Hi Chase, >> >> Thanks to your advice about the submodule, I was able to make some progress. >> Unfortunately, I am now getting a lot of errors from the headers, e.g.: >> [...] >> I had been hoping to get a Motif 2.1 compatible version of CDE working on >> UnixWare, but I believe these changes, using autoconf and an out of tree >> ksh, are going to pose significant challenges for the future portability of >> CDE because it would be contingent on support by other projects. A similar >> transition by >> X.org >> resulted in OpenBSD implementing their own makefile build system with >> Xenocara, and I have had experience with autoconf releases after 2.13 >> turning into an effort trying to debug some rather inscrutable m4. Imake, >> for all its limitations, generates easy to understand Makefiles, is simple >> to configure manually if need be, and only assumes a knowledge of make and >> the cpp. >> >> What would your advice be for anyone wanting to continue using CDE on >> platforms that are unsupported by the autotools or ksh? >> > > Well, autotools is they way we are heading. There is already quite a lot of > work already done on the autotools branch. imake is dead and is very hard > for new users to 'get'. I intend, once everything can be built from > autotools (see the autotools-conversion branch), to completely remove all > that is imake from the tree once and for all. IT sucks. It requires special > syntactic C preprocessor behavior. I have no intention of continuing to > support imake once we can safely ditch it. > > For ksh, we can stick with the iffe stuff it is using now, until they > (upstream) change it to something else. Even in the current master - we just > call the ksh build scripts from Imake. We will do the same from autotools. > If some day ksh moves to autotools or something else, we can just arrange to > call it, whatever it winds up being. > > As for running on platforms unsupported by autotools - sorry, do we care? I > know unixware used to support it, I used to run unixware... 20 years or so > ago... If the OS is not being updated, why would we waste time appealing to > the lowest common denominator? > > I know ksh is a problem and it always astonished me that we actually needed a > running ksh on the system in order to build CDE. That is a dep we should get > rid of. We should not need ksh to build ksh, or any other part of CDE if we > can avoid it. > > So - I will hold off on applying patches until we have a path forward. > Chase: If you would like I can update the master-ksh93-upgrade with latest > master. Let me know. > > -jon > >> Kind regards, >> Lev >> >> >>> On Jan 17, 2021, at 20:13, Chase <nicetry...@protonmail.ch> >>> wrote: >>> >>> I would not get too ahead of yourself with that, we are planning on making >>> the jump to the gnu autotools pretty soon, imake has a multitude of issues >>> that, if we want to see significant progress in the fields of OS packaging >>> and cross compiling, it will need to be done away with. Upstream might >>> appreciate any help with turning nmake into plain makefiles or autotooling >>> it however. It also just occured to me why your build was failing, after >>> you checkout master-ksh93-upgrade, make sure you do "git submodule update >>> --init --recursive" or else git will not pull in the submodule, thats why >>> your ./bin/package was missing. If you still have technical problems with >>> it afterwards, maybe this commit from att ksh could help >>> https://github.com/att/ast/pull/260 >>> >>> >>> >>> Thank you for your time, >>> -Chase >>> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Sunday, January 17, 2021 9:02 PM, Lev >>> <int...@mailbox.org> >>> wrote: >>> >>> >>>> Hi Chase, >>>> >>>> I am thinking of revamping the bundled dtksh to build directly with imake >>>> instead of nmake, using a ksh93 configure script to generate a .cf file >>>> with the appropriate defines as a replacement for iffe. If this isn’t the >>>> ksh 2020 fork but the new ksh 93u one, backporting the fixes shouldn’t be >>>> too difficult because they basically started from scratch to my >>>> understanding. >>>> >>>> Kind regards, >>>> Lev >>>> >>>> >>>>> On Jan 17, 2021, at 17:28, Chase via cdesktopenv-devel >>>>> cdesktopenv-devel@lists.sourceforge.net >>>>> wrote: >>>>> Lev, >>>>> This is a known issue with upstream ksh93: >>>>> https://github.com/ksh93/ksh/issues/3 >>>>> , maybe I am being a bit inconsiderate, but I think that the benefit of >>>>> us not having to maintain our own decade old out of tree fork of ksh93 >>>>> anymore is a worthy trade off for musl support. Could any of your most >>>>> recent patches be applied upstream? I saw that you did edit a few files >>>>> in the ksh93 tree. >>>>> 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 > > _______________________________________________ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
