instead of all from {includes}/fdk-aac/ ; through elegant abuse of the
include guard, we can "patch" in our modified FDK_audio.h .
The most proper way to deal with this would very likely be to upstream
this stuff, and then to detect at CMake time whether the system has an
unmodified FDK_audio.h or not, and if it needs modification, to have a
script that generates a patched FDK_audio.h on the fly.
Notice that these changes are, by C and C++ standards, NOT safe in
theory, but will very likely be in practice: enum's underlying (as in:
with what kind of registers will functions be actually called in
assembly) data type depend on the number of elements in that enum.
In practice, these enums will pretty much always be passed as an int –
and that should be at least 32 bit for any system GNU Radio runs on.
Still, the compiler that built the fdk-aac library binary might, at some
point, decide that the enum guarantees that only the values specified in
the enum as he knows it can possibly be passed as arguments, and thus
e.g. omit some "impossible" ´if´ branches, so that this is really an
unsafe thing to do.
TAKEAWAY
Changes of this type break the API, and might break the ABI, of the
shared object (library) that we're linking against. It's generally
illegal to change the functional parts of a header of a binary library.
We might be getting away with this here, but it's by luck.
instead of all from {includes}/fdk-aac/ ; through elegant abuse of the include guard, we can "patch" in our modified FDK_audio.h .
The most proper way to deal with this would very likely be to upstream this stuff, and then to detect at CMake time whether the system has an unmodified FDK_audio.h or not, and if it needs modification, to have a script that generates a patched FDK_audio.h on the fly.
Notice that these changes are, by C and C++ standards, NOT safe in theory, but will very likely be in practice: enum's underlying (as in: with what kind of registers will functions be actually called in assembly) data type depend on the number of elements in that enum.
In practice, these enums will pretty much always be passed as an int – and that should be at least 32 bit for any system GNU Radio runs on.
Still, the compiler that built the fdk-aac library binary might, at some point, decide that the enum guarantees that only the values specified in the enum as he knows it can possibly be passed as arguments, and thus e.g. omit some "impossible" ´if´ branches, so that this is really an unsafe thing to do.
TAKEAWAY
Changes of this type break the API, and might break the ABI, of the shared object (library) that we're linking against. It's generally illegal to change the functional parts of a header of a binary library.
We might be getting away with this here, but it's by luck.