1. They (and the others) all use PerMachineDefaultable. It's not the
best class, but consistency come first. (It and all of them can be
improved accross the board later.)
2. They use `None` as the default argument so as not to mutate what's
effectively a global variables. (Thanks @dcbaker!)
3. They have a `fallback` field to centralize authority on when
environment variables should be consulted.
First of all, I'd like compilers and other modules that environment.py
currently imports to be able to take these without creating
hard-to-follow module cycles.
Second of all, environment.py's exact purpose seems a bit obscured.
Splitting the data types (and basic pure functions) from the more
complex logic that infers that data seems like a good way to separate
concerns.
Fix get_library_dirs() on FreeBSD to only return /usr/local/lib,
/usr/lib and /lib as the default location to look for libraries.
FreeBSD does not use lib/${platform} or lib64 by default. In general,
those directories should not exist, but in case they do, ensure they're
not picked up.
Fix defaul_libdir() on FreeBSD. The current behaviour of using
usr/lib64 if that exists is wrong on FreeBSD. The default should be to
always use usr/lib, even if usr/lib64 exists as a folder in the file
system. Fix this by checking if we're running on FreeBSD and then
always return 'lib' in default_libdir().
This does two things:
* On windows GCC-like compilers, the subsystem is always explicitly
specified (either -mwindows or -mconsole). MSVC is already explicit.
* The gui_app linker flags are now added after those mandated by
external dependencies. This is because some misguided libraries (such
as SDL) think that hijacking `main()` and forcing `-mwindows` in link
flags is clever. We must unconditionally override such misuses to let
gui_app work as intended.
'c_arg' entries should become *both* compiler options and external
peprocessor options for C. (And likewise for a few other languages.)
Seems inconsistent to me, but this is the status quo.