Based on ca0c2efe7a. Credits go to flacs.
However, unlike the original commit, hidapi does not completely replace
the current implementations, so we can still connect Wiimotes with 1+2
(without pairing).
Also, it is only used on Linux and OS X for now. This removes the
advantage of having only one implementation but there is no other
choice: using hidapi on Windows is currently impossible because
hid_write() is implemented in a way that won't work with Wiimotes.
Additionally:
* We now check for the device name in addition to the PID/VID so we can
support the Balance Board and maybe third-party Wiimotes too. This
doesn't achieve anything with the DolphinBar but it does with hidraw.
* Added a check to not connect to the same device more than once.
Adds a link check in to the LLVM find script to make sure it can actually link against the library it finds.
Noticed this issue since I have a non-standard LLVM version built and installed.
Ubuntu 14.04 has miniupnpc 1.6.3
REGEX was failing because the string was empty, causing cmake to
error and not generate a Makefile.
This allows systems with older versions of miniupnpc to fall back
to the statically linked version in externals.
miniupnpc.h provides MINIUPNPC_API_VERSION since 1.7 and we require 1.7
or later, so there is no reason to have version detection code for older
versions.
Adds a cmake module to correctly discover OProfile and adjusts the
corresponding CMakeLists to make use of it. Additionally removes
linking against the bfd library when compiling with OProfile because
Dolphin does not use it.
For some dumb reason, llvm-config doesn't provide the flags to link
against the dynamic library copy of LLVM (as opposed to static), so the
script has to guess the library name. However, in some installations
(such as mine), there is no dynamic copy, which caused Dolphin to fail
to link. Change the script to do a link test. If it fails, one option
would be to fall back on static linking, but I just have it fail to
detect LLVM, because statically linking Dolphin against LLVM is really
not a great idea - huge binary, long link time.
Not deleted, because it's the only option for some other operating
systems such as FreeBSD or any other slightly exotic operating
system someone might try and run dolphin on.
This fixes detection of at least libenet via pkg-config, and I think
libpng via pkg-config pulseaudio via direct detection.
Also remove the NOT APPLE from the shared libenet check, because there's
no reason for it.
- all files converted to unix line endings
- files from other subsystems and most of system have been removed
- include/SFML/System.hpp and include/SFML/Network.hpp modified to
not include removed stuff
- IpAddress.*pp renamed to IPAddress.*pp to workaround git apply bug
with case-only renames
I must have had a dirty cmake configuration which didn't encounter this issue.
Make sure we are using LLVM_DEFINITIONS to know where we are linking to libraries at.
Link against libLLVM-${VERSION}, the other one was linking us against static libraries...
This will work for all of our platforms, x86, ARMv7, and AArch64.
Main issue with this is that LLVM's cmake files aren't correctly finding the LLVM install.
Not sure if this is Ubuntu's issue or not, it may just work on other operating systems.
We could potentially improve this, you can pass in a specific CPU in to the LLVM disassembler. This would probably affect latency times that are
reported by LLVM's disassembly? This needs to be further investigated later.
- strip down PolarSSL's CMakeLists.txt
- switch to the PolarSSL 1.3 API
- use entropy interface instead of havege (PolarSSL 1.3 has disabled
havege by default because it is "considered unsafe for primary usage")
- add VS2013 .vcxproj file
is at least 1.8 and has the methods of glew 1.9. This is an annoying
hack to deal with Ubuntu's glew setup, which is glew 1.8 with 1.9
methods patched in.
Florent Castelli