Use of ccache on build host is now controlled by the
LOCAL_CCACHE_SUPPORT option. Setting it to "no" will disable use
of local ccache.
Signed-off-by: Matthias Reichl <hias@horus.com>
If LOCAL_CCACHE is set to the full path of ccache on the build host
it will be used for early stage host package builds, eg make and ccache
at the moment.
By default it uses a separate cache dir (.ccache-local) so that it
doesn't interfere with our ccache (which is typically a different
version). The location can be changed by setting LOCAL_CCACHE_DIR
Signed-off-by: Matthias Reichl <hias@horus.com>
This is needed for host packages built in very early stages,
before host-cc (which typically uses ccache) is available.
Set CC/CXX to LOCAL_CC/CXX in this case.
Signed-off-by: Matthias Reichl <hias@horus.com>
python's crypt module is deprecated in 3.11 and to be removed in 3.13.
Replace its usage with openssl's passwd.
Signed-off-by: Ian Leonard <antonlacon@gmail.com>
Default linker can be set with DEFAULT_LINKER in options.
Packages can influence linker selection both by positive and/or
negative PKG_BUILD_FLAGS, eg +bfd or -gold.
Positive build flags take priority over the default linker so eg
DEFAULT_LINKER="gold" and PKG_BUILD_FLAGS="+bfd" will select bfd.
Negative flags mean a specific linker should not be used, eg -gold
prevents using gold.
If the default linker is disabled via a build flag then any other
available linker will be used.
Optional linkers like gold have to be enabled with eg GOLD_SUPPORT="yes"
in options. If an optional linker is not enabled it won't be a candidate
for linker selection. So eg "+mold" will have no effect if MOLD_SUPPORT
isn't set to "yes".
Signed-off-by: Matthias Reichl <hias@horus.com>
Timing detail reporting can be enabled by setting
TRACE_BUILD_TIMING=1
This enables timestamping collecting at various build stages so we
can easily analyze how long eg configure, make/build, install etc
steps take.
Signed-off-by: Matthias Reichl <hias@horus.com>
march and mcpu were added in ~2011. I don't know why. I have seen CFLAGS added
en masse to LDFLAGS when using LTO, but that does not explain these inclusions.
Remove to cleanup LDFLAGS.
Signed-off-by: Ian Leonard <antonlacon@gmail.com>
was:
- OpenGL (GLX) support (provider): no (no)
- OpenGL ES support (provider): yes (mesa)
- Vulkan API support (provider): no (no)
is:
- OpenGL (GLX) support (provider): no
- OpenGL ES support (provider): yes (mesa)
- Vulkan API support (provider): no
* Initial fully buildable/bootable Odin Support
* Rework NX-Boot to FAT32 Boot for shared usage between switch and odin
* Move shared packages from switch/odin to main packages folder
uname options -p and -i are non portable and return "unknown" on
Linux with GNU coreutils as there's no OS support for it.
Note: some distributions like Fedora or Ubunto patch coreutils so
that uname -p (more or less) returns the machine name (uname -m output).
But that should not be used and fails on distributions like Debian
that don't add that patch.
Signed-off-by: Matthias Reichl <hias@horus.com>
If we build with `-Os` some vars are missing in backtraces and will be listed as `<optimized out>`
- https://github.com/PCSX2/pcsx2/issues/5226#issuecomment-1036987320
```
Optimize debugging experience. -Og should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is a better choice than -O0 for producing debuggable code because some compiler passes that collect debug information are disabled at -O0.
Like -O0, -Og completely disables a number of optimization passes so that individual options controlling them have no effect. Otherwise -Og enables all -O1 optimization flags except for those that may interfere with debugging:
```
- https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
