5 ms·

If "git status" is empty, and takes milliseconds to know that -- "make" should take roughly the same amount of time to know the same. There are some better bui

by Peaker 12y ago

If "git status" is empty, and takes milliseconds to know that -- "make" should take roughly the same amount of time to know the same. There are some better build systems which will fulfill this requirement, but fail others. This is why I am implementing buildsome [1], that gives far better guarantees [2] about the build's correctness while making it easier to specify. Empty builds only check "mtimes" of all files, and no more than that. [1] https://github.com/ElastiLotem/buildsome https://github.com/ElastiLotem/buildsome [2] https://github.com/ElastiLotem/buildsome/raw/master/doc/Presentation.pdf https://github.com/ElastiLotem/buildsome/raw/master/doc/Pres...

reubenmorais 12y ago
> If "git status" is empty, and takes milliseconds to know that -- "make" should take roughly the same amount of time to know the same. If absolutely nothing changed, you wouldn't need to build in the first place. He's talking about the case of "nothing changed that needs to be built". Configuration files, sources that aren't built on that platform, etc. Which means the build system still needs to traverse directories and figure dependencies out, etc.
- Peaker 12y ago
  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 status.
  - 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.
    - 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.

by Peaker 12y ago

reubenmorais 12y ago

> If "git status" is empty, and takes milliseconds to know that -- "make" should take roughly the same amount of time to know the same. If absolutely nothing changed, you wouldn't need to build in the first place. He's talking about the case of "nothing changed that needs to be built". Configuration files, sources that aren't built on that platform, etc. Which means the build system still needs to traverse directories and figure dependencies out, etc.

Peaker 12y ago
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 status.
- 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.
  - 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.