meson-1.0.tcl: Use a cross file

[ryandesign (Ryan Carsten Schmidt)]

As I'm coming to understand it, meson tries to detect the CPU architecture and build for that. If you want to build for something other than what it autodetected, you must apparently use a "cross file".

Its CPU detection is currently wrong on some systems; see ​https://github.com/mesonbuild/meson/issues/6187.

Even if its CPU detection were right, we would always want to tell it what to build for. We want the user to be able to specify a different build_arch in macports.conf and we want the user to be able to build for multiple archs (universal).

Therefore it seems like we should always be using a "cross file".

[kencu (Ken)]

Not much chance we could just get them to use cmake, which has this all figured out already :>

Hah hah, I know they won't. But new build systems are a PITA, and there is precious little to support the need for us to go through all this endless tweaking again for something that will never be as good as cmake anyway.

That aside, I think you're right, we probably want to skip all of meson's attempts at logic

[kencu (Ken)]

A relevant document defining the cross file is here <​https://github.com/mesonbuild/meson/blob/master/docs/markdown/Cross-compilation.md>.

We would appear to need to specify the build machine (our default architecture of the system that is doing the building) and the host machine (our universal target architecture).

For non-universal builds, they would be the same.

For universal builds, we would set the host machine to the univeral architecture we're building for.

I don't see any way to do multiple arch-flag builds at present, so it looks like the only way this works is to use the muniversal portgroup for universal builds with meson.

I suppose all of this should go into the meson PortGroup file... not sure it's great to include the muniversal portgroup inside that portfile, but it's much easier than doing having to define it separately in every port that uses meson I suppose.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

not sure it's great to include the muniversal portgroup inside that portfile, but it's much easier than doing having to define it separately in every port that uses meson I suppose.

If that's the only way to do a universal build with meson, and I suspect you're right that it is at this time, then including the muniveral portgroup in the meson portgroup is probably the right thing to do.

However, individual ports that use meson may still want or need to disable the universal variant, which they would want to do by specifying universal_variant no. I am not sure whether the muniversal portgroup respects that. I suspect that it does not. If not, adding support for that to the muniversal portgroup might be nice, but I anticipate that this will actually break a whole lot of ports which do not have a universal variant by default and which currently use the muniversal portgroup and expect it to provide a universal variant even though they are not setting universal_variant yes.

It looks like the octave portgroup includes a workaround for this deficiency in the muniversal portgroup. Until the muniversal portgroup is fixed to support this, I guess that same workaround can be used in the meson portgroup.

[kencu (Ken)]

I had sorta excluded the multiple archflags approach according to how meson does things, but now I am wondering if we could consider just Bogarting our multiple universal archflags onto the build lines, forcing them onto the cflags, cxxflags, and ldflags, or in a pinch, tagging them onto the compiler spec.

If that worked, it would certainly be much simpler...

[ryandesign (Ryan Carsten Schmidt)]

In light of what we've discussed in ​6187 do you really expect that to have any chance of working? What would you expect their detect_cpu / detect_cpu_family functions to return in that case? There is no sane answer that a CPU detection function could give at configure time when building for more than one CPU arch.

[kencu (Ken)]

Until I try it, I guess we won't know for sure. Will report back.

[kencu (Ken)]

To no great surprise, you quickly run into trouble with this approach. Even then using the muniversal portgroup, no happiness. When building the i386 portion, meson returns x64_64 to the build system, and it tries to build 64bit only source when targeting 32bit. So the cross file idea is looking like the only viable option to me at present, as anticipated.