mesonbuild / meson

The Meson Build System
http://mesonbuild.com
Apache License 2.0
5.65k stars 1.64k forks source link

missing compiler doesn't fall back to the wrap #12609

Open stsp opened 11 months ago

stsp commented 11 months ago

Describe the bug The [binaries] section in toolchain config has this:

[binaries]
nasm = 'nasm-segelf'

This overrides the nasm compiler requested in the project() call. I also do have this nasm-segelf.wrap:

[wrap-git]
url = https://github.com/stsp/nasm.git
revision = elf16
depth = 1

[provide]
program_names = nasm-segelf

This properly overrides find_program('nasm-segelf'). But I can't get both overrides to work together. If nasm-segelf is not installed, then nasm requested via project() call doesn't fall back to the nasm-segelf wrap. It just says: ../meson.build:1:0: ERROR: Unknown compiler(s): [['nasm-segelf']] and ignores the wrap. I don't know if it ignores the wrap because it is called from project(), or because it is already overridden by [binaries] and 2 overrides do not chain, but in either case the desired result is not achieved.

Expected behavior nasm should first be translated to nasm-segelf via the [binaries] override, and then it should fall back to a wrap.

dcbaker commented 11 months ago

This is actually a pretty hard problem to solve, because we need to have the compiler available at configure time to run compiler tests and to know argument syntax, etc. It would basically require meson setup to stop, run a nested meson + ninja to build the compiler, and then return to configuration using that compiler. There are a handful of other programs we have the same problem with, but off the top of my head I can't remember what they are.

stsp commented 11 months ago

But how does the wrap normally work? I.e. find_program() also runs at configure time, and yet it can be wrapped. I suppose that, indeed, even now the configure stops, the wrap builds, and find_program() restarts. Or how exactly does it work, and what is the difference between find_program() and project() calls in that regard?

dcbaker commented 11 months ago

No, find_program overrides happen at normal build time, we just creat the right dependency chain to ensure that the build works. If you try to use an overridden find_program at configure time you’ll get an error. That tends to to work for find_program, I’m not sure it will work for compilers. Some thought may be required

stsp commented 11 months ago
Target machine cpu family: x86
Target machine cpu: i386
Program nasm-segelf found: NO
Fallback to subproject nasm-segelf which provides program nasm-segelf

Executing subproject nasm-segelf 

nasm-segelf| Project name: nasm-segelf
nasm-segelf| Project version: 2.17

OK I guess I can see what you mean. The above is what I see at configure time. Meson noted the override and configured the wrap project. But the use of the program is going to happen during build, whereas the compiler may be used by itself during configure too. I see the problem, thanks for an info.

stsp commented 11 months ago

However, understanding the problem doesn't make me very happy about it. :) I think this problem is serious, and it would be good to know if the meson devs at least share the opinion that it should be solved, one way or another. For me its a show-stopper currently.

stsp commented 11 months ago

Actually there may also be another problem. Namely: if there is no compiler, then how would the one ever build the wrap? :) Seems the solution indeed needs a bit of brain-storming.