On Wed, Oct 11, 2017 at 8:23 PM, Helmut Grohne <hel...@subdivi.de> wrote:
>> Is cpu_family intended to describe a CPU family, or an ABI? Some CPU >> families have more than one incompatible ABI: > > It's not clear to me what the intention is. My experience matches yours > though: cpu and cpu_family are incapable of differentiating ABIs. Under what circumstances is this difference noticeable _inside_ the meson.build files (that is, the parts that developers write). Based on examples few projects seem to care on a level higher than "is this x86 or arm"? If Meson needs to do some magic for the compilation on behalf of users, we can and should do that behind the scenes correctly so users don't have to care. > Yet my vision for debcrossgen is that it should become an adapter > between the autotools interface (tell a gnu-triplet and pass variables > such as CC) and meson. Potentially, it can become distribution > agnostic at some point. It may have to use config.guess eventually. > Let's see where this is going. If we can do that reliably, portably and all that stuff, it is something we can consider, however ... > Again, doing so would constitute an API break on behalf of meson and it > would break a number of meson files. > > And yet, I believe that doing exactly that would avoid a lot of pain > down the road. Unfortunately, it'd also means gaining a dependency on > autotools-dev for using its config.guess. I doubt that Jussi will add > that dependency. Meson is very strict in this regard: we are only allowed to depend on things that are part of the Python standard library. Whatever solution we come up with, it _must_ work without any traces of Autotools. > It works beyond cc. binutils, pkg-config, a number of foo-config scripts > and more use that convention. I agree that this is the de facto > standard. Meson is non-standard here. Then again, this is a pretty > unix-ish standard and meson tries to cover more. Yes. For example compiling for iOS means using the main system compiler but adding a bunch of magical compiler flags to it. Most embedded and commercial compilers behave the same. Meson's goal is to be able to support them all (and many we already do) so we must provide a solution that is not tied to the unix de facto prefix model. > Meson is presently working with that assumption. Switching from > platform.machine to sysconfig.get_config_var would be a change in > vocabulary, but not in assumptions. > >> > > 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). > > Probably. I listed them here to demonstrate that mesons's present > vocabulary is broken. So maybe we should acknowledging that the > vocabulary is broken and thus breaking it is a reasonable approach > anyway? Maybe a little bit of history would be appropriate here. When Meson's cross compilation behaviour was designed many years ago it was mostly done by me in relative isolation (for the first few years of its life, Meson had roughly zero users). I did not have a lot of experience with cpu abis and the like on Mips and other lesser used platforms (I still don't). Most build files dealing with cross compilation I had seen took the cpu value from somewhere (uname, triplet values etc) and then tried to canonicalise it to roughly what cpu_family is today. So that was made the default, because it seemed like the most useful thing to do. The idea always was that those values should reflect the userland behaviour and _not_ the kernel that is running, because if you compile an x86 program it will always execute on a 32 bit userland and libraries, but the kernel might be 32 or 64 bits depending on the machine it is run on. The former is what's important for compilation so that is what was chosen. Maybe this was good nomenclature, maybe it was bad. Hard to say. But I had to make the call at the time with very little feedback from anyone else. This is also why the current implementation uses Python's platform module. It was simple, available and portable. That being said, we have stated in our documentation that those values may change, especially for rarer platforms (and, if it is unclear, some of those examples are clearly wrong and we should fix them). If there is a better naming scheme (especially one that is properly standardised) then we could consider adopting it. Or we could do something like add an cpu_abi field with the extra information if it is needed or something else. >> 32-bit ARM can also run on an aarch64 kernel, and 31-bit S390 can run >> on a 64-bit S390x kernel, so uses of that approach will tend to >> proliferate. Detecting the build architecture's bit width from uname -m >> just doesn't work very well, unfortunately: uname -m is a fact about >> the kernel rather than a fact about the user-space OS. > > Exactly. If there is a better, portable way of deducing this, do let us know. > I've been asked what build system to use a number of times now. > Presently, I tell people to avoid meson, because it is badly integrated > in Debian (debcrossgen is still broken), because it's architecture There is a new version in mentors that you can check out if you want. Pitti apparently has not had time to review and upload it yet: https://mentors.debian.net/package/meson
