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
