Hi Chase, I sincerely doubt that autoconf works anymore on half of the systems they list, and from what I’ve seen of bug reports, they either don’t respond or tell users their system is the problem. I could probably check later to see if the existing CDE autotools branch is compatible with Thomas Dickey’s autoconf fork, which he maintains because upstream has broken compatibility with so many platforms. Unfortunately, he doesn’t maintain a fork of automake. The problem is that we’d be stuck using old autotools constructs forever (I think Debian ships Dickey’s fork just for ncurses and xterm), and distributors won’t want to ship something they can’t run autoreconf on with the latest autoconf. Apparently configure scripts are one of the most popular places to hide malware.
I think it’s possible to do everything that autotools does with imake and iffe (which we already ship), there’s support upstream for cross-compiling, and BSD users could continue to use native tools. Even MacPorts ships imake, so couldn’t we use an external copy if it’s available? As far as custom configuration goes, just use sed on the .cf files or ship a small configure script for people who can’t be bothered. Kind regards, Lev > On Feb 6, 2021, at 15:24, Chase <nicetry...@protonmail.ch> wrote: > > My purpose is not to decrease supported operating systems with the > introduction of automake. Automake was (at least in theory) supposed to be a > build system that we wouldn't have to maintain ourselves with the most > supported operating systems that could be build projects without the tools > even being installed, plus features like cross compiling, custom directory > installation and in line changing of compilers and other resources that would > require the user to change the config file with automake. If older versions > of GNU make and autoconf work for you to build CDE, then what is the issue? > We could simply just make sure we don't introduce any features that were > implemented after a certain release. Its either that or you tell GNU about > the issues. They advertise everything from AIX3 to z/OS unix being supported, > so it would really make me scratch my head if they suddenly decided they > didn't want to do compatibility with old operating systems anymore. > > > Thank you for your time, > -Chase > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Saturday, February 6, 2021 4:08 PM, Lev <int...@mailbox.org> wrote: > >> Hi Chase, >> >> I am not sure what behavior GNU is expecting, but older releases of GNU make >> and autoconf worked fine. It seems that if the purpose of autoconf is >> increased portability, the onus should be on them to repair breakages, not >> on vendors who have customers demanding compatibility with decades old UNIX >> behavior. Ultimately the choice is yours if these systems are worth >> supporting or not, but if CDE is going to drop support, why not switch to >> something like meson, which is where Xorg is going? Most projects are trying >> to migrate away from autoconf to cmake, meson, etc. >> >> Kind regards, >> Lev >> >>> On Feb 6, 2021, at 14:40, Chase nicetry...@protonmail.ch wrote: >>> Keyword directory. An empty argument != directory. I have a hard time >>> believing that Xinuos would let their OS become unusable for automake, have >>> you emailed them at all about the issues you've been facing? >>> Thank you for your time, >>> -Chase >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Saturday, February 6, 2021 3:30 PM, Lev int...@mailbox.org wrote: >>> >>>> Hi Chase, >>>> I just tried to build GNU make on UnixWare and it errors out right away: >>>> ../build-aux/depcomp: line 126: syntax error at line 127: ‘done’ unexpected >>>> I don’t think UNIX compatibility is really a GNU priority unfortunately… >>>> It is actually documented in the System V interface Definition (Volume II, >>>> page 128) that: >>>> “If the removal of a non-empty, write-protected directory is attempted, >>>> the command will always fail (even if the -f option is used), resulting in >>>> an error message.” >>>> This behavior was POSIX compliant until 2017, and I have a hard time >>>> believing that the committee did not even consult the SVID. >>>> Kind regards, >>>> Lev >>>> >>>>> On Feb 6, 2021, at 13:55, Chase nicetry...@protonmail.ch wrote: >>>>> While this is impressive, it still won't be relevant for very long due to >>>>> our impending transition to autotools, did you ever get that make=gmake >>>>> hack to work? I was also thinking that a good way to solve the rm problem >>>>> would be to build the upstream ksh and link it to /bin/sh, since their rm >>>>> is builtin and conforms to POSIX. >>>>> Thank you for your time, >>>>> -Chase >>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>>>> On Saturday, February 6, 2021 1:09 PM, Lev via cdesktopenv-devel >>>>> cdesktopenv-devel@lists.sourceforge.net wrote: >>>>> >>>>>> Hello, >>>>>> This patch allows for parallel ‘make World’ with imake. >>>>>> If we are interested in cross-compilation support, I could work on that >>>>>> as well. >>>>>> 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
