
- #GIT WINDOWS ISSUES TO RUNNINGSOMEONEELSE SCODE INSTALL#
- #GIT WINDOWS ISSUES TO RUNNINGSOMEONEELSE SCODE SOFTWARE#
Note: this would assume they're also able to read and comprehend their compiler's source code, to prevent attacks like the Ken Thompson Hack (1984)
#GIT WINDOWS ISSUES TO RUNNINGSOMEONEELSE SCODE SOFTWARE#
Read the entire source code of all the software they use.First of all, because running someone else's binary is a security risk - it can get very hard to tell what a binary is going to actually do just by looking at it, and monitoring it isn't entirely failsafe either. There are many good reasons to build your own software. DCMAKE_INSTALL_PREFIX=$HOME/myprefix/chipmunk2dĪppendix to the appendix 1: Why build your own software? You can specify the installation prefix by setting the CMAKE_INSTALL_PREFIX variable: $ cmake. The usual CMake build process goes like this: $ cmake. This section assumes that you have read the autotools section above, which contains some fundamentals about prefixes and how software is built on Linux. Note: -prefix usually has to be an absolute path.īuilding each library in its own prefix is a good habit: it makes it immediately cleary which files belong to which library.įor the purpose of bundling your libraries, in this example, one would copy all files in $HOME/myprefix/sdl2/lib/ to their bundled library folder. # and then, make & make install, as usual With autotools, you can specify the prefix in the configure phase, with the -prefix flag: $. However, you can simply specify your own prefix, so that the built library is installed into an unprivileged, user-owned directory, ready for bundling with your games.
#GIT WINDOWS ISSUES TO RUNNINGSOMEONEELSE SCODE INSTALL#
The only reason sudo is required for the install step is because the default prefix is a system-wide directory that can only be written to by privileged users (like root). Binaries are installed in /usr/bin/ (or /usr/local/bin).

The default prefix is usually /usr, or /usr/local, which means: Their idea of a build process is in three steps: # gather information about the system, paths, dependencies

The most common form under which open-source software is distributed is probably using autotools. See the Distributing Linux builds page of this book autotools (./configure & make) If, instead of using a pre-made Game engine package like Unity, you prefer picking a few libraries here and there and mix them in your own way, you might reach a point where you want to build your own versions of those libraries, so that you may bundle them with your game.
