It'd be nice if we could use 'ARDOUR::config_dir_name' for this purpose (or perhaps 'PROGRAM_VERSION'). However, neither is implemented widely enough at present to make this practical. Keep an eye on them though, as possible future strategies.
Use the gcc visibility attributes when building with the MinGW compiler(gcc).
GCC also supports the __declspec syntax but it will not compile at the moment
until the issues(which may not even be exactly the same issues as with MSVC)
are resolved.
This is necessary to get the libmidi++ test to work as libmidi++ has
unresolved symbols in libtimecode. This was not a problem when libtimecode
was statically linked into libardour if the executable depended on both
libtimecode and libardour as the symbols would get resolved.
This is not true for the midi++ test case as it doesn't depend on libardour
Also as libmidi++ only references symbols from one object file in the
libtimecode static archive only that object file gets included/exported
from libmidi++.
This is fixed by adding a dummy reference to a symbol in the other object
file in the libtimecode static archive.
This avoids having to define define LIBFOO_DLL=1 all over the place. If we ever go with static libs we will
need to define LIBFOO_STATIC=1 but hopefully in some central location like the top level wscript.
Oh, and I also dropped support for gcc older than version 4.x because ardour will already not build
on such an old version.
This is slightly awkward. It is important that we only link once to the static lib. Doing this at executable link time did not
work, possibly because waf insisted on putting the two static libraries at the front of the link list. So instead libardour
is now the point where linkage to these libraries occurs (and nowhere else). This should never be changed unless the change
just moves the linkage point to another location.
Also fix a bug with the libardour version tha was picked up by waf 1.7
incoming MIDI data has to be parsed EVERY process cycle, not just when Slave::speed_and_position() is called.
The private MIDI::Parser owned by the MTC and MClck slaves was irrelevant, since the port has its own.
See comments in midi_port.h on the strangled inheritance heirarchy.
