6 ms·

If nothing needs to be built, my statement still stands. The build system needs to cache its dependency computations. Empty build would be same time as git sta

• dangerlibrary 12y ago
  #ifdef win32 ...some changes we don't care about on linux #else ...no changes #endif so you'd still need to traverse all the headers, at a minimum.
  • reubenmorais 12y ago
    Though in this case, things do need to be rebuilt. No C build system is this clever, as far as I know :)
    • taeric 12y ago
      Actually, they sort of are. If the conditional not taken on the current configuration includes another header and that was where the change was, then there will be no dependency between the current file and that header on this platform/configuration.
      • Peaker 12y ago
        That case is the easy case (though caching of included files is problematic in most build systems due to inability to express dependency on the inexistence of the included name in a previous include directory). The hard case is changing defined macros in a way that doesn't matter but does pass extra -D flags to the compilation units. You can detect this by ad hoc preprocessor aware logic, or you can have a separate build step for preprocessing and do content aware rebuilds that avoid rebuilding if the preprocessed text is identical.
        • taeric 12y ago
          Right, I was just saying that some of the build environments are "smarter" than you might give credit. I think you'd be surprised how many people don't know about gcc -M and friends.
          • Peaker 12y ago
            One thing almost nobody knows about gcc -M is that it is wrong :( And for 2 different reasons: A) If the headers are supposed to be auto-generated, it will uninformatively fail B) If everything is successful, it will not tell you about all the paths it depends on not existing. gcc -M -Ia -Ib foo.c Will tell you about b/x.h being a dependency, but will not tell you about a/x.h not-existing being a dependency.
            • taeric 12y ago
              A) doesn't make sense. If the header is autogenerated, then it has a dependency specified elsewhere. So, I'm not sure how that is a failure of -M. (That is, it will tell you that this file depends on a header. It is up to other rules to say that header is autogenerated. Right?) B) This makes sense, though I don't necessarily see how that could happen. It won't help you not rerun the -M hit, but the flow is: "rerun -M" on files to get list of dependencies, restart with those dependency list loaded and see what needs to be rebuilt. Right?
              • Peaker 12y ago
                A) Usually, there's a rule like: auto_%.h from %.xml Then you want #include "auto_foo.h" to be found, and cause auto_foo.h to be auto-generated from foo.xml, without explicitly mentioning "foo.xml" anywhere in the build system itself. B) If you rerun -M every time you try to build, your empty builds are going to be quite expensive. It makes sense to cache that, and only rescan files when they or their #included files changed. But then you need to be able to do the file-inexistence dependency thing or it's wrong.
                • 12y ago
  • Peaker 12y ago
    This is a rebuild, though. You can distinguish the preprocessing phase into its own build step and then you'd just preprocess everything. You could even try to cache which macros are relevant to which headers/files.