[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 May 2012 18:54:08 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: configure script for musl (?!)
OK before anybody flips out, no, there's no autoconf. :-)
Partly as an exercise in learning the details of how users/systems
integrators expect "./configure" to work, and partly in the interest
of simplifying build/installation of musl, I've been playing around
with writing a configure script. It's a flat shell script written in
portable (POSIX) sh, and depending on no external programs except the
compiler whose characteristics are being tested.
What does this buy us?
1. Automatic selection of ARCH as long as the compiler supports the
GCC -dumpmachine option. This works even if $CC is set to a
cross-compiler.
2. Automatic selection of compiler options that can fix standards
conformance issues, like -ffloat-store or
-fexcess-precision=standard. I believe the latter is default with
-std=c99 for all compilers that support it, but testing for it
allows us to fallback to (better than nothing) -ffloat-store on
ones that don't. We could also add things like -frounding-math if
they're helpful without worrying about breaking build on compilers
that don't support them.
3. Automatic enabling of preferred warning options without breaking
build on older compilers that don't support them all, or becoming
spamming on newer compilers that need -Wno-* options to disable
some bogus ones.
4. Automatic enabling of debloating options when supported/possible
(like omitting DWARF2 stuff when debugging is disabled).
I'm going to start by committing some changes to Makefile with the
minimum invasiveness to support configure-like semantics in
config.mak. The key change needed is that we have to split up CFLAGS
so that overriding CFLAGS from the make command line does not remove
the essential options (like -std=c99, -ffreestanding,
-D_XOPEN_SOURCE=700, etc.) and break things horribly. I'm also making
some changes that make it easier to disable shared OR STATIC libs from
the build process if desired, and some general cleanup. My intent is
that these changes not break existing manually-written config.mak
usage at all.
After that, I'll post a draft configure script here, and if all goes
well, it can be committed and can serve as an alternative to the
manual configuration method (which will continue to work).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
