* Refactor build.sh. Restructure finding plugins. Remove legacy code. Add --clean-plugins option. Document --no-trans option.
Don't do setcap if dev9ghzdrk isn't being built. List dependencies if they are missing. Remove code related to zerospu2, and misc plugins we aren't building. Minor message changes.
in the top-level source directory. The build folder should NOT be
transferred between computers when PGO is used, though I don't
see why anyone would be doing so anyway.
Also adds support for PGO and LTO to the build.sh script.
Doesn't fully work yet
* Unknown stack frame
* Outside any known module
Potential root cause:
* Nvidia driver
* VU code as ebp is required for emulation so likely no frame
My reasoning was off. The -m flag does avoid the clang-tidy startup
cost (which isn't large), but it also increases tail latency because it
allows a straggler command to run much longer. Suppose that many heavy
.cpp files are bundled into one clang-tidy invocation.
Bench from Greg
with -m
./build.sh --dbg --clean --no-simd --clang-tidy 3886.45s user 12.04s system 1066% cpu 6:05.71 total
without
./build.sh --dbg --clean --no-simd --clang-tidy 4297.51s user 41.70s system 1497% cpu 4:49.86 total
1. All POSIX shells support $(...) syntax [1], including /bin/sh. shellcheck
warns about it.
2. [[ won't work in /bin/sh [2], so use [ everywhere. I wonder why it worked
now, perhaps the test was running on a system where /bin/sh -> /bin/bash.
3. In POSIX sh, string indexing is undefined. [SC2039]. Unfortunately, this
means we require a subprocess: https://wiki.ubuntu.com/DashAsBinSh. Very
ugly.
4. In POSIX sh, arrays are undefined. We seem to use $flags as an array
after constructing it by string concatenation. I tried to verify that
this has the same effect as just passing the quoted string in bash:
bash-3.2$ flags="-DCMAKE_GOOK"
bash-3.2$ flags="$flags -DCMAKE_MOARMA"
bash-3.2$ flags="$flags -DCMAKE_URURURUR"
bash-3.2$ ./argv $flags
0: ./argv
1: -DCMAKE_GOOK
2: -DCMAKE_MOARMA
3: -DCMAKE_URURURUR
bash-3.2$ ./argv "${flags[@]}"
0: ./argv
1: -DCMAKE_GOOK -DCMAKE_MOARMA -DCMAKE_URURURUR
bash-3.2$ ./argv "$flags"
0: ./argv
1: -DCMAKE_GOOK -DCMAKE_MOARMA -DCMAKE_URURURUR
bash-3.2$
5. Enable exit on unknown variable (-u). All variables should be known,
otherwise we have an error in the script. shellcheck doesn't warn so I
think it's fine.
Apart from shellcheck(1), I also ran checkbashisms(1). The latter only
reported that "command -v" might not be available in other shells.
Apparently only ash(1) doesn't understand it.
NOTE: Why are we even trying to support pre-Mavericks (Darwin < 13) OSX? We
don't even support the most modern OSX (El Capitan) fully yet. OSX upgrades
are free and generally don't leave old machines behind. Most machines made
after 2009 can upgrade to El Capitan, AFAIK. I also believe that systems
that have all the utilities and libraries necessary to build PCSX2 will have
/bin/bash >= 3.x.
NOTE 2: Does cmake/ninja generate the same type of output in
compile_commands.json?
[1]: http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03
[2]: http://serverfault.com/a/52050
Quick benchmark. GCC debug mode
Full build: 6 second better, it can 2 additional cores :)
make : ./build.sh --dbg --clean 213.25s user 22.35s system 881% cpu 26.739 total
ninja: ./build.sh --dbg --clean 203.94s user 18.31s system 1085% cpu 20.474 total
No change build:: 1 second better :)
make -C build_dbg -j 16 install 1.51s user 0.34s system 206% cpu 0.898 total
ninja -C build_dbg -j 16 install 0.05s user 0.02s system 98% cpu 0.074 total
Various distribution still ship the true old shell to win 1 second at startup.
Besides, bash syntax is no way better
Not fully tested, some bashism might remain for some options but at least you can
do a standard build
Slow and generate a 100k log!
Better to fix cppcheck/coverity/gcc(/clang) report first.
Anyway, clang-tidy incorporates clang-modernize (port code
to use some C++11 features)
For older distribution you can still use SDL1.2
./build.sh ... --sdl12 ...
or
cmake ... -DSDL2_API=FALSE ...
Note: there is a hard dependency between WxWidget and SDL. If Wx is linked against
SDL1.2, you must use SDL1.2. Crashes are expected otherwise.
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.
Hamish