Hi Chase, I ran autoreconf on Linux and copied it over to my UnixWare system. After manually patching the ‘configure' script to work around new build requirements like Xinerama, pkg-config, and freetype, the build fails because it tries calling the am—refresh target and it can’t find aclocal. Touch’ing all the files solved that issue but the automake-generated Makefiles contain macros that do not function with UNIX make, like $< outside inference rules; this leads make to run commands that are missing their arguments. In contrast, cde-2.2.1 mostly works once BOOTSTRAPCFLAGS are properly defined. Sadly, I don’t see how this endeavor is going to work in the long run, especially if autoconf drops compatibility with the SVR4 utilities (the reason for the ‘rm’ warning.)
When I have more time, I think I will pivot towards getting the new ksh93 working without regressions on UnixWare and other SVR4 platforms first. Perhaps the best approach later is to configure Imake with iffe (possibly sync’ing the defines with the autoconf one for source code portability), restore Motif's Imake support, and backport bug-fixes to 2.2.1 as part of a "CDE classic" project that bundles dependencies like Tcl and patches for these systems. Kind regards, Lev > On Jan 27, 2021, at 19:32, Chase <nicetry...@protonmail.ch> wrote: > > Not to my knowledge, no. I wonder, would committing the configure file > alleviate any of the issues you have with the autotools? If we commit the > configure file, you wouldn't need to install the autotools or m4 (you'd still > need it to build nsgmls but hopefully we will get rid of this soon for system > onsgmls) to build in theory. I was actually going to propose to do this a > while ago so that the future debian package wouldn't depend on the autotools > but I was busy with the whole ksh replacement project. > > > Thank you for your time, > -Chase > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Tuesday, January 26, 2021 10:23 PM, Lev <int...@mailbox.org> wrote: > >> Hi Jon and Chase, >> >>> On Jan 26, 2021, at 18:56, Jon Trulson j...@radscan.com wrote: >>> On 1/25/21 8:54 PM, Lev wrote: >>> >>>> Hi Jon, >>>> Thank you for committing that, it should be the last ksh93 patch. Did you >>>> get a chance to look at the other five patches I sent on 17th? I don’t >>>> believe they are in yet. >>> >>> I must have missed them... I remember skipping some of them because I had >>> already applied them. If I look at the log in master, there are several >>> patched from you regarding musl... >>> If there are some I missed (possible since some of them were embedded in >>> threads), re-send them (minus any ksh stuff) and I'll merge them. >> >> Thanks, I’ve attached the (rebased) patches. >> >>>> I don’t know if this got lost in the shuffle, but since you mentioned >>>> potentially fixing autoconf as an alternative to imake, I am curious if >>>> you have any thoughts on Thomas Dickey’s fork of autoconf 2.59 >>>> (https://invisible-island.net/autoconf/ >>>> ). I doubt I would be able to match the excellent work he’s done in order >>>> to keep xterm and ncurses compiling everywhere (even OS/2 and VMS), but as >>>> far as I can tell, upstream is not interested in these patches. >>> >>> Ahh... no I wasn't proposing to take over autoconf development :) >>> There is another CDE branch called autotools-conversion. A lot of work is >>> already done and most of CDE can be built. I just need to get that finished >>> and then the imake support would be removed and the result merged into >>> master. This probably won't happen for awhile, so imake is safe for now :) >> >> Alright, I think that was a misunderstanding on my part on then. The >> incompatibilities aren’t with CDE’s autotools support but the autotools >> themselves. About the ‘adopting imake’ comment: I tried to get some context >> on what spurred the autotools conversion in the first place and found ’The >> sorry state of imake’ thread. Chase, if you wouldn’t mind, was Alan >> Coopersmith still looking for a maintainer last time you spoke? >> >>>> Also, if you don’t mind my asking, whatever happened to Accelerated-X? It >>>> seems that X.org >>>> development is slowing considerably with the ascendance of Wayland. >>> >>> XiG died in 2012... It was a good run. It's the second company I worked for >>> that I got in early, and then had the misfortune to ride it down into the >>> dirt. I have several million shares if anyone's interested... :D >>> But WRT Wayland, I've been hearing that it's going to kill X11 for over a >>> decade now. I will believe it when I see it :) >>> But yeah - no one is 'innovating' in X11 anymore, it's "Done". >>> One thing I really depend on a lot is the ability to run X11 apps over the >>> network. I do not think that is possible in wayland - maybe via their >>> Xwayland stuff? Haven't really looked very deep into Wayland in a few years. >>> -jon >> >> Sorry to hear that. Did anything survive regarding its architecture? I >> remember it required a kernel module, but I can’t remember the reason why >> instead of writing to the card’s framebuffer in /dev/mem. I wonder if X11 >> could have taken a different path, and I imagine you have a unique knowledge >> of the history behind the X Consortium, XFree86, and the rebranding/merger >> ofX.org. As a software engineer, did you have any impressions/opinions >> regarding XIE, STSF, and Display Postscript? XRender and Xft do not really >> seem to mesh well with X11’s client-server architecture. >> >> Kind regards, >> Lev >> >>>> Kind regards, >>>> Lev >>>> >>>>> On Jan 23, 2021, at 17:11, Jon Trulson j...@radscan.com >>>>> wrote: >>>>> On 1/18/21 8:21 AM, Lev via cdesktopenv-devel wrote: >>>>> >>>>>> Here’s a revised copy of the ksh fixes I submitted before that properly >>>>>> tests for POSIX-compliant terminal handling capabilities rather than >>>>>> attempting to get OLDTERMIO working. I think these patches are ready to >>>>>> be committed. >>>>> >>>>> Sorry I missed this one. I've added it to master. However, I think any >>>>> future ksh changes should go to the ksh93 maintainer... I'd like to get >>>>> Chase's ksh tree merged to master soon... >>>>> Thanks! >>>>> -jon >>>>> >>>>>> Kind regards, >>>>>> Lev >>>>>> >>>>>>> On Jan 17, 2021, at 19:17, Lev via cdesktopenv-devel >>>>>>> cdesktopenv-devel@lists.sourceforge.net >>>>>>> wrote: >>>>>>> Hello, >>>>>>> I am now able to compile CDE on Void PPC with musl. In the future, it >>>>>>> might make sense to create a PpcLeArchitecture for Alpine Linux (also >>>>>>> using musl) for CI with a minimal image. >>>>>>> Kind regards, >>>>>>> Lev >>>>>>> <0001-Fix-warnings-on-PowerPC-builds-and-correct-a-compile.patch><0002-The-musl-C-library-does-not-define-MAXNAMLEN-but-we-.patch><0003-The-musl-C-library-requires-the-inclusion-of-the-SVR.patch><0004-Include-config.h-for-the-definition-of-u_int.-Proper.patch><0005-Disable-binding-a-privileged-client-port-with-rresvp.patch>_______________________________________________ >>>>>>> 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 >>>>>> -- >>>>>> 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 >>> >>> -- >>> 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
