Opened 3 years ago

Last modified 3 years ago

#59864 new enhancement

meson-1.0.tcl: Use a cross file

Reported by: ryandesign (Ryan Schmidt) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: kencu (Ken), SoapZA


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

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".

Change History (7)

comment:1 Changed 3 years ago by 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 can take a lot of time to mature.

That aside, I think you're right, we probably want to skip all of meson's attempts at logically figuring anything out, and just write up a cross file for every meson build.

Last edited 3 years ago by kencu (Ken) (previous) (diff)

comment:2 Changed 3 years ago by kencu (Ken)

A relevant document defining the cross file is here <>.

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.

comment:3 in reply to:  2 Changed 3 years ago by ryandesign (Ryan 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.

comment:4 Changed 3 years ago by 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...

comment:5 Changed 3 years ago by ryandesign (Ryan 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.

comment:6 Changed 3 years ago by kencu (Ken)

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

comment:7 Changed 3 years ago by 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.

Note: See TracTickets for help on using tickets.