On 1/18/21 6:13 PM, Lev wrote: > 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.
Sure... I would just create a fork though. Unfortunately I do not have the ability on SF to create branches and then let someone have control over them... -jon > 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 -- 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
