Adding a generic build order rule

Describe the bug

Currently meson has specific build order logics depending on the type of rule. On some rule, it may depend on input, or depends or the main source files for executable(), and so on. Unfortunately as soon as we get into a case not planned by meson developers, we are either stuck or forced to do ugly or bug-prone build logics.

I’d like to get a syntax to block some target build rule until some other target got built first. Maybe it could be something like:

if (wait(some_target))
  some_rule(options)
endif

To Reproduce

The use case we had today (in GIMP build):

1. We generate a file git-version.h with this rule:

  gitversion_h = vcs_tag(
    input : gitversion_h2,
    output: 'git-version.h',
    command: [ 'git', 'log', '-n1', '--date=format:%Y', '--pretty=%cd', ],
    replace_string: '@GIMP_GIT_LAST_COMMIT_YEAR@',
    fallback: 'unknown (unsupported)',
  )

1. On another meson.build, we generate gimp-plug-ins.rc from some template:

gimp_plugins_rc = configure_file(
  input : 'gimp-plug-ins.rc.in',
  output: 'gimp-plug-ins.rc',
  configuration: versionconfig,
)

1. Then we use gimp_plugins_rc in a few dozen meson.build like this:

  plugin_sources += windows.compile_resources(
    gimp_plugins_rc,
    args: [
      '--define', 'ORIGINALFILENAME_STR="@0@"'.format(plugin_name+'.exe'),
      '--define', 'INTERNALNAME_STR="@0@"'    .format(plugin_name),
      '--define', 'TOP_SRCDIR="@0@"'          .format(meson.source_root()),
    ],
    include_directories: [
      rootInclude, appInclude,
    ],
  )

What happens

The problem is that gimp-plug-ins.rc actually has an #include "git-version.h". So we don’t need git-version.h to generate the .rc file, but the later is simply useless without the .h. Or to be more accurate: the build will fail if the .rc was built first. As meson kind of starts everything in the same time, it sometimes work, but sometimes doesn’t. It’s a race condition. We just had a CI build on a tag which failed whereas it was succeeding on the commit the tag is on (i.e. exact same code), just because of this race condition.

Expected behavior

I looked up documentation and I see that we could add depends: [ gitversion_h ], on each and every windows.compile_resources() calls. We have more than 30 of these. And we have another rc file which has the same issue, and finally we have other rc files generated from the first one. Basically we have a lot of these calls. We could all update them, but this is bug prone as hell. This should be taken care of on the rc generation level. Basically gimp_plugins_rc target should not be created before gitversion_h target. This is basic build order which makes sense (even though gitversion_h is not a dependency to build gimp_plugins_rc, it is definitely a dependency to use it, so it makes no sense to make gimp_plugins_rc available before gitversion_h).

This is why I am not asking to add a depends: option on configure_file() or or any other target type. Instead I propose a generic call to wait for another target. My proposed naming idea was a wait() call, though it could be anything else as long as it allows to create call orders when needed:

if (wait(gitversion_h))
  gimp_plugins_rc = configure_file(
  input : 'gimp-plug-ins.rc.in',
  output: 'gimp-plug-ins.rc',
  configuration: versionconfig,
)
endif

The fact is also that we can never take every special case into account. There will always exist some special build case where we need to wait for another target (for reason X or Y which matters to the project). So a generic wait() rule is really worth it as it would take care of all the remaining needs.

system parameters

• Is this a cross build or just a plain native build (for the same computer)? This was a cross-build but it doesn’t matter for the requested feature.
• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.) Build on Linux Fedora 33 for Windows, but once again, this is a generic feature so OS don’t matter.
• what Python version are you using e.g. 3.8.0 Python 3.9.0
• what meson --version 0.55.3
• what ninja --version if it’s a Ninja build 1.10.1

[Jehan]

That’s a pity, but, I wonder if windows.compile_resources() could be improved to accept declare_dependency() objects?

Note that it’s not the only one you’d have to change. While testing other variants, I saw among the 35 uses, we have a bunch like this one:

    plugin_rc = configure_file(
      input : gimp_plugins_rc,
      output: plugin_name + '.rc',
      copy: true,
    )

Which gets as error:

../../../../../../../dev/src/gimp/plug-ins/common/meson.build:159:4: ERROR: Inputs can only be strings or file objects

This means that you’d configure_file() to accept more types of objects. I know, I am annoying to repeat this 😛, but I really think a more generic “this depends on that” (whatever this or that are) would be a lot more useful as generic, rather than trying to cater to every possible case which will come up.

[eli-schwartz]

That’s a pity, but, I wonder if windows.compile_resources() could be improved to accept declare_dependency() objects?