Several people had trouble building against systemwide installed libs.
And even if the build succeeds, the resulting bundle would not work on
other Macs.
Our code does not compile when HAVE_XRANDR=1 and HAVE_X11=0.
This combination would not normally exist, but on OS X we skip the X11
check so it is possible for X11 to be "not found" even when the OS does
support it. On OS X 10.6 this was not a problem because XRANDR is not
detected there, but apparently on OS X 10.7 XRANDR is available.
I incorrectly assumed that since wx 2.8.8 lacked wxAuiToolBar, the entire 2.8.x
series lacked it. In fact in wx 2.8.9 this feature was added.
Thanks to Glenn Rice for spotting this issue.
If we are actually missing symbols because a required architecture is missing
from a library, we'll get a link error as usual, so suppressing this warning
is pretty safe.
The "dsptool" executable is not included in the bundle.
The "tester" executable is not included in the bundle and it no longer
installed on other platforms, since it is neither expected nor useful
to install unit tests.
The following changes were made:
Restricted the "-march=core2" option to i386 because the first Intel Macs
had Intel Core CPUs, not Core2.
Removed the "-mdynamic-no-pic" flag as GCC lists it as a PPC specific flag.
Removed "-Wl,-read_only_relocs,suppress" because it seems to be related
to "-mdynamic-no-pic" and I see no need for it.
Removed "-Wextra-tokens -Wnewline-eof" because they are GCC specific and
not OS X specific.
Previously, there was just one list of frameworks regardless of which part
of the code depended on which frameworks. Now we keep separate lists for
the Dolphin core, the Dolphin GUI and internal use by wxWidgets.
Flags in CMAKE_CXX_FLAGS are passed to both compile and link commands.
A cleaner solution would be to use set_source_files_properties().
However, currently there are headers (StdThread.h, maybe more) that contain
Objective syntax. So it is not easy to determine exactly which source files
should be compiled as Objective C/C++ and that set can quickly change when
certain #include directives are modified. The solution for that would be to
move all uses of Objective syntax to implementation (.cpp) files and then
apply set_source_files_properties() to those.
If the systemwide wxWidgets is too old, we can fall back to the version
from Externals instead of letting the build fail.
Note that while the version in Externals appears to be wxWidgets 2.8,
it has post-2.8 features manually added to it (wxAuiToolBar), so the
version check only accepts 2.9 or higher.
Also, don't check to see if a directory is a wad file. They aren't. This removes an annoying and invalid debug assertion with the debug build.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7682 8ced0084-cf51-0410-be5f-012b33b47a6e
Also move the primary translation pot file to the external repository to facilitate updating translations when strings in the code are changed. Now the only time the primary dolphin repository needs to be changed for translations is when a new language is added.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7438 8ced0084-cf51-0410-be5f-012b33b47a6e
Now po files can be updated as often as we want without bumping up the svn revision numbers of dolphin itself. I left the dolphin-emu.pot and primary build files in the primary dolphin-emu svn. The dolphin-emu.pot file will still need to be updated on occasion to reflect changes to strings in the program. The gettextize script will still work as before for this.
Also added Arabic translations to the build thanks to mansoor.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7343 8ced0084-cf51-0410-be5f-012b33b47a6e
Update several of the other languages.
Fix those pesky DSPIntUtil.h compiler errors.
Clean up some remnants of building the plugins in the primary CMakeLists.txt file.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7127 8ced0084-cf51-0410-be5f-012b33b47a6e
Pierre Bourdon