Skip to content

Conversation

@xclaesse
Copy link
Member

@xclaesse xclaesse commented Oct 9, 2025

No description provided.

@xclaesse xclaesse requested a review from jpakkane as a code owner October 9, 2025 19:57
@xclaesse xclaesse force-pushed the override-ct branch 2 times, most recently from cdc9b1e to 31e0749 Compare October 9, 2025 20:52
@xclaesse
Copy link
Member Author

xclaesse commented Oct 9, 2025

For context, I'm using it there: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/547.

g-ir-scanner is a python tool that requires a module to be built. When g-i is built as subproject, gnome.generate_gir() needs a way to depend on that module to be built first.

@xclaesse
Copy link
Member Author

Actually, I'm having a 2nd though about this. If the custom target output is a script, Meson won't be able to parse the shebang on Windows. I think that means a program must be an executable, external, or a file that exists at config time. Which is exactly what meson.override_find_program() accepts.

I think we should instead concentrate on fixing the root issue: How do we define a program that has build time dependencies.

I see 2 ways:

  • Add a new function: prog = local_program('foo.py', depends: [...]) meson.override_find_program('foo', prog).
  • Less flexible but new kwarg instead of new function: meson.override_find_program('foo', files('foo.py'), depends: [...])

The 2nd option could be enough because the current project does know about its own program dependencies and can always manually add it everywhere it's being used. It is only when it's being used by a parent project, when find_program() returns an override, that it cannot know about those extra deps.

@xclaesse
Copy link
Member Author

Closing in favor of #15107

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant