Re: configuguration tools, Portable Software (was: fledgling assembler programmer)

In article 23-03-037,
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2023-03-28, Aharon Robbins <arnold@freefriends.org> wrote:
>> Today, the C and C++ worlds are easier to program in, but it's still
>> not perfect and I don't think I'd want to do without the autotools.
>> Particularly for the less POSIX-y systems, like MinGW and OpenVMS.
>
>Counterpoint: Autotools are a real detriment to GNU project programs.
>
>When a release is cut of a typical GNU program, special steps
>are execute to prepare a tarball which has a compiled configure
>script.
>
>You cannot just do a "git clone" of a GNU program, and then run
>./configure and build. You must run some "make boostrap" nonsense, and
>that requires you to have various Autotools installed, and in specific
>versions!


This is not inherent in the autotools; it's laziness on the part of the
maintainers. For exactly this reason gawk has a very simple bootstrap.sh
program that simply does a touch on various files so that configure will
run without wanting to run the autotools.


>Most Autotools programs will not cleanly cross-compile. Autotools is the
>main reason why distro build systems use QEMU to create a virtual target
>environment with native tools and libraries, and then build the
>"cross-compiled" program as if it were native.


QEMU wasn't around when the Autotools were first designed and
implemented. Most end users don't need to cross compile either, and it
is for them that I (and other GNU maintainers, I suppose) build my
configure scripts.


Yes, the world is different today than when the autotools were
designed. No, the autotools are not perfect. I don't know of a better
alternative though. And don't tell me CMake. CMake is an abomination,
interweaving configuration with building instead of cleanly separating
the jobs. Not to mention its stupid caching which keeps you from
running a simple "make" after you've changed a single file.


>My TXR language project has a hand-written, not generated, ./configure
>script. What you get in a txr-285.tar.gz tarball is exactly what you
>get if you do a "git clone" and "git checkout txr-285", modulo
>the presence of a .git directory and differing timestamps.
>
>You just ./configure and make.


And for gawk it's ./bootstrap.sh && ./configure && make
where bootstrap.sh only takes a few seconds.


>None of my configure-time tests require the execution of a program;
>For some situations, I have developed clever tricks to avoid it.


And why should you, or anyone, be forced to develop such clever tricks?


All of this simply justifies more the approach taken by newer languages,
which is to move all the hard crap into the libraries. The language
developers do all the hard work, instead of the application developers
having to do it. This is great for people who want to just get their
job done, which includes me most of the time. However, and this is a
different discussion, it does lead to a generation of programmers who
have *no clue* as to how to do the hard stuff should they ever need to.


My opinion, of course.


Arnold
--
Aharon (Arnold) Robbins arnold AT skeeve DOT com

Return to the comp.compilers page.
Search the comp.compilers archives again.