Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Kaz Kylheku <864-117-4973@kylheku.com> Newsgroups: comp.compilers Subject: Re: configuguration tools, Portable Software (was: fledgling assembler programmer) Date: Wed, 29 Mar 2023 18:33:12 -0000 (UTC) Organization: A noiseless patient Spider Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <23-03-037@comp.compilers> References: <23-03-001@comp.compilers> <23-03-017@comp.compilers> <23-03-022@comp.compilers> <23-03-029@comp.compilers> <23-03-032@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="34614"; mail-complaints-to="abuse@iecc.com" Keywords: tools Posted-Date: 30 Mar 2023 20:23:14 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:3438 On 2023-03-28, Aharon Robbins wrote: > > In article <23-03-029@comp.compilers>, > Hans-Peter Diettrich wrote: >>My 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 #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: @Kazinator@mstdn.ca