Post by Aharon RobbinsPost by Hans-Peter DiettrichMy impression was that the FSF favors C and ./configure for "portable"
code.
Like many things, this is the result of evolution. Autoconf is well
over 20 years old, and when it was created the ISO C and POSIX standards
had not yet spread throughout the Unix/Windows/macOS world. It and the
rest of the autotools solved a real problem.
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!
In the past what I have done to build a GNU program from version
control, as a quick and dirty shortcut, done was to find the tarball
which is the closest match to the baseline that I'm trying to build
(e.g. of GNU Make or GNU Awk or whatever). Unpack the tarball over the
repository and run ./configure. Then "git reset --hard" the changes and
rebuild.
Most Autotools programs will not cleanly cross-compile. Autotools is tha
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.
Among the problems are in Autoconf itself. If it knows the program
is being cross-compiled, any test which requires a test program to be
compiled and executed is disabled. Since the output of that configure
test is needed, bad defaults are substituted.
For instance, about a decade and a half ago I helped a company
replace Windriver cruft with an in-house distribution. Windriver's
cross-compiled Bash didn't have job control! Ctrl-Z, fg, bg stuff no
workie. The reason was that it was just cross-compiled straight, on an
x86 build box. It couldn't run the test to detect job control support,
and so it defaulted it off, even though the target machine had
"gnu-linux" in its string. In the in-house distro, my build steps for
bash exported numerous ac_cv_... internal variables to override the bad
defaults.
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.
I have a "./configure --maintainer" mode which will require flex and bison
instead of using the shipped parser stuff, and that's about it.
You don't have to use that to do development work.
There is no incomprehensible nonsense in the build system at all.
None of my configure-time tests require the execution of a program;
For some situations, I have developed clever tricks to avoid it. For
instance, if you want to know the size of a data type:. Here
is a fragment:
printf "Checking what C integer type can hold a pointer ... "
if [ -z "$intptr" ] ; then
cat > conftest.c <<!
#include <stddef.h>
#include <limits.h>
#include "config.h"
#define D(N, Z) ((N) ? (N) + '0' : Z)
#define UD(S) D((S) / 10, ' ')
#define LD(S) D((S) % 10, '0')
#define DEC(S) { UD(S), LD(S) }
struct sizes {
char h_BYTE[32], s_BYTE[2];
#if HAVE_SUPERLONG_T
char h_SUPERLONG[32], s_SUPERLONG[2];
#endif
#if HAVE_LONGLONG_T
char h_LONGLONG[32], s_LONGLONG[2];
#endif
char h_PTR[32], s_PTR[2];
char h_LONG[32], s_LONG[2];
char h_INT[32], s_INT[2];
char h_SHORT[32], s_SHORT[2];
char h_WCHAR[32], s_WCHAR[2];
char nl[2];
} foo = {
"\nSIZEOF_BYTE=", DEC(CHAR_BIT),
#if HAVE_SUPERLONG_T
"\nSIZEOF_SUPERLONG_T=", DEC(sizeof (superlong_t)),
#endif
#if HAVE_LONGLONG_T
"\nSIZEOF_LONGLONG_T=", DEC(sizeof (longlong_t)),
#endif
"\nSIZEOF_PTR=", DEC(sizeof (char *)),
"\nSIZEOF_LONG=", DEC(sizeof (long)),
"\nSIZEOF_INT=", DEC(sizeof (int)),
"\nSIZEOF_SHORT=", DEC(sizeof (short)),
"\nSIZEOF_WCHAR_T=", DEC(sizeof (wchar_t)),
"\n"
};
!
In this generated program the sizes are encoded as two-digit decimal
strings, at compile time. So the compiled object file will contain
something like "SIZEOF_PTR= 8" surrounded by newlines. The configure
script can look for these strings and get the values out:
if ! conftest_o ; then # conftest_o is a function to build the .o
printf "failed\n\n"
printf "Errors from compilation: \n\n"
cat conftest.err
exit 1
fi
The script gets the SIZEOF lines out and evals them as shell
assignments. That's why we avoided SIZEOF_PTR=08; that would become
octal in the shell:
eval $(tr '\0' ' ' < conftest.o | grep SIZEOF | sed -e 's/ *//')
It also massages these SIZEOFs into header file material:
tr '\0' ' ' < conftest.o | grep SIZEOF | sed -e 's/= */ /' -e 's/^/#define /' >> config.h
if [ $SIZEOF_PTR -eq 0 -o $SIZEOF_BYTE -eq 0 ] ; then
printf "failed\n"
exit 1
fi
Here is how it then looks like in config.h:
#define SIZEOF_BYTE 8
#define SIZEOF_LONGLONG_T 8
#define SIZEOF_PTR 4
#define SIZEOF_LONG 4
#define SIZEOF_INT 4
#define SIZEOF_SHORT 2
#define SIZEOF_WCHAR_T 4
There is a minor cross-compiling complication in txr in that you need
txr to compile the standard library. So you must build a native txr
first and then specify TXR=/path/to/native/txr to use that one for
building the standard lib. Downstream distro people have figured this
out on their own.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca