Combining Generated Sources with PCH

[lhearachel]

I would like to combine generated headers with a PCH; for our main build target, we have the following (snipped for brevity):

main = executable('main',
    sources: [
        pokeplatinum_c,
        pokeplatinum_asm,
        c_consts_generators,
        asm_consts_generators,
        naix_headers,
        gen_species_headers,
        tutorable_moves_h,
    ],
    c_args: [
        pokeplatinum_args,
        '-thumb'
    ],
    nasm_args: asm_args,
    c_pch: 'include/pch/global_pch.h',
    ...
)

Generated headers have been listed as sources for the executable to ensure that they are built before any source file is compiled. However, it appears that meson has generated a target for main.nef.p/global_pch.h.mch in build.ninja which lists all of the generated headers as implicit dependencies of the PCH (snipped for brevity):

build main.nef.p/global_pch.h.mch: c_PCH ../include/pch/global_pch.h | consts/abilities.h consts/abilities.inc ...

From my understanding, when any change to these generated files is detected, this then appears to result in the PCH being recompiled. That, in-turn, flags the entire source tree for re-build.

Is my understanding correct? Is there a way around this, or should we migrate off of using a PCH?

Our project source is available here.

[eli-schwartz]

From my understanding, when any change to these generated files is detected, this then appears to result in the PCH being recompiled. That, in-turn, flags the entire source tree for re-build.

Is my understanding correct? Is there a way around this, or should we migrate off of using a PCH?

This is a bug and I have tracked down which commit it was introduced in and why it is buggy. Possible fix: master...eli-schwartz:meson:pch-orderdep

[eli-schwartz]

You can clone and checkout my fork with the pch-orderdep branch:

git clone https://github.com/eli-schwartz/meson -b pch-orderdep

and thereafter run meson using python3 path/to/cloned-repo/meson.py setup sourcedir builddir

[lhearachel]

This looks pretty close to functional, but it seems like our source files now do not get anticipated for rebuild whenever we regenerate one of our headers due to a change in an asset input. We generate those headers at the time of archive-packing, and it seems like meson / ninja are incorrectly determining that changing, for example, res/field/events/events_acuity_cavern.json will:

1. Rebuild a binary file events_acuity_cavern.bin
2. Pack the archive zone_event.narc and regenerate a header of constants zone_event.naix
3. Render previous compilation of src/map_header.c as invalid, due to an inclusion of zone_event.naix

Instead, what seems to be happening is that the archive is repacked, but the re-compilation is never re-triggered, even though we have zone_event.naix listed as an output of the custom_target that generates it and include it in the list of headers to be passed as source files to main.nef.

[lhearachel]

For sanity, I checked the output of ninja -t deps 'main.nef.p/src_map_header.c.o', which responded with the following (snipped a bit for brevity):

main.nef.p/src_map_header.c.o: #deps 10, deps mtime 1732070700480037170 (VALID)
    ../src/map_header.c
    ./main.nef.p/global_pch.h.mch
    ../include/map_header.h
    ../include/data/map_headers.h
    ./consts/map.h
    ./res/field/events/zone_event.naix
    ./res/field/scripts/scr_seq.naix
    ./res/text/pl_msg.naix

This looks like the correct dependency scan to me.

[eli-schwartz]

I assume you mean that zone_event.naix is an ordinary #included file? This should be getting handled via depfile support (you can debug the functionality of the depfile by performing a ninja build using -d keepdepfile).

[lhearachel]

I think I can take care of the tinkering from here; mostly what I wanted to contribute was that the fix that you made didn't still auto-trigger a full source rebuild, which seems to be the case. Thanks for the help, and hopefully that fix makes it into a patched version of meson soon! 🙏