On Wed, Sep 13, 2017 at 10:01 PM, Helmut Grohne <hel...@subdivi.de> wrote:
> I'm not sure why you felt the need to append a version, but my attached > patch supports your need by adding a --gccsuffix option to debcrossgen > while defaulting to an unversioned gcc as is expected by most Debian > packages. I also made it honour the environment variables CC and CXX by > default. When compiling with Meson, CC and CXX must point to the native compilers, not to cross compilers. If the crossgen tool uses CC that means that debuild needs to first set it to the cross compiler, run crossgen and then set it to the native compiler. Is this a natural way of doing it for debuild or does it cause complications? > I took some time looking into the cpu and cpu_family variables and am a > little confused what to put there. Experimentation with native meson > shows the following strange results: Yes, we do indeed to some canonicalization here. In Meson terms the "cpu_family" means the CPU type that is native to the given platform, _not_ the CPU type of the kernel currently running. > mips mips64 mips64 > mipsel mips64 mips64 These should be plain mips (assuming that this is mips32 userland running on top of a 64 bit kernel). > powerpc ppc64 ppc64 Same here. We do the magic normalization here: https://github.com/mesonbuild/meson/blob/master/mesonbuild/environment.py#L162 This script should probably do the same thing as that one. With a bit of refactoring it could even import that function since it ships in the same (private) directory as the code itself. > I'm not sure why all the tools use absolute paths, but I implemented > that path lookup generically now. If it turns out to be unnecessary, you > can remove it. Some toolchains do not have different executable names for the compiler and cross compiler. Thus absolute paths are needed to ensure they do not get mixed up by accident.
