Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Newsgroups: comp.compilers Subject: Re: configuguration tools, Portable Software (was: fledgling assembler programmer) Date: Sun, 02 Apr 2023 08:56:48 GMT Organization: Institut fuer Computersprachen, Technische Universitaet Wien Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <23-04-003@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> <23-03-037@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="6239"; mail-complaints-to="abuse@iecc.com" Keywords: tools Posted-Date: 02 Apr 2023 07:33:43 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:3446 Kaz Kylheku <864-117-4973@kylheku.com> writes: >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! And the problem is? The git repo contains only the source code, useful for developers. The developers have stuff installed that someone who just wants to install the program does not necessarily want to install. E.g., in the case of Gforth, you need an older Gforth to build the kernel images that contain Forth code compiled to an intermediate representation. Therefore the tarballs contain a number of generated (or, as you say, "compiled") files, e.g., the configure script, the kernel images in case of Gforth, or the C files generated by Bison in case of some other compilers. If you go for the "git clone" route rather than building from the tarball, you don't get these amenities, but have to install all the tools that the developers use, and have to perform an additional step (usually ./autogen.sh) to produce the configure file. "make bootstrap" is unlikely to work, because at that stage you don't have a Makefile. I remember "make bootstrap" from gcc, where IIRC it compiles gcc first (stage1) with the pre-installed C compiler, then (stage2) with the result of stage1, and finally (stage3) again with the result of stage2; if there is a difference between stage2 and stage3, something is amiss. Anyway, tl;dr: If you just want to do "./configure; make", use the tarball. >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. Clever! Let the machine do the work, rather than having to do manual work for each package. >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. That's the way to do it. Your idea seems to be that, when the value is not supplied, instead of a safe default (typically resulting in not using a feature), one should base the values on the configuration name of the system. I think the main problem with that is that for those systems most in need of cross-compiling the authors of the tests don't know good values for the configuration variables; for linux-gnu systems I usually configure and compile on the system. >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: Great! Now we need someone who has enough time to replace the AC_CHECK_SIZEOF autoconf macro with your technique, and a significant part of the configuration variables that have to be supplied manually when cross-configuring Gforth become fully automatic. - anton -- M. Anton Ertl anton@mips.complang.tuwien.ac.at http://www.complang.tuwien.ac.at/anton/