*available

Isn't this redundant? It will throw an error anyway if not.

Why is this broken?

It requires those features to work.

Sorry thought this was part of the same derivation as above.

Why does meson care about targetPlatform? Sounds like a bug (an existing one though).

Yes indeed. Meson is a bit confused with cross :(. I was hoping to fix it, starting with mesonbuild/meson#3689 which I thought would be uncontroversial. But it was, and then I think I burnt some credibility in the process.

I mean a bug in the Nix expression. This can't be right?

 60     [host_machine]
 61     system = '${targetPlatform.parsed.kernel.name}'
 62     cpu_family = '${targetPlatform.parsed.cpu.family}'
 63     cpu = '${targetPlatform.parsed.cpu.name}'
 64     endian = ${if targetPlatform.isLittleEndian then "'little'" else "'big'"}

The only place where you care about targetPlatform is when building a cross compiler. I don't see why meson would ever apply here.

Also I don't understand what "Meson is a bit confused with cross" means. Based on my reading, it has mostly the same semantics and names for everything as autoconf?

It's not that bad. I fixed some terminology in https://github.com/mesonbuild/meson/blob/master/docs/markdown/Cross-compilation.md without issue (i.e. the thing itself did the mostly right thing) for example.

The concrete issue is that pops up here is Meson handles compiler env vars incorrectly.

With autoconf, CC_FOR_BUILD (or long ago + still in Linux HOST_CC) targets the build platform, CC targets the host platform, and CC_FOR_TARGET targets the target platform. The _FOR_* ones are defaulted in the native case so the build system writer doesn't need any special casing. With Meson, CC always targets the native platform, so sometimes it's for build and host, and sometimes it's for build.

What's going in Nix is a) we need to wip out our autoconf-style CC (and other variables, which isn't done yet) and b) we are making a cross file baked into meson, which is also sketchy cause we don't know what compilers we'll have in actuality. Since meson is making the file, and already a nativeBuildInput it's only a little stretch to pretend it's a cross compile and use targetPlatform according too for the build hook bug yuck.

This reflects a larger issue that meson's implementation constantly thinks "native vs foreign" rather than "build vs host vs target" which leads to tons of needless and hazardous conditional code.

I opened mesonbuild/meson#3282 before I knew it used CC incorrectly in the cross case. I suppose I should open another making it use the env vars like autoconf.

With Meson, CC always targets the native platform, so sometimes it's for build and host, and sometimes it's for build.

Right, if setting CC overrides the native compiler even when a cross file is present, that will be painful. Having them support CC_FOR_BUILD would be useful indeed.

we are making a cross file baked into meson, which is also sketchy cause we don't know what compilers we'll have in actuality.

You can create the cross file in the setup hook at build-time. I presume it would be needed anyway if you ever need to tell meson about say, a cross Fortran compiler and not have meson depend on gfortran all the time.

This reflects a larger issue that meson's implementation constantly thinks "native vs foreign" rather than "build vs host vs target" which leads to tons of needless and hazardous conditional code.

Any concrete example?

Having them support CC_FOR_BUILD would be useful indeed.

Glad you agree. Made mesonbuild/meson#3969 for CC/CC_FOR_BUILD.

You can create the cross file in the setup hook at build-time.

Yeah agree making on the fly (probably via setup-hook) is a more reliable way to get this done. Of if we deem Meson important enough, we can make it part of -wrapper. (If I do the big refactors I want, probably at the end up the month, those should be a lot simpler freeing up some complexity budget.)

Any concrete example?

grep for is_cross I recall. I had some local changes I could dredge up too. mesonbuild/meson#3689 would have been the first step in ensuring that all of build, host, and target, are treated symmetrically. The next step would be to make cross files and environment detection present their conclusions through the same interface so downstream stuff can read the info in a cross-agnostic manner. Right now, tons of those is_cross conditions are deciding whether to query the (detected) native platform or cross file (for host and target, when cross compiling). The alternative would mean just querying build, host, and target information not caring about is_cross or provenance (explicitly specified vs inferred).

(In mesonbuild/meson#3689 (comment), I raise trying different plans of attack that people might be more on board with.)

Since when is this withFeature a thing? First time I see it used.

enableFeature has existed for a while but I think withFeature is pretty recent addition.

Indeed I added it in 9e9cdd7.

I think it probably should be asked from the community whether it's desirable to do this.

I figured since enableFeature exists, it's OK, but happy to bring in more people. @aneeshusa was pushing for things like this.

My main interest was using structured data for configureFlags, cmakeFlags and the like; in the cmakeFlags case this makes a bunch of these helpers unnecessary. No strong opinions about withFeature and friends in the configureFlags case but seems reasonable enough.

Maybe get rid of this as well?

Eh it can't be that much better until upstream changes per my above response.