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.
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
>>>>> 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
