find_package(Git) is done in SearchForStuff it could be deleted over there
but it fits better there. The only thing this line did was saying git was
not found for a second time since if it was found then it never triggered.
.
Check for the existance of .git to avoid
fatal: Not a git repository (or any of the parent directories): .git
The goal is to reduce the burden for new architecture port.
Patch is mostly inspired from 3kinox initial patch. The diff are
*/ used ifdef instead of raw removal
*/ gui don't rely on UseMicroVU* option
*/ completely remove sVU_micro.* file
Call to vsnprintf update the gp_offset of the varargs (at least on x86_64 linux).
Therefore the 2nd call (because buffer was too small) uses out-of-memory arguments
We need to keep a local copy otherwise you will get an awful SIGSEV
Note: I'm sure we have same issue on plugins
* GTK3_API requires a wxWidget that support it too
=> avoid complexe compilation error
* SDL2_API requires a wxWidget without SDL support (wxUSE_LIBSDL = 0)
=> avoid run time crash
SDL check hypothesis: wx is linked against SDL1.2 and not SDL2. It would need to be improved on a distant future
This fixes it for build.sh and when not using build.sh (packaging).
.
Also fix native 32bit build which should also be broken and attempt to
predict the future and fix it for lib32-wx3.0. Worst case the filenames
have to be fixed which is trivial.
.
When wx2.8 support is dropped then only the lib32-wx3.0 IF should remain.
When crosscompilation support gets dropped then the first IF gets deleted
unless we also dropped wx2.8 support then everything gets deleted.
I only had to add "PATH_SUFFIXES SDL2".
.
include is superfluous
SDL2-2.0 is a distro specific convenience symlink. Use the correct one
as before.
.
I probably did this as an artificial way of disabling pkgconfig when cross
compiling and before disabling pkgconfig for all cross compiling but it's
wrong. I thought I had fixed this already.
User may forget or not know about -DUSE_CLANG=TRUE. It could probably
be always autodetected instead of requiring user input.
.
Trivial wording changes to compiler_version.
Tell the user to use CMAKE_TOOLCHAIN_FILE upon failure.
.
Cleanup detectOperatingSystem. Should be the same but adding
GNU and kFreeBSD from Debian and filtering out pre OS X Apple.
.
libaio is linux only. Also check for the correct header since
aio.h is the POSIX one. Both are in /usr/include/ anyway.
Only build core if (Linux AND NOT AIO_FOUND) == false.
.
Use Unix for GTK and X11. Macs has gtk-quartzs and xquartz or native X11.
*BSD, linux, etc should have both.
Even before this pull request it was required to set PKG_CONFIG_PATH
when cross compiling since pkg-config always searches for native
libraries. This would require to backup an already existing ENV
variable if present, detect the distro specific place the pkgconfig folder is,
and restore the original ENV variable if it was present. Cmake as shown in:
.
http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3df51470
.
added support for this but requires CMAKE_MINIMUM_REQUIRED_VERSION as 3.1
which is kind of strict since it was released 10 days ago.
.
To avoid the ugliness let just avoid pkg-config when cross compiling. This
means only EGL, SDL2 and GTK3 have to be updated since the rest work w/o
pkg-config.
- EGL is fixed with PR #409
- SDL2 is fixed here and it's trivial.
- GTK3 is non-trivial. For this one use pkg-config for native builds since
the .pc file is kept up to date automatically. For cross compilation
use the provided FindGTK3 which I made by using the sed documented
inside the file and updating the dependencies for GTK3. Since I checked
each and every single .pc file to make sure they are up to date this
should have the same behaviour as pkg-config. Prefer the .pc files for
native builds since it does not need to be manually updated and when
the native 64bit port gets finished all the cross compile options should
be removed which is quite easy since most of the code got moved to the
CMAKE_TOOLCHAIN_FILE.
Note:
Cmake Modules are BSD-3-clause therefore GPL compatible.
The obtained binaries before and after this commit are identical (sha1sum)
when compiled in Debian/Ubuntu/Fedora/ArchLinux.
.
The linker will always pick the 32bit libraries the only thing this does is
make sure we have all the 32bit dependencies installed. Basically we avoid
detecting the 64bit libraries and telling the users the 32bit libraries were
found. We always link with 32bit libraries therefore this avoids having to
wait 5-10min to just be told -lXXX is missing.
.
The only thing really needed are
set(CMAKE_LIBRARY_ARCHITECTURE "../lib32")
set(CMAKE_LIBRARY_ARCHITECTURE ".")
.
which basically ensures we don't pick 64bit headers since
CMAKE_LIBRARY_ARCHITECTURE always gets tested first and for some reason
FindGTK2 test searches lib64 first then lib32/lib. These values are hardcoded.
Right now these arch specific headers are not used but can't say this will
always be true.
.
FIND_LIBRARY_USE_LIB64_PATHS is not needed for native builds and it's covered
by CMAKE_SYSTEM_IGNORE_PATH.
.
NOTE:
We filter out lib32 because multilib is not compatible with multiarch.
- Fedora only needs --arch if cross compiling.
+ It's only used to select libdir so i386=i686=i986
- Messages are nice to debug build logs.
.
Everything seems to work unless some other distro broke. Other
distros need to add CMAKE_TOOLCHAIN_FILE or --cross-multilib if
they cross compiled amd64 -> i686.
- Update the build.sh and fix some typos.
+ Don't add the OSX ones because I have not tested them and it won't
even build anyway due to the libaio dependency. Needs to use POSIX AIO
or something else.
- They are rather simple and all the magic happens in two lines.
+ First line tells cmake to get ready to compile FOR linux or darwin.
It also sets CMAKE_CROSSCOMPILING to true which is the only way to
let cmake known that we are using stuff not from the host.
+ CMAKE_C_COMPILER/CMAKE_CXX_COMPILER are basically used to detect
the architecture of the target. Since I used generic cc/c++ the
hardcoded -m32 is needed to ensure we get TARGET=i386. Also
since I hardcode -m32 and use c++/cc it's to be noted that
we can only do i386->i386 (trivial), amd64 -> i386, and x32->i386.
.
Using something like i586-linux-gnu-{gcc,g++} would also work and
enable arm -> i386, etc but it's infeasible and impractical to do all
the combinations. File is simple enough that a distro or user can
create their own and cross compiling is rather tedious compared
to using a chroot to compile it.
- I tested it in Debian with "dpkg-buildpackage -ai386" but installing the
build dependencies was rather tedious.
http://www.vtk.org/Wiki/CMake_Cross_Compilinghttp://www.cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html
.
The official way that cmake does cross compiling is via the use of a
CMAKE_TOOLCHAIN_FILE. This has to be given by the user and can't be
included from within a Cmake file since setting up the toolchain has
to be the first thing that happens.
.
After the file is given and validated cmake behaves nicely and all the
workarounds and hacks are not really needed anymore.
.
The consequence of this change is that without this file cmake will
try to build for the HOST architecture as expected and with the file
it will build for the TARGET architecture of the given toolchain. Due to
this remove 64BIT_BUILD_DONT_WORK and just ERROR out if the user tries
in the same way as before.
Currently crosscompiling was broken since we detected the cpu of the host
not of the target. Building arm -> i386, i386->amd64, etc resulted in
interesting stuff.
.
CMAKE_HOST_SYSTEM_PROCESSOR and CMAKE_SYSTEM_PROCESSOR should have done this
but they are incredibly broken and unreliable. I use
CMAKE_HOST_SYSTEM_PROCESSOR just to retain the format of the old message
and is not used for critical stuff so it does not matter.
.
This code also allows scalability so that if one day in the very distant
and unlikely future the x86/x86_64 specific code gets made portable
by replacing asm/MMX/SSE*/AVX/etc code with generic/portable code then
it also would work on all architectures.
.
For *BSD/OS X it probably would need to use POSIX AIO instead of linux
specific libaio but that is a different issue.
.
Error out the x86_64 builds.
Also the 64BIT_BUILD_DONT_WORK option became obsolete more info in following
commit.
- Update copyright due to incoming changes.
- Don't support universal binaries until they actually work therefore
only allow 1 architecture in CMAKE_OSX_ARCHITECTURES.
- Don't allow an empty ARCH list.
We probably asked for ppc or ppc64 w/o support for it.
For now just dump the original and add the BSD-2-Clause.
.
It's GPL compatible so it's okay.
.
I was writting one myself but found this one and it handles apple
which I did not consider since I can't test it.
At PCSX2_ui.ini: default: GzipIsoIndexTemplate=$(f).pindex.tmp
The rules:
- must contain one and only one instance of '$(f)' (without the quotes)
- if starts with $(f) then it expands to the full path + file name.
- if doesn't start with $(f) then the path is ignored (name+ext only)
- if doesn't start with $(f) and ends up relative,
then it's relative to pcsx2.exe (not to cwd)
- No checks are performed if the result file name can be created, so the dir
should exist.
- PCSX2 will not try to rename/move older index files to the new name/location.
If it's modified - the user should take care of rename/move before loading
gzipped iso files or else it will create a new index according to the template
Examples:
$(f).pindex.tmp - the default - same dir as the iso, loads older index files.
$(f).pindex - a popular request.
cache.gz/$(f) - relative to pcsx2.exe (if the dir exists).
%appdata%/pcsx2/cache.gz/$(f) - should end up at the default install docs dir.
when running with --nogui, PCSX2 knows to exit when the GS window closes.
However, pressing esc (suspend) didn't close the window and instead hidden it.
As a result, PCSX2 didn't exit and remained a zombie process.
this patch closes the gs window on suspend in --nogui mode, which makes PCSX2
exit fully.
it's now also possibly to use --noguiprompt which prompts if esc will exit
PCSX2, and allows the user to abort the suspend and continue using PCSX2.
TODO: if PCSX2 was in full screen - then pressing esc exits full screen. it
would have been ideal to restore full screen, but for now it doesn't.
- don't display a message if the replacement is the same as the default.
- display a message if the key combination is unknown
- (same as before) display a message when replacing a shortcut
- also added PCSX2_keys.ini.default sample file with some help
The method of forcing first-time-wizard wasn't very effective because
1. it's ugly, and 2. after selecting the language at the wizard it either
imports the previous settings (together with the previous language thus
overriding the new language) or resets all other settings - which is not fun.
This patch uses a small dialog instead to only change the language, and within
it reuses the language panel from the first time wizard.
The code was searching only at the default paths for cheats and cheats_ws.
Now it's possible to set UseDefaultCheats[WS] at PCSX2_ui.ini to 'disabled'
and set a custom value to Cheats and/or CheatsWS and PCSX2 will respect it.
EGL sometimes is not found. Checklib 1st does
.
string(TOLOWER ${lib} lower_lib)
pkg_search_module(${var} QUIET ${lower_lib})
.
Therefore this part should be equivalent since we always compare lower.
.
This part seems to not find anything and then it does.
.
find_library(${var}_LIBRARIES ${lib})
.
Here it also does not find anything since it tries to find libegl
while the library is called libEGL therefore I changed the name to upper.
to avoid
_internal_message("-- ${lib} not found (miss lib)")
.
It could fail in the unlikely event that someone renamed libEGL to libegl.
This bug is triggered when you combine crosscompiling from amd64 to
i386 with Debian multiarch paths. For other distros it should work with
pkg_search_module normally.
It was added recently to the xDG specs
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
.
It should improve the discoverability of pcsx2 for gnome shell users in any
distro and Ubuntu users at the very least. It's unrelated to the menu
hierarchy so it does not need a special hack for OpenSuse. Also it should
not break anything.
.
It's an optional entry but the "gnome guys" really want software to use it
more.
.
It should be concise and not the name of the software so I just did
game;emulator; since for example gnome-chess uses game;strategy;.
Gregory Hainaut