Hi Samuel, On Sun, Feb 20, 2022 at 12:01:36AM +0100, Samuel Thibault wrote: > Mmm, it still targets hurd-<any> explicitly, so I'd say it should still > be called mig-x86-64-gnu.
I can relate to that, yes. > What I'm wondering is why we added -linux/-kfreebsd since here they are > host, not target. The package name is supposed to designated the target > doesn't it? I'm actually now unsure what "mig-for-host" was supposed to > mean. AIUI we'd want it to pull a native-for-host binary that targets > the architecture equivalent on the hurd port. E.g. on linux-amd64 it'd > pull a linux-amd64 x86-64-gnu-mig binary. Currently gnumach is fine > with this I think the -linux/-kfreebsd ones originate from the fact that you used any-amd64. In the end, there will be a sparsely filled binary matrix of builds. I see how the build/host/target terminology can become confusing here. It depends on the point of view. mig's point of view, host is what architecture the built mig is being run on, but the target architecture is what architecture it is being used for. The downstream packages (mainly hurd) relate to mig via their host architecture though. Thus the "-for-host" part is hurd's host, but mig's target in a sense. So why do we have mig-for-host? We want hurd to depend on some mig for its host architecture (i.e. a mig where build=don't care, host=don't care, target=host of hurd). And that directly means, we only need mig-for-host for hurd-any. How about changing its architecture field from "any-i386 any-amd64" to "hurd-any"? Then, mig-x86-64-linux-gnu has no reverse dependencies anymore and can go way. Unfortunately, that also means that we won't have any mig executable on amd64 anymore, but having it would be useful for cross building hurd. To fix that, we can change the Architecture field of mig-x86-64-gnu from "hurd-amd64" to "any-amd64". Once doing that, we effectively get the very same packages just without -linux or -kfreebsd. Circling back to this matrix of builds. It has two dimensions (host architecture and target architecture). In the packaging, we decide which of these combinations generate a package by default. Of course the diagnoal (host==target) is needed. There is no question about that, but for other combinations it is less obvious. You currently try to fill same-cpu combinations. I'm wondering whether that is needed (given that rebootstrap builds its own mig anyway) and I'm wondering whether that should be expanded to just cover the full matrix withing x86 architectures (32bit and 64bit) to ease hurd-amd64 development on hurd-i386. Do you have a preference here? > checking for i686-gnu-mig... i686-linux-gnu-mig > > but that's still relatively bogus. After the change above, there would not be any i686-linux-gnu-mig, but i686-gnu-mig instead. If you agree with this change in principle, I can look into writing a patch for it. Helmut