Have you tried reporting any of these issues to the GNU project? I feel like reporting/fixing it upstream would be significantly less of a time sync and would be beneficial for everyone to have the makefiles be posix compliant and such.
Thank you for your time, -Chase ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, January 28, 2021 8:03 PM, Lev <int...@mailbox.org> wrote: > 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
