meson when compiling something with 'native: true' (for building
executables that are meant to be run on the host system) uses CFLAGS
and CXXFLAGS environment variables, we "pollute" them with
TARGET system cflags/cxxflags, such as -march= for the cross-compiled
arch.
so to fix it we export CFLAGS and CXXFLAGS to be CFLAGS_host and
CXXFLAGS_host respectively, they are set by XBPS and correspond to
the XBPS_CFLAGS/XBPS_CXXFLAGS. This same set of changes is also done
with CC and CXX see L#61
this was found when cross-compiling lighttpd which created the
'lemon' executable to generate inputs
thanks to @Cogitri from Exherbo for helping me debug this
[ci skip]
following https://mesonbuild.com/Cross-compilation.html
- host_machine is our XBPS_TARGET_MACHINE
- build_machine is our XBPS_MACHINE, and meson can find out the details
on it's own
- also don't include -musl in the CPU because meson doesn't recognize it
and projects like Mesa (LibGL) don't enable optimizations for it
- cpu_family and cpu are different, they need to be set properly:
- armv* is arm
- mips* is mips
- i686 is x86
- x86_64 is x86_64
- aarch64 is aarch64
There is no need to use a custom build directory for python{2,3}-only
modules.
This indirectly fixes our issues with packages that use distutils-extra.
Instead of relying on qtchooser to provide the link to the qmake
binary for Qt4 or Qt5 test for either version and use that.
Sometimes qtchooser can fail if e.g. a package was built with Qt4
and after that another package with Qt5 without zapping the masterdir.
Many packages depending on Qt5 or Qt4 and built with cmake
generate "flags.make" files with -isystem for include paths.
With gcc6 this results in e.g. "#include_next <stdlib.h>" giving
an error, because a -isystem /usr/include is in the wrong place.
The simple fix is to replace "-isystem" with just "-I".
in order to make gufw installation process work, it includes itself
while installing. this raise the need that the build directory needs
to be a valid python identifier too. this commit solves this issue.
- python_module build style now builds modules for python2/3 by default
- new python2_module and python3_module build styles for building
python2-only and python3-only packages respectively
- no more python_versions
- no need to define pycompile_version for Python modules anymore
(still needed for non-Python modules though)
- Python version and paths are now guessed automatically and a set of
useful variables can now be used in templates
- #!/usr/bin/python2 and #!/usr/bin/python3 are now the default shebangs
- /usr/bin/foo2 and /usr/bin/foo3 are now the default names for bin
scripts (for use with alternatives)
