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.
- 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.
Gregory Hainaut