1. 11
  1. 1

    I would like to see this built into build systems to verify the configuration. For example, ninja could have a “–verify” flag which makes it do such strace magic and compare the output with its configuration. Tup does it always.

    This seems like such a useful feature that I wonder that (for example) cmake does not already have it.

    1. 1

      I think you’d lose things under /usr/ that are build dependencies, like actual system libraries. Or am I misunderstanding the scope?

      1. 1

        Using strace to record all the syscalls does let you see things like which libraries and headers the compiler loaded from /usr in order to do its job.

        The one downside I know of is that strace makes syscalls slower. I think like 10%-30% wall clock overhead is realistic for a compiler(*) since they spend much more time in userspace thinking about code than they do in the OS loading it.

        (* source: vague collection of having tried running make under strace for some smallish C codebase to see how much difference it would make)

        I suspect the wall clock time overhead would be negligible on BSD where they have the much-faster ftrace utility instead. Maybe modern Linux eBPF magic could be used to log all the syscalls like strace does but with negligible overhead like ftrace has?

        1. 2

          He says he ignores the boring paths, meaning stuff like /usr/

          1. 2

            Oh! Sorry, I missed that.

            So I guess that changing the libraries in /usr/include or replacing the compiler binary doesn’t cause a full rebuild? seems sketch.

            1. 1

              Good point. Would break all the time on a rolling release distro.