This effectively reverts commit 0f02bbc2fe which was a horrible
kludge for JACK support on Windows. Maintaining this kludge doesn't
seem worth the trouble (the JACK version was never updated), and
apparently nobody uses this.
Boost makes building a piece of software much more difficult than
necessary. It's a huge library, and just uncompressing it takes a
considerable amount of time. MPD only used a tiny fraction of it, yet
its header bloat made the MPD build very slow. Locating Boost was
difficult due to its arcane build system and its resistance to use
pkg-config; it's always a special case. MPD could never use features
of newer Boost versions because Linux distributions always shipped old
Boost versions. Boost made everything complicated and slow.
So, finally, after getting rid of GLib (commit ccdb94b06c), switching
to C++ and using Boost (commit 0801b3f495), we've finally get rid of
it 8 years later.
Unfortunately, I had to reimplement parts of it along the way
(e.g. IntrusiveList). Kind of NIH, but on the other hand, compiling
MPD has become much easier for users.
This enables the JACK output plugin on Windows, but doesn't link
against libjack64.dll, instead loads the DLL at runtime with
LoadLibrary(). This kludge avoids the extremely fragile JACK shared
memory protocol by using the system's libjack64.dll, without requiring
the same DLL at build time.
This fixes the Windows build. Linking failed because some packages
(e.g. libFLAC) default to enabling `_FORTIFY_SOURCE`, which is broken
in recent mingw versions
(https://github.com/msys2/MINGW-packages/issues/5803).
So long, autotools! This is my last MPD related project to migrate
away from it. It has its strengths, but also very obvious weaknesses
and weirdnesses. Today, many of its quirks are not needed anymore,
and are cumbersome and slow. Now welcome our new Meson overlords!
configure.ac sets this, but this wasn't used for compiling third-party
libraries. This setting however is important for libnfs, which adds
fallback definitions for POLLIN and POLLOUT with bogus values.
Workaround for the following LAME build failure:
error: inlining failed in call to always_inline '_mm_sqrt_ps': target
specific option mismatch
This is because the LAME build scripts do not check whether SSE is
available; they only check for the presence of the "xmmintrin.h"
header.
Requiring a Pentium 3 CPU is reasonable enough, and it's the first CPU
to feature SSE support.
Enable it in the Windows build script, closes#78.
LAME currently doesn't support Android:
checking host system type... Invalid configuration `arm-linux-androideabi': system `androideabi' not recognized
Max Kellermann