Not fully processed custom_target when concatenating files

[inigom...@gmail.com]

I need to concatenate a set of generated files in a new file, which is then used to generate documentation by using `gtkdoc`. I'm just using `cat` to concatenate files in a `custom_target`. However, looks like `cat` stops halfway and this makes the documentation generation to fail because the resulting file doesn't contain the whole data.

This procedure is done in the following way:

doc_module = 'libqmi-glib'
name = doc_module + '-sections.txt'

sections_txt = custom_target(
  name,
  input: ['libqmi-glib-common.sections'] + gen_sections,
  output: name,
  console: true,
  command: [find_program('cat'), '@INPUT@'],
)

`gen_sections` is a set of generated files by using a previous `custom_target` and `libqmi-glib-common.sections` is an existing file which is also concatenated into a file called `libqmi-glib-sections.txt`.

gnome.gtkdoc(
  doc_module,
  main_xml: doc_module + '-docs.xml',
  src_dir: src_dirs,
  ignore_headers: private_headers,
  include_directories: top_inc,
  dependencies: libqmi_glib_dep,
  namespace: 'qmi',
  scan_args: scan_args,
  fixxref_args: fixxref_args,
  content_files: [sections_txt, version_xml],
  install: true,
)

The `sections_txt` target seems to stop at some point after/when `gtkdoc` is executed. The resulting file should be `7531 bytes` but is only `5353 bytes`. If I execute the `libqmi-glib-sections.txt` target alone, the resulting file size is correct, `7531 bytes` and if `gtkdoc` documentation generation is executed after, then the process ends properly.

Any idea about what is happening here?

[Jussi Pakkanen]

On Fri, Jan 11, 2019 at 12:25 PM <inigom...@gmail.com> wrote:

> This procedure is done in the following way:
>
> doc_module = 'libqmi-glib'
> name = doc_module + '-sections.txt'
>
> sections_txt = custom_target(
> name,
> input: ['libqmi-glib-common.sections'] + gen_sections,
> output: name,
> console: true,
> command: [find_program('cat'), '@INPUT@'],
> )
>
> `gen_sections` is a set of generated files by using a previous `custom_target` and `libqmi-glib-common.sections` is an existing file which is also concatenated into a file called `libqmi-glib-sections.txt`.

At the very least you should use "capture: true" here, otherwise the
output of cat is printed to the console rather than going to a file.
Probably you meant to type "capture" rather than "console" in this
declaration.

[inigom...@gmail.com]

Actually, I've tested both parameters and neither has worked. In fact, `capture` was my first option, but once it failed I also tried `console` after reading its description:

console (added 0.48) keyword argument conflicts with capture, and is meant for commands that are resource-intensive and take a long time to finish. With the Ninja backend, setting this will add this target to Ninja's console pool, which has special properties such as not buffering stdout and serializing all targets in this pool.

 

As the command seemed to take too long, I opted for this version without success.

In case it might be helpful to test this behavior, this came from the wip meson port of `libqmi`.

Thank you,

Best regards,

[inigom...@gmail.com]

After almost two years since I had this issue, I have rebased the `libqmi` meson port and tried this in case the issue has been resolved in recent meson versions. Unfortunately, the issue remains.

Is there anything that can be done, properly or even with a workaround?

Thanks!