The changes I intend to make are:
- supporting IPv6 by rebasing on https://github.com/freeminer/enet
- adding custom code for quick resending
Even if I manage to get the latter upstream (which I'd like to wait for
some testing before attempting), I don't know what the original author
might do with the former, so...
Leave an option to use it for the sake of Linux distros - this means any
changes must stay protocol compatible, and Dolphin must work around any
API incompatibilities (e.g. for IPv6).
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.
If we don't unset it, all the CMake checks will run with PortAudio
in the library list. This didn't affect those who had PortAudio,
but for select Debian systems without it, it breaks everything.
Since libcommon.a is also the last library to be linked, this has the
totally hacky but useful side-effect that it doesn't require people to
modify CMake files for temporarily adding VTune code to other Dolphin
libraries.
Changing PATH basically screws everything up, and while the attempt to
avoid MacPorts copies of system libraries was well-intentioned, it made
the OS X buildbot unable to pick up ffmpeg and libusb.
It's sufficient to put /usr first to make sure we use the system copies
of duplicated libraries.
DolphinQt:
* Make the connect() calls explicit, not automatic
* Follow better naming convention for the QActions
* Remove the Open action from the toolbar.
Dolphin[Qt|WX]:
* Move the "Skip Bundle" option to the root CMakeLists so that both DolphinQt and DolphinWX can use it.
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.
Yes, this is a fancy new feature, but our Wayland support was
particularly bitrotten, and ideally this would be handled by a platform
layer like SDL. If not, we can always add this back in when GLInterface
has caught up. We might be able to even support wxWidgets and GL
together with subsurfaces!
Jules Blok