fs configure_file_list function

[bruchar1]

This is a new attempt to achieve the same goal as what I tried in #11822 , but in a simpler way.

This function produces, at build time, a file containing the list of files given as argument. It is used when a command uses, as argument, a file containing the list of files to process. One usecase is to provide to xgettext the list of files to process, from the list of source files, when this list is too long to be provided to the command line as individual files.

[bruchar1]

Another use case is described in discussion #13235

[lhearachel]

To wit on the above use case, our project's compiled archive binaries must match a specific SHA-sum, which means that the archives must be packed in a certain order. Historically, we would manage a separate file, but this feels brittle and does not play well with change; ideally, we would build that file from the existing list of files statically defined in the meson.build configuration, which this exactly facilitates.

[jpakkane]

Linking discussion #13235, an alternative approach would be to make custom_target use rsp files automatically. That seems to be the more general solution of the two. Would it also solve the issue this feature aims to?

[bruchar1]

Linking discussion #13235, an alternative approach would be to make custom_target use rsp files automatically. That seems to be the more general solution of the two. Would it also solve the issue this feature aims to?

The problem I see is that not all custom commands can use rsp files, and not all commands use the same rsp file syntax. I don't see how this could easily be implemented in a generic way.

[lhearachel]

an alternative approach would be to make custom_target use rsp files automatically.

I do agree with @bruchar1 that it doesn't seem to make sense to automatically use rsp files, since not all executables support them nor use the same syntax. Perhaps if an executable supported a flag designating that it supports a response file, it could be standardized to dump all arguments given as input into the response file?

[jpakkane]

I do agree with @bruchar1 that it doesn't seem to make sense to automatically use rsp files, since not all executables support them nor use the same syntax.

Of course it would not be automatic, but instead have a kwarg like use_rsp_file or something like that.

[eli-schwartz]

We already have a depfile kwarg, which is something else that compilers have builtin handling for but must be manually implemented for each custom target.

A possible analogous feature we could use here, would be:

custom_target(
    ...,
    command: ['myprog', '-i', '@INPUT@', '-o', '@OUTPUT@', '--foo', '--bar=baz', additional_args],
    rspfile_args: ['--args-from', '@RSPFILE@'],
    rsp_style: 'gcc',
)

Which would, I suppose, produce a commandline of myprog --args-from path/to/subdir/mytarget.rsp. Requires two kwargs instead of one and one function kwarg? Not sure what I think about either approach. Just a shower thought.

[lhearachel]

Offering support for a leading-args parameter I think makes more sense than expecting an underlying program to always interpret a response file via the same methodology. At least for my team's use case, the difference won't matter (since we build the tools where we would use a response file anyways), but it makes more sense to me to hedge against users with third-party tools that may have varying input schemae.