The point of MSYS(2) is that the most effective cross-platform build
tool ever written for gcc-alike compilers is still autoconf,
automake, libtool, and pkg-config. Like it or not, they “work” (as
well as they ever work) everywhere, EXCEPT WINDOWS. And like it or
not, nobody has really produced a good and functional alternative
that can really claim to do the same thing.
CMake promised that, and it might have delivered if it hadn’t tried
to basically be XSLT for build systems, with lots of obsolete docs on
their own web pages for supported but niche features, oh, and that
they didn’t grab onto the idea of pkg-config and get with that tool’s
devs to turn their config file format into a toolchain-agnostic
resource so that complex build scripts weren’t needed.
I realize I’m going off on a bit of a rant here, but think about it?
SDL’s build system is too complex for automake because it handles
some unusual stuff when you’re not doing Linux builds. Plus, I think
Sam despises automake with a burning passion hotter than an emacs vs.
vi flamewar. But that’s likely only because of all the ridiculous
things automake has to do in order to work everywhere.
Still, let’s look at SDL’s configure.in, shall we?
- A hack to try and preserve user requests for build options
- Setting build version
- Configuring libtool
- Figuring out host/target for cross-compiling
- Figuring out what the installed build system is
- A hack for a UNIX tool too dumb to handle Windows paths on Windows
- Check for Mercurial so you don’t destroy the official autoconf setup.
- A hack because autoconf might be running under cygwin to bypass using it
- A CFLAG override mechanism
- Hack to find system files like X11 because there’s no standard here
- Setting toolchain environment based on what we know so far
- Hack for x64 Linux dists that use lib and lib64 rather than lib and lib32
- A function to find a library (because this isn’t automake)
- Checks for compiler options (can’t divine them anywhere)
- Option for debug/assertion level
- Check for toolchain dependency tracking for make
- Check for linker flag support
- A test for libc
- A test for a gcc feature
- Definition of what files to build (rare for a configure, but okay?)
- Optional features with their default settings
- Override for OSS on OpenBSD, how to do PulseAudio on Solaris properly, etc?
- Check for Wayland
- Check for Mir
- A comment questioning how to link Mir on BSD and OS X
- Check for NaCl
- Complex check for X11 because autoconf’s own still can’t always find it, let alone its various libs
- Hacks for two OSes’ locations for X11 libs by hand
- A custom check for the Raspberry Pi’s(? I think anyway) EGL video driver
- Checks for other video driver support (OS X, Haiku, etc)
- Checks for OpenGL, OpenGL ES, a random sound driver which seems to be in an odd spot in the config, etc
- Checks for dbus, Linux events, udev, etc
- A long list of OS-specific options for how to do pthreads (how p are they again?)
- Test for Windows and specific checks for its build system and libs
- Test for dlfcn and how to use it
- Test for BSD USB driver
- Test for how to do precise timing
- Test for Linux version availability
- Option to disable RPATH on systems that use it
- A whole bunch of system-specific configuration options
- A whole bunch of SDL buildsystem-internal regex line noise
- Writing files
- Telling the user what we did
More or less.
If you had something like CMake’s compiler definition files included
with gcc, clang, llvm, and their like in a common format, along with
the rest of the toolchain, that’d be a lot. Get support for that
into autoconf alone and rest assured that people WOULD start using
them in other build systems because they’d support just about
everything but the odd Microsoft compiler or the occasional non-gcc
UNIX compiler from Oracle, Intel, or HP that don’t see much use
anymore. And anyone who DID use them would quickly produce shims for
them because it’d make them instantly work with all of those build
Develop a standardized pkgconf format that is platform-agnostic and a
means to know how to register it with the system, with the existing
pkgconf as a reference implementation and watch it become even more
widely used than it already is. In fact, if you extend the idea to
support registering more than just how to compile and link a library
and you’ve got gold.
A way to find X11 (provided by whatever installed it for you), its
headers and libs in general, and also the specific header or lib for
a given X extension? Or OpenGL with a vendor string (Mesa, NVidia,
Apple, etc), where the libraries and headers are, specifics for
things like cg or cuda as well as glX, wgl, and other system glue.
Oh, and a thing to query for the kinds of glue available in
preference order. (The Mac has a few options, for example?) Another
nice subsystem to standardize would be audio since there are many
options and they now emulate one another pretty frequently.
I’m oversimplifying it a little I know, but not as much as I’ll be
said to be doing.
JosephOn Thu, Dec 25, 2014 at 03:20:14AM +0400, Alexander Sabourenkov wrote:
MSYS? Is it still alive?
Five years ago I remembered what niche MSYS filled. Ten years ago I even
Today - what is the point? All that time wasted on setting it up is worth
tens of Linux VMs, maybe thousands.
Also - always build out-of-tree - makes cleanup entirely free of side
SDL mailing list
SDL at lists.libsdl.org