On Wed, 20 Jan 2021, Chase via cdesktopenv-devel 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.
This post is more about autotools and my personal experience, less about CDE. Until few years ago I insisted on having as little as possible to do with the autotools. Sure, ./configure and make were the way to go, but I never really wanted to dig into this. One day I learned autotools to some useful extent and even helped some projects to fix their problems with the stack but I have little experience with converting something big like CDE to autotools. I still don't "like" autotools and find them necessary evil for some cases, here is why: When we talk about autotools and we tell how great and useful they are, we usually mean autoconf. Autoconf is the best tool of the whole suite and it is really the "loss leader" of the bunch. However, as you go, you might be encoraged to add automake (the worst of all of them), libtool, maybe autoheader as well. This means a multistage file generation pipeline where sometimes even a simple compiler or linker call is replaced with some incomprehensible shell script and a much of stuff like ".lo" or ".la" files spread over all the directories. Getting to the bottom of it in case of serious trouble is horrible - wading through .am and .in files and tracing all of this to something that usually is something like, "oh, should I treat this library as the internal to my project or maybe not, how do I tell automake to stop doing this or that". Part of the problem is that those tools are geared towards GNU make, which lacks lots of higher level capabilities or library functions, like BSD make variants or even ksh's nmake do. You can't even "make -V variablename" to find out what is the final value of the variable. I am glad to hear that autoconf development took off again with a great effort and there was a new release recently. Portability of autotools is also a myth - people started adding some features from recent bash versions and didn't have opportunity to test it on dying platforms (no surprise). I was surprised to find out that even on an oldish Solaris I was having problems with libtool shell scripts. And this is by far better supported platform than, say, Ultrix. There are some more advanced issues with the autotools approach, like for example trying to find header files and libraries at all cost somewhere may lead to unexpected results when in-tree newer version should be used but instead some older ones that are already installed on the system keep getting being found and used instead. Most of those issues (also out of tree builds, cross-building) are solvable when the macros are written properly, but I think most people simple don't know how to apply all those considerations and caveats into working m4/whatever code. You have much more experience trying to get CDE running on strange platforms than I do; I was only having issues with getting the path to TCL libraries right, or sometimes it is hard to find which library gives us proper RPC. I think also that current imake configuration is ugly and structured badly, I wish I had something resembling BSD make's /usr/share/mk tree instead (https://cgit.freebsd.org/src/tree/share/mk). Having said that, I appreciate the time you guys are putting to push the project forward even if I somewhat dislike the autoconf way of doing things. The discussion would be fair if I had put a solution on a table to improve current imake definitons to fix the most obvious problems (not sure I even know the list of them! - anyone?). In the nmake and iffe documentation similar dislike of "the autoconf way" is expressed. The authors were well aware of autoconf and tried to find a better solution to the problem of portability. Sadly those tools became totally unknown and fell into obscurity so it is hard to expect they could become a viable alternative. Maybe one day someone comes with an iffe-based CDE build though :) saper
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
