4 ms·

Bazel’s: * each build file is independent (unlike CMake where the project is one big script with global scope and side effects) * build script evaluation is h

Bazel’s: * each build file is independent (unlike CMake where the project is one big script with global scope and side effects) * build script evaluation is hermetic (cannot read time for example) and strictly reproducible * target is rebuilt not by timestamp changes (which is unreliable for several reasons), but instead all dependencies must be declared, and target is rebuilt when the hash of dependencies change

barumi 6y ago
> each build file is independent (unlike CMake where the project is one big script with global scope and side effects) I don't understand your point. CMake projects specify build targets per module, and it's up to the developer to choose what he thinks should be a module. What value do you see in specifying build targets per file?
- lightgreen 6y ago
  I'm not saying about specifying build target per file. I say when cmake file includes another cmake file, all variables are inherited, and in certain cases cmake file can define variable in outer cmake file scope. Thus build files are dependent on each other. Inclusion order is important, and when project refactoring/restructuring, it's a common error, that resulting project is incorrect because for example, some file relied on the fact that when it is included, certain variables or macros are already set by someone else. This makes large project maintenance quite inconvenient. Especially because CMake does not guarantee that error will be revealed unless it is full clean rebuild.
  - barumi 6y ago
    > I say when cmake file includes another cmake file, all variables are inherited, and in certain cases cmake file can define variable in outer cmake file scope. This is not true at all. You only "inherit" variables that you intentionally want to pass to downstream projects. You need to explicitly and intentionally declare your variables with PARENT_SCOPE to access variables from other files. That's an explicit decision from the developer.
    - lightgreen 6y ago
      > You only "inherit" variables that you intentionally want to pass to downstream projects Yep, most project variables, except for some locals. > You need to explicitly and intentionally declare your variables with PARENT_SCOPE to access variables from other files. No you don't. PARENT_SCOPE is needed to write variables into parent scope, but not read. > That's an explicit decision from the developer. Even so. Yes, when working very carefully, when you are a single developer writing on a small projects, and enforce code style, it is possible to keep the mess manageable. When at least 100 people work on the project, if a project is several years old, if half of the team changed, CMake project is always a mess. (Source: I worked in two very different large companies which were using CMake; both of them eventually migrated away from CMake). Someone might blame developers for making that mess. I'd prefer blaming CMake, as I see the same developer keep projects in good shape when using Bazel (or another build system with similar model).
      - barumi 6y ago
        > No you don't. PARENT_SCOPE is needed to write variables into parent scope, but not read. You're talking about an entirely different thing then. Subprojects do inherit scope, but that is only relevant if you intentionally, and for some reason, want to reuse variables that were inherited. This is often used to propagate config settings from the project root to all submodules, but you only do this if that's something you explicitly want to. > Even so. Yes, when working very carefully, when you are a single developer writing on a small projects, and enforce code style, it is possible to keep the mess manageable. It really isn't. If you're dealing with a problem where random team members break stuff without oversight or awareness of what they're doing, and if this happens so often that you start to deflect blame at tooling, then you're not dealing with a build system problem. You're dealing with poor software engineering practices that not only goes way deeper than the build system but also cannot be fixed by replacing it. > When at least 100 people work on the project, if a project is several years old, if half of the team changed, CMake project is always a mess. It really isn't. What's always a mess under those circumstances is unmaintained code developed without any care or oversight, which just builds crust by accretion. The choice of build system has no influence on that outcome, not does the problem stay circumscribed to the build system. As the saying goes, bad workers always blame their tools. Well, we can extend that saying to badly managed teams.

barumi 6y ago

> each build file is independent (unlike CMake where the project is one big script with global scope and side effects) I don't understand your point. CMake projects specify build targets per module, and it's up to the developer to choose what he thinks should be a module. What value do you see in specifying build targets per file?

lightgreen 6y ago
I'm not saying about specifying build target per file. I say when cmake file includes another cmake file, all variables are inherited, and in certain cases cmake file can define variable in outer cmake file scope. Thus build files are dependent on each other. Inclusion order is important, and when project refactoring/restructuring, it's a common error, that resulting project is incorrect because for example, some file relied on the fact that when it is included, certain variables or macros are already set by someone else. This makes large project maintenance quite inconvenient. Especially because CMake does not guarantee that error will be revealed unless it is full clean rebuild.
- barumi 6y ago
  > I say when cmake file includes another cmake file, all variables are inherited, and in certain cases cmake file can define variable in outer cmake file scope. This is not true at all. You only "inherit" variables that you intentionally want to pass to downstream projects. You need to explicitly and intentionally declare your variables with PARENT_SCOPE to access variables from other files. That's an explicit decision from the developer.
  - lightgreen 6y ago
    > You only "inherit" variables that you intentionally want to pass to downstream projects Yep, most project variables, except for some locals. > You need to explicitly and intentionally declare your variables with PARENT_SCOPE to access variables from other files. No you don't. PARENT_SCOPE is needed to write variables into parent scope, but not read. > That's an explicit decision from the developer. Even so. Yes, when working very carefully, when you are a single developer writing on a small projects, and enforce code style, it is possible to keep the mess manageable. When at least 100 people work on the project, if a project is several years old, if half of the team changed, CMake project is always a mess. (Source: I worked in two very different large companies which were using CMake; both of them eventually migrated away from CMake). Someone might blame developers for making that mess. I'd prefer blaming CMake, as I see the same developer keep projects in good shape when using Bazel (or another build system with similar model).
    - barumi 6y ago
      > No you don't. PARENT_SCOPE is needed to write variables into parent scope, but not read. You're talking about an entirely different thing then. Subprojects do inherit scope, but that is only relevant if you intentionally, and for some reason, want to reuse variables that were inherited. This is often used to propagate config settings from the project root to all submodules, but you only do this if that's something you explicitly want to. > Even so. Yes, when working very carefully, when you are a single developer writing on a small projects, and enforce code style, it is possible to keep the mess manageable. It really isn't. If you're dealing with a problem where random team members break stuff without oversight or awareness of what they're doing, and if this happens so often that you start to deflect blame at tooling, then you're not dealing with a build system problem. You're dealing with poor software engineering practices that not only goes way deeper than the build system but also cannot be fixed by replacing it. > When at least 100 people work on the project, if a project is several years old, if half of the team changed, CMake project is always a mess. It really isn't. What's always a mess under those circumstances is unmaintained code developed without any care or oversight, which just builds crust by accretion. The choice of build system has no influence on that outcome, not does the problem stay circumscribed to the build system. As the saying goes, bad workers always blame their tools. Well, we can extend that saying to badly managed teams.