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
