Regarding using custom_target/generator as an executable/library "dependency".

[Kagetsuki]

• The following is regarding the design and implementation of Meson - not a bug or a problem.

This issue prompted me to look deeper into how to "properly" handle using a custom_target (or a generator) as either a dependency (as in prerequisite step in the build chain) or an input. Note I'm not raising this as an issue at the moment, because I may be mistaken in how I've understood the current design.

Before I cover the issue with using it as a dependency, let me cancel out the discussion of using a custom_target as an input. Using a custom_target as an input would open up the using custom_target chains to create pipelines; which is apparently disallow by design according to this bit of documentation. Specifically the line stating "This is by design as writing shell pipelines into build definition files leads to code that is very hard to maintain.". If someone wants to disagree with that design decision please do it separately as I personally have come to agree with this design decision and don't want to make that an issue here.

Using a custom_target as a dependency

This can be already be done with a 'known' "hack". Instead of declaring the custom target as a dependency, if you put the custom_target object into the source file list of a library or executable it effectively acts like a dependency. As an example, this works:

project('ctc',
  ['c'],
  default_options: ['c_std=c11'],
  version: '0.0.1',
  license: 'GPL-3.0'
)

ct_pre = custom_target('ct_pre',
  output: 'ct-pre.mark',
  command: ['touch', 'ct-pre.mark']
)

hello = executable('hello',
  [ct_pre, 'src/main.c']
)

ct_post = custom_target('ct_post',
  output: 'ct_post.mark',
  input: hello,
  command: ['touch', 'ct_post.mark'],
  build_by_default: true
)

Explicitly declaring it as a dependency however does not work:

project('ctc',
  ['c'],
  default_options: ['c_std=c11'],
  version: '0.0.1',
  license: 'GPL-3.0'
)

ct_pre = custom_target('ct_pre',
  output: 'ct-pre.mark',
  command: ['touch', 'ct-pre.mark']
)

hello = executable('hello',
  'src/main.c',
  dependencies: [ct_pre]
)

ct_post = custom_target('ct_post',
  output: 'ct_post.mark',
  input: hello,
  command: ['touch', 'ct_post.mark'],
  build_by_default: true
)

But in a way that makes sense, because [if I understand correctly] in this context "dependency" is essentially referring to things like separate libraries or tools that are needed to perform the build rather that the CMake idea of a "dependency" which is just a prerequisite.

In the case of using a custom_target as a source it does in fact make perfect sense and is a semantically consistent design choice if the custom_target is in fact generating a source file or something that could be considered a source file. When utilized this way, this makes perfect sense and is a nice implementation for a necessary feature - and should be better outlined in the documentation because I've run into quite a few issues that could have been resolved by this.

The above said this is probably going to sound like nitpicking, but when using a custom_custom target as a dependency that's not generating what would regularly be considered a "source" file this method feels hackish and wrong. Of course a custom_task that normally has no output can simply output a dummy file that you could call a source file, but it's still using a feature in a way it doesn't seem intended for.

All that said and knowing what I think I know now, letting custom_targets and generators be specified as a dependency would break the concept of what a "dependency" is in Meson? I also feel like the a possible solution of just adding a field like "prerequisites" to library and executable objects which would just be added to the sources list at build time is silly, but would be effective.

Sorry about such a long post about something so minor - but I saw enough unresolved issues in the wild (GH/SO/etc.) sharing this confusion and it took me so long to figure out the above listed "hackish" usage that I think it's something that should be addressed.

[eli-schwartz]

It might help to keep in mind that meson has two different kwarg types, not all of which are available for all functions:

• dependencies indicates objects that come from pkg-config or cmake or more generally from the dependency() or declare_dependency() functions, and contains an interface wrapper around link_with + include_directories
• depends is a task ordering mechanism that indicates one target has to be built after a different target and maybe also takes the other target as a command: parameter. But specifying a target as input files or as elements of the command: [...] array usually automatically sets up depends as part of the backend processing logic, so usually depends: is used for files that are internally used by the command but don't appear on the command line, e.g. due to internal globbing or hardcoding specific ancillary filenames that it expects to find.

People have argued before in favor of library/executable gaining support for the depends: kwarg.

[Kagetsuki]

Thanks for the detailed technical explanation of dependencies - I think for a lot of people like me who come from tools like CMake it takes a little while to realize dependencies in meson are not an ordering mechanism.

As for dependsbeing added as a kwarg... I actually forgot about that when writing my post because I was so focused on specifically executable/library and I wrote "prerequisites" to try and disambiguate things - but if a kwarg is going to be added it should replicate existing patterns so depends makes much more sense.

I'll try and dig up issues and posts requesting adding the depends kwarg to executable/library to gain more context - but offhand if anyone happens to have a definitive reason why such requests were rejected please let me know.

[eli-schwartz]

The one that springs to mind is #8515 -- that came up specifically in the context of "projects which use .c files as includes".