8 ms·

> CMake is an out-of-tree tool, which is something the project tries to avoid at all costs for portability and maintainability reasons. Is this relevant though

> CMake is an out-of-tree tool, which is something the project tries to avoid at all costs for portability and maintainability reasons. Is this relevant though? Portability is not dictated by whether you vend a tool within your project tree, and maintainability is only remotely relevant if you're planning on customizing the tool instead of the scripts executed by the tool, which would be silly. I mean, there is no wrong in just coming forward and stating that you're already using a build system in another project and you're hoping to lower maintenance costs by standardizing on a single build system that you're already using. All other arguments sound dubious at best.

sgbeal 2y ago
> > CMake is an out-of-tree tool, which is something the project tries to avoid at all costs for portability and maintainability reasons. > Is this relevant though? For this project and its day-to-day maintenance, unequivocally. One of Richard's philosophies is "freedom means being able to take care of yourself," and that philosophy permeates all of his software projects, which eschew external dependencies because every single one reduces the project's level of freedom. Every time a third-party tool breaks, or introduces new, incompatible behavior as part of an upgrade, dependents of that tool suffer[^1]. All of Richard's projects have a strong culture of avoiding that suffering by avoiding third-party dependencies where at all possible, to the point of sometimes reinventing the wheel to extreme degrees (like implementing his own SCM). That aspect aside, nobody in the SQLite project uses CMake, so it would never occur to us to migrate the build process to it. We write our own makefiles by hand _and we like it that way_. (Sidebar: Autosetup neither writes our makefiles nor introduces new syntax for doing so, in contrast to CMake.) > I mean, there is no wrong in just coming forward and stating that you're already using a build system in another project and you're hoping to lower maintenance costs by standardizing on a single build system that you're already using. All other arguments sound dubious at best. This isn't about standardizing on one build process, but about simplifying the lives of the developers and future maintenance of the project. We can't do that by porting to tools we don't otherwise use. If we weren't using Autosetup in other trees, and weren't happy with it, we wouldn't have even considered undertaking this effort and facing the downstream upheaval it will undoubtedly cause. We know, however, from 13 years of experience with it, that this tool does what we want, is low friction, and causes us an amount of grief which closely approaches zero[^2]. Without our collective background with Autosetup, we wouldn't have even considered porting away from the Autotools because that would be a case of "out of the frying pan and into the oven." [^1]: As a concrete example: the SQLite project's WASM build is 100% dependent on the Emscripten toolchain for the simple reason that there is no feasible alternative. A handful of times over the past two years we have had to accommodate incompatible changes when upgrading Emscripten. That's hassle nobody wants. Obviously, software has to evolve, but being able to embed our build tools (Autosetup) directly in the source tree gives us control over the pace of that evolution. No system-wide upgrade is going to pull it out from under us, nor will it behave differently on downstream folks' machines. [^2]: You won't ever hear me say that _any_ software is 100% grief-free, but autosetup is as close to it as, e.g., the bash shell.
- chipdart 2y ago
  > For this project and its day-to-day maintenance, unequivocally. Insisting on personal assertions does not pass as a justification, particularly one based on such specious reasoning. > One of Richard's philosophies is "freedom means being able to take care of yourself," (...) That's fine. Irrelevant to the discussion, though. If you're really really concerned with somehow losing access to a build tool managed by a third-party, nothing prevents you from storing the tool anywhere, including in a separate Git repository. Just say it's personal taste and technical merits play no role in the decision. All these wild claims just sound silly.
  - sgbeal 2y ago
    > Just say it's personal taste and technical merits play no role in the decision. Reducing long-term maintenance burden and simplifying the developers' work is arguably the best technical merit we could hope for. > All these wild claims just sound silly. And, with that, i'm stepping out of this sub-thread.
  - pjc50 2y ago
    This is such a HN answer, presenting your own personal taste as technical merits and the technical merits of other's approaches as wild claims.
  - HelloNurse 2y ago
    It isn't about losing access to the tool, it's about lacking control of what the tool does. For example, suppose that the CMake developers, due to last-straw Unicode bugs, lose sanity and decide that from next version (in a few weeks) an initial BOM and UTF-8 encoding in all files will be mandatory: are you ready to check and adjust all your source files and review your text editors (or to fork CMake)? More realistic scenarios include users discovering novel CMake bugs and changed defaults after updating CMake and developers discovering useful things that are impossible with CMake because of old bugs and limitations.

sgbeal 2y ago

> > CMake is an out-of-tree tool, which is something the project tries to avoid at all costs for portability and maintainability reasons. > Is this relevant though? For this project and its day-to-day maintenance, unequivocally. One of Richard's philosophies is "freedom means being able to take care of yourself," and that philosophy permeates all of his software projects, which eschew external dependencies because every single one reduces the project's level of freedom. Every time a third-party tool breaks, or introduces new, incompatible behavior as part of an upgrade, dependents of that tool suffer[^1]. All of Richard's projects have a strong culture of avoiding that suffering by avoiding third-party dependencies where at all possible, to the point of sometimes reinventing the wheel to extreme degrees (like implementing his own SCM). That aspect aside, nobody in the SQLite project uses CMake, so it would never occur to us to migrate the build process to it. We write our own makefiles by hand _and we like it that way_. (Sidebar: Autosetup neither writes our makefiles nor introduces new syntax for doing so, in contrast to CMake.) > I mean, there is no wrong in just coming forward and stating that you're already using a build system in another project and you're hoping to lower maintenance costs by standardizing on a single build system that you're already using. All other arguments sound dubious at best. This isn't about standardizing on one build process, but about simplifying the lives of the developers and future maintenance of the project. We can't do that by porting to tools we don't otherwise use. If we weren't using Autosetup in other trees, and weren't happy with it, we wouldn't have even considered undertaking this effort and facing the downstream upheaval it will undoubtedly cause. We know, however, from 13 years of experience with it, that this tool does what we want, is low friction, and causes us an amount of grief which closely approaches zero[^2]. Without our collective background with Autosetup, we wouldn't have even considered porting away from the Autotools because that would be a case of "out of the frying pan and into the oven." [^1]: As a concrete example: the SQLite project's WASM build is 100% dependent on the Emscripten toolchain for the simple reason that there is no feasible alternative. A handful of times over the past two years we have had to accommodate incompatible changes when upgrading Emscripten. That's hassle nobody wants. Obviously, software has to evolve, but being able to embed our build tools (Autosetup) directly in the source tree gives us control over the pace of that evolution. No system-wide upgrade is going to pull it out from under us, nor will it behave differently on downstream folks' machines. [^2]: You won't ever hear me say that _any_ software is 100% grief-free, but autosetup is as close to it as, e.g., the bash shell.

chipdart 2y ago
> For this project and its day-to-day maintenance, unequivocally. Insisting on personal assertions does not pass as a justification, particularly one based on such specious reasoning. > One of Richard's philosophies is "freedom means being able to take care of yourself," (...) That's fine. Irrelevant to the discussion, though. If you're really really concerned with somehow losing access to a build tool managed by a third-party, nothing prevents you from storing the tool anywhere, including in a separate Git repository. Just say it's personal taste and technical merits play no role in the decision. All these wild claims just sound silly.
- sgbeal 2y ago
  > Just say it's personal taste and technical merits play no role in the decision. Reducing long-term maintenance burden and simplifying the developers' work is arguably the best technical merit we could hope for. > All these wild claims just sound silly. And, with that, i'm stepping out of this sub-thread.
- pjc50 2y ago
  This is such a HN answer, presenting your own personal taste as technical merits and the technical merits of other's approaches as wild claims.
- HelloNurse 2y ago
  It isn't about losing access to the tool, it's about lacking control of what the tool does. For example, suppose that the CMake developers, due to last-straw Unicode bugs, lose sanity and decide that from next version (in a few weeks) an initial BOM and UTF-8 encoding in all files will be mandatory: are you ready to check and adjust all your source files and review your text editors (or to fork CMake)? More realistic scenarios include users discovering novel CMake bugs and changed defaults after updating CMake and developers discovering useful things that are impossible with CMake because of old bugs and limitations.