KS2011: Afternoon topics [LWN.net]

KS2011: Afternoon topics

Posted Oct 27, 2011 22:23 UTC (Thu) by nix (subscriber, #2304)
In reply to: KS2011: Afternoon topics by Cyberax
Parent article: KS2011: Afternoon topics

Why would I want to modify CFLAGS? Let's see. -fstack-protector, might want that if I want a bit of extra security. -fomit-frame-pointer, might want that if I like a fairly large speedup on x86-32. -g, might want that (particularly if I'm a distributor generating packages with separated debugging information). -D__NO_STRING_INLINES, might want that because the string inlines still slow glibc down more than they speed anything up in my benchmarks. -L and -I, might well need them if some packages are installed in non-standard prefixes. This is a small subset of the reasons I tweak CFLAGS, and most of them are applicable to any random distributor you could name.

Automake gets it *just* right: the CFLAGS, LDFLAGS and so on are propagated correctly, supplemented with makefile-specific flags for those targets where it is necessary, and possibly occasionally overridden for those very very few targets where that is necessary (though this elicits a warning). This is done *by default*: there is no need for the makefile author to hack about with anything or remember to do anything (which nearly all will of course forget).

Automake doesn't take any --with- switches at all: are you thinking of Autoconf? Even *that* only requires them if autodetection fails, in which case you are installing things in nonstandard prefixes and should expect to have to do things by hand.

Oh, and it doesn't require building any kind of 'executable tool' at all, only a portable shell script. The entire *reason* why configure scripts are a shell script is because the distributor / builder needs nothing but a shell and core Unix shell tools: they do *not* need Autoconf or Automake. For scons you need a whole flipping Python installation -- fairly common these days, you think? I wish you were right: Python is by no means ubiquitous. The shell is. Until recently Autoconf's shell requirements were so lax that it actually allowed Solaris 2.6-and-below /bin/sh, which doesn't support shell functions: so we're talking a 1980s shell here!

(Log in to post comments)

KS2011: Afternoon topics

Posted Oct 27, 2011 22:35 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> Automake gets it *just* right: the CFLAGS, LDFLAGS and so on are propagated correctly, supplemented with makefile-specific flags for those targets where it is necessary, and possibly occasionally overridden for those very very few targets where that is necessary (though this elicits a warning). This is done *by default*: there is no need for the makefile author to hack about with anything or remember to do anything (which nearly all will of course forget).

So create a proper configuration with these flags instead of hacking them in using command line or system environment. That way they'll be cleanly visible in the build file instead of being tucked-in in a some obscure driver script.

>Automake doesn't take any --with- switches at all: are you thinking of Autoconf? Even *that* only requires them if autodetection fails, in which case you are installing things in nonstandard prefixes and should expect to have to do things by hand.

Yes, sorry. Of course I meant autoconf, and you have to do a lot of --with if you try to do cross-compilation with even remotely non-standard libdirs.

>Oh, and it doesn't require building any kind of 'executable tool' at all, only a portable shell script. The entire *reason* why configure scripts are a shell script is because the distributor / builder needs nothing but a shell and core Unix shell tools: they do *not* need Autoconf or Automake.

Portable? They don't work with MSVC which is probably the most popular C++ compiler. I can hardly call them 'portable'. Even between Unix platforms it's a hit-and-miss - most Linux software requires tweaking to build correctly on HP-UX.

KS2011: Afternoon topics

Posted Oct 28, 2011 16:57 UTC (Fri) by nix (subscriber, #2304) [Link]

So create a proper configuration with these flags instead of hacking them in using command line or system environment. That way they'll be cleanly visible in the build file instead of being tucked-in in a some obscure driver script.

So... I pointed out that scons requires understanding and hacking every single build script rather than just putting configuration state in one centralized place (be that a site-config file, as, autoconf, or a wrapper that runs the tool, as cmake)... and you suggest that I should fix this by... understanding and hacking every build script!

I suspect that you don't understand what I'm driving at. A build system which requires distributors to hack every build script in order to make simple adjustments to flags and paths will never be popular among distributors, and packages that use it will forever be discriminated against and make packagers and builders despair when they meet them.

Portable? They don't work with MSVC which is probably the most popular C++ compiler.

Now I know you're just trying to win regardless of logic. POSIX programs are very rarely portable to MSVC: I can count the number of programs on my Linux system that can also be built with MSVC on the fingers of two hands (and if I rule out SDL and its subsidiary packages, that's one hand). Generally such packages need radical internal surgery to make them work on Windows at all, and working without an abstraction layer such as Cygwin is even harder.

So, sorry, portability to MSVC is rarely worth considering when looking at Unix build systems.

Even for such programs, msys provides a platform specifically intended to allow configure scripts to run. (It's not heavyweight.)

KS2011: Afternoon topics

Posted Oct 30, 2011 23:09 UTC (Sun) by cortana (subscriber, #24596) [Link]

Actually I believe there is work going into making Automake work with MSVC. With CC=cl, automake creates a 'compile' script in the source directory which takes GCC-like options and invokes MSVC with the equivalents (where possible).

KS2011: Afternoon topics

Posted Nov 23, 2011 22:33 UTC (Wed) by oak (guest, #2786) [Link]

> Oh, and it doesn't require building any kind of 'executable tool' at all, only a portable shell script. The entire *reason* why configure scripts are a shell script is because the distributor / builder needs nothing but a shell and core Unix shell tools: they do *not* need Autoconf or Automake. For scons you need a whole flipping Python installation

I think python-minimal is quite a bit smaller than POSIX base system (shell, perl, awk, GNU core utils etc). I don't understand why Autools generate scripts that are supposed to work with some foobar non-POSIX shells that don't support functions (which makes configure scripts pretty much unreadable), but then requires Perl etc.