As a followup, the xterm author maintains his own autoconf forks at
https://invisible-island.net/autoconf/. They don’t hang on my system like the
newer ones shipped by m4 and nano.
Also, I tried iffe and it works like a charm even on the V7 Bourne shell. The
feature tests are also much nicer to write than their m4 equivalents, e.g.,
here’s the one I wrote for musl:
tst need64 -D_LARGEFILE64_SOURCE note{ off64_t necessary }end nocompile{
#include <sys/types.h>
typedef off64_t __ast_off64_t__;
typedef off_t __ast_off_t__;
extern __ast_off64_t__ x;
__ast_off_t__ x;
}end fail{
echo "#undef _typ_off64_t"
}end
Kind regards,
Lev
> On Jan 20, 2021, at 17:23, Lev <int...@mailbox.org> wrote:
>
> Hi Chase,
>
> It’s not that the autotools suite is bad per se, but my opinion is that
> they’re somewhat GNU-centric. For instance, trying to get it working on
> UnixWare (which still gets patches from Xinuos, and I wonder if they’d give a
> free license for CDE developers), it immediately errors out because of an
> incompatibility with ‘rm -f’ (you have to set ACCEPT_INFERIOR_RM_PROGRAM.) It
> then doesn’t want to work with UNIX m4, asking the user to install GNU m4,
> but then that requires autoconf too…
>
> I think you’ve done great work getting CDE to work with the new ksh93, and
> I’ve submitted a patch to get it working with UnixWare
> (https://github.com/ksh93/ksh/pull/159) and restoring ISO C90 support. In the
> process of porting it, I also found a stack corruption error, which goes to
> show that portability can potentially benefit all users.
>
> I don’t intend to compete with or split the CDE community or anything. My
> thought was that if I’m doing the work to port CDE, I might as well share it
> with others if the only alternative for them is no CDE at all. I still want
> to submit patches and consider this the CDE upstream and I apologize if I
> came across otherwise.
>
> Kind regards,
> Lev
>
>> On Jan 20, 2021, at 15:56, Chase <nicetry...@protonmail.ch> wrote:
>>
>> Lev,
>> I just don't understand what the big issue with autotools is. We gutted a
>> lot of the legacy OS code a few years ago (ultrix, unixware, even weird ones
>> like uxpds), but if someone were to want these platforms back, I feel that
>> using autotools would be an even better solution, since autotools supports
>> building and feature testing on all these platforms, and instead of having
>> big chunks of ifdef OS you can just implement features tests, whereas imake
>> stopped receiving updates in 2000, and imake in general stopped being
>> supported in 2014. I was the one that really spearheaded that we use
>> autotools since it has a much larger platform support base than cmake or
>> meson do, and I did so in case someone really wanted to bring back the old
>> platform support.
>>
>> I'd really like you to see the light on this one, if theres one thing that
>> CDE doesn't need, its a fork.
>>
>>
>> Thank you for your time,
>> -Chase
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Tuesday, January 19, 2021 10:52 PM, Lev via cdesktopenv-devel
>> <cdesktopenv-devel@lists.sourceforge.net> wrote:
>>
>>> Hello,
>>>
>>> I intend on porting CDE/Motif 2.1 to SVR4 and possibly other niche
>>> platforms, so I’ve set up a branch at https://github.com/lev105/cde-imake/
>>> so as to not interfere with the good work here to get CDE up to date with
>>> the autotools suite, etc.
>>>
>>> Without being able to test on a SVID3-compliant OS, it’s difficult for me
>>> to be able to gauge which changes risk worsening compatibility with older
>>> systems, and CDE is a wonderful, lightweight desktop for them. Like a lot
>>> of other folks, this will be something I balance in a small amount of free
>>> time, but I hope these efforts will be useful for others. I’ve already got
>>> fairly extensive changes to support compiling CDE on platforms without XPG
>>> internationalization, and I am going to try getting fixes upstream for CDE
>>> and ksh93 (looks like musl support has already been committed) if they fit
>>> within their respective roadmaps. Maybe I could adopt imake if there
>>> wouldn’t be any objection?
>>>
>>> Kind regards,
>>> Lev
>>>
>>> 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
