On 1/18/21 5:58 PM, Chase wrote: > I would like master to be merged, yes. I am a bit confused though, > what constitutes a path forward? I have satisfied all of the testing > requirements (minus NetBSD), and I can't find any of the regression > test faults that Marcin was talking about by using libc malloc. This > would eliminate our need for a ksh to build with for dtksh (and it > could probably be easily removed elsewhere as well), as ./bin/package > was written to be shell agnostic. I could also start working on > autotooling it when it gets merged. >
A path forward... good question. I tried to merge master into this but had a ton of conflicts due to the recent changes to the ksh in master. I don't have time to go through them ATM. But - when I do, I can merge this into master as along as people are happy with it. I still have not tried as I've not had the time. Also, Lev's ksh changes would be removed... Is that something we are ok with? Swapping out ksh in master is a big deal. -jon > Thank you for your time, > -Chase > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Monday, January 18, 2021 6:48 PM, 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> >>>> <mailto: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> >>>> <mailto: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 >>>>>> <mailto: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 >>> <mailto: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 >> > -- 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
