On 1/28/21 7:03 PM, Lev 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
Yeah.. .this is an issue on the BSD's as well... I know for those you need to use gmake currently... like: ./configure MAKE=gmake gmake That works. I am not a make whiz, so I used what I had and what works. If we can replace the uses of $< with something that works on the native makes, I am all for it. Show me the way... -jon > 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 >> -- 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
