Turns out that without HAVOK, we can't build the PhysicsExtensions_TPV; but
the viewer's build.sh is unaware of CMake switches set in autobuild.xml.
Passing those CMake overrides in build.sh allows us to test that setting
elsewhere in build.sh to skip the PhysicsExtensions_TPV step -- instead of
failing the build.
since we no longer support 32-bit Mac builds.
The old build-darwin-i386 directory name appeared in a shocking number of
files. Change CMake paths to use ${CMAKE_BINARY_DIR} -- or, when trying to
find the packages subdirectory, ${AUTOBUILD_INSTALL_DIR}. Change the rest to
at least look for build-darwin-*.
We never intend to support 32-bit Mac builds any more.
This change eliminates the autobuild warning about not finding darwin64 and
therefore falling back on plain darwin.
With the new autobuild command infrastructure, the quotes that used to be
necessary for correct command-line parsing are now actually undesirable: they
are passed literally to the command in question, causing (e.g.) cmake to
complain that although it knows of a generator called Xcode, there's no
generator called 'Xcode'.
autobuild 1.1 now supports expanding $variables within a config file --
support that was explicitly added to address this very problem. So now the
windows platform in autobuild.xml uses $AUTOBUILD_ADDRSIZE,
$AUTOBUILD_WIN_VSPLATFORM and $AUTOBUILD_WIN_CMAKE_GEN, which should handle
most of the deltas between the windows platform and windows64.
This permits removing the windows64 platform definition from autobuild.xml.
The one remaining delta between the windows64 and windows platform definitions
was -DLL_64BIT_BUILD=TRUE. But we can handle that instead by checking
ADDRESS_SIZE. Change all existing references to WORD_SIZE to ADDRESS_SIZE
instead, and set ADDRESS_SIZE to $AUTOBUILD_ADDRSIZE. Change the one existing
LL_64BIT_BUILD reference to test (ADDRESS_SIZE EQUAL 64) instead.
autobuild now passes a vector of arguments to the commands it executes,
instead of smashing everything together into a single string only to have
cmd.exe parse it back into individual arguments again. In general, this is a
good thing and more robust than before.
However, it surfaces the fact that sometimes people were lazy and encoded
things like "-configuration Release" or "-j 12" as single <string> elements in
the XML. When such things are handed to the command as a single argument string
containing a space, it can get confused.
Code (e.g.) <string>-configuration</string><string>Release</string> instead.
Nat Goodspeed