Regular .h files *should* be self-contained and independent of previous
includes and guarded to only include once. Make it clear which files
that *doesn't* apply for at all.
the rest from `tools/convert_boost.sh`.
* replace boost::function, boost::bind with std::function and std::bind.
This required some manual fixes, notably std::placeholders,
some static_casts<>, and boost::function::clear -> = {}.
autowaf has no real shutdown functionality anyway. The automatic
shutdown function that could have been called wouldn't work anyway, as
it takes an argument.
The only reason it doesn't fail is that the top level wscript has no
shutdown handling and doesn't recurse to other scripts, so it is all
dead code.
Variables by these names are only used from the local wscript and when
running "waf configure", which already for other reasons only can run at
the top-level.
These variables are thus not mandatory and not used.
* reserve "probe" to actually probe for devices
* use separate probe for libusb and MIDI port devices
* use "available" to check if surface can be used
* allow both methods to be NULL
* remove unused ControlProtocolDescriptor* argument
Most surface just return `true` for available.
The Editor continues to notify them, but via a direct call to ControlProtocolManager, not a signal.
The CP Manager calls the ControlProtocol static method to set up static data structures holding
selection info for all surfaces and then notifies each surface/protocol that selection has changed.
This new design will work even when threads that need to receive
messages from RT threads are created *after* the RT threads. The
existing design would fail because the RT thread(s) would never
be known the later created threads, and so signals emitted by the
RT thread and causing call_slot() in the receiver would end up
being enqueued using a lock-protected list. The new design ensures
that communication always uses a lock-free FIFO instead
Those objects do not have a versioned API by themselves.
This fixes issues with duplicate deployment (OSX, Linux bundles: cp) and
ardour listing control-surfaces multiple times (file index plugin dir).
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.
svn+ssh://ardoursvn@subversion.ardour.org/ardour2/branches/build_fixes
........
r6292 | trutkin | 2009-12-05 08:31:25 -0500 (Sat, 05 Dec 2009) | 1 line
remove scons build files
........
r6294 | trutkin | 2009-12-05 09:11:17 -0500 (Sat, 05 Dec 2009) | 2 lines
cairomm
remove unnecessary vendor libraries as we now rely on the developer to install them
........
r6295 | trutkin | 2009-12-05 09:12:54 -0500 (Sat, 05 Dec 2009) | 2 lines
soundtouch
remove unnecessary vendor libraries as we now rely on the developer to install them
........
r6311 | trutkin | 2009-12-05 23:38:49 -0500 (Sat, 05 Dec 2009) | 2 lines
glibmm2, gtkmm2, libgnomecanvasmm, sigc++2
remove unnecessary vendor libraries as we now rely on the developer to install them
........
r6314 | trutkin | 2009-12-06 09:15:49 -0500 (Sun, 06 Dec 2009) | 4 lines
remove scons referencing from Makefile
- TODO: should move cscope stuff to waf and get rid of the Makefile
........
git-svn-id: svn://localhost/ardour2/branches/3.0@6315 d708f5d6-7413-0410-9779-e7cbd77b26cf
* Install ardour3_ui_default.conf to system config dir
* Set -DDATA_DIR etc. defines to proper absolute paths
* Set default MIDI control port name to "control"
(it was "control" some places, "default" other, so the generic MIDI
control surface didn't work. The real problem here is probably that
the name is hardcoded in the surface code, ick)
* Install surfaces to correct system directory
* Generate and install ardour_system.rc
User POV:
* Installed versions not run from the source directory discover configuration
files and surfaces, and generally work
* Building and/or starting a fresh copy of ardour3 with no pre-existing
configuration will run an ardour with a single MIDI "control" port, which
you can plug a surface into and control MMC and controllers and such
(after turning on the generic MIDI surface, which IMO should be loaded
by default anyway, especially since it's no longer in a menu)
git-svn-id: svn://localhost/ardour2/branches/3.0@5833 d708f5d6-7413-0410-9779-e7cbd77b26cf