The geoclue2 service is a D-Bus service, so it's relevant only for
native builds, particularily for (GNU/)Linux. I haven't checked whether
we do any checks for Darwin and do conditional compilation with or
without enableGeoLocation, but in any case it's not relevant, because it
would have failed nevertheless even before this change.

Signed-off-by: aszlig <[email protected]>

Our stdenv currently only passes the cross compilation options/flags to
autotools and friends and doesn't include cmake. So until we have
implemented a generic hook for cmake, let's set it directly here until
we have the necessary patience to fix this for cmake directly.

Signed-off-by: aszlig <[email protected]>

ALSA is only relevant on systems running with a Linux kernel, and
cdparanoia and libXv are *nix/BeOS-only. We could have more fine-grained
checks here and also add exceptions for other plugins, but the base
package is usually the one used by most packages, such as webkitgtk.

Signed-off-by: aszlig <[email protected]>

This fixes errors in conjunction with gnulib, for example:

error: expected '=', ',', ';', 'asm' or '__attribute__' before
'gl_msvc_invalid_parameter_handler'
gl_msvc_invalid_parameter_handler (const wchar_t *expression,
error: 'gl_msvc_invalid_parameter_handler' undeclared (first use in this
function)

Not sure whether it makes sense to jump to version 0.19.x, but for now
I'm avoiding that to ensure we don't break unrelated stuff.

Signed-off-by: aszlig <[email protected]>

For native builds, this of course isn't a problem, because all
buildInputs no matter whether native or not are handled the same way.

This is fine if you just use gettext utilities in cross builds, but not
for glib, which links against gettext.

Signed-off-by: aszlig <[email protected]>

Tools such as flex or bison just need to be available for generating
stuff during the build, so it doesn't make sense to cross-build them.

Signed-off-by: aszlig <[email protected]>

We already set a cross-compile prefix via a configure script option, so
if we have a CC which includes the prefix as well, we'll end up having
things such as x86_64-w64-mingw32-x86_64-w64-mingw32-gcc. And that's
obviously not what we want.

Signed-off-by: aszlig <[email protected]>

Gnome support means linking against the Gnome Keyring library, which for
example on Windows isn't available, so let's avoid that by enabling it
only when we're doing native builds.

Signed-off-by: aszlig <[email protected]>

Fixes undefined references to __imp_xmlFree, which happens due to wrong
linking flags.

Signed-off-by: aszlig <[email protected]>

Here we pass an absolute set of dependencies, because it doesn't make
sense to throw in a whole bunch of conditionals for checking against
Windows cross builds.

Signed-off-by: aszlig <[email protected]>

I'm not quite sure whether we can really build iconv for mingw-w64, but
it seems to have a hard-dependency on Linux headers, so let's leave it
out.

Signed-off-by: aszlig <[email protected]>

On Windows, we *usually* don't have CUPS, and I'd imagine that GTK+ uses
the Windows internal printing backend.

Signed-off-by: aszlig <[email protected]>

So far I didn't get graphite2 to compile using mingw-w64, so until we
get it to compile I think we can live without it for now.

Signed-off-by: aszlig <[email protected]>

Obviously, X libraries aren't available for Windows. There are X servers
for Windows though, but that's not what we'd usually want.

Signed-off-by: aszlig <[email protected]>

`concatMapStringsSep` actually needs a function to work on the list
items, but it was probably a leftover from the refactor in af8654d.

Signed-off-by: aszlig <[email protected]>

We have quite a lot of the following:

stdenv ? cross && stdenv.cross.libc == "msvcrt"'

... and similar in nixpkgs, which is not only error-prone (oh, damn,
typo in "libSystem"), but also very repetitive.

The default values for the generic stdenv are set to false, so the we
can use these checks even outside of crossAttrs.

Signed-off-by: aszlig <[email protected]>

As promised in the previous commit, this should finally get rid off all
the repetitive mess and should lead to much more readable package
definitions.

There are still some leftovers from the old mingw32 stuff, which I
didn't replace, because they're quite old and probably unused.

Signed-off-by: aszlig <[email protected]>

The last real change on this was in 68a6fa7 and even the upstream
project doesn't seem to be maintained anymore. I asked @rbvermaa a while
ago whether it can be removed and I *think* the answer was yes (don't
have backlog of it).

It's however one of the last things which still uses the old mingw32
bits, so we should be close to removing it entirely.

Signed-off-by: aszlig <[email protected]>

Otherwise, Boost.Build is trying to compile against pthread and
desperately searches for icu/iconv.

Signed-off-by: aszlig <[email protected]>

I guess the "set -x" was only left there for debugging, so I'm removing
it because it let's the scrollback buffer explode ;-)

Signed-off-by: aszlig <[email protected]>

The upstream sources only compile with masm, so we need to add a patch
that translates the masm sources to GNU assembler. Unfortunately, this
means, that "generic.nix" is no longer very much generic, but the
versions we currently include work fine with the patch.

Unfortunately, the boost build still doesn't finish, but we're getting
there soon enough.

The patch is from https://svn.boost.org/trac/boost/ticket/7262 and
following the discussion it seems that the upstream authors are
unwilling to add a gas version for the Windows platform. So in the long
term we might need to find a better solution to that, like for example
using Wine to run MASM.

Signed-off-by: aszlig <[email protected]>