4 ms·

Why autosetup? Because it'll hopefully keep the build commands the same? Or are there more fundamental reasons to prefer it over cmake?

sgbeal 2y ago
> Why autosetup? A link in the original post leads to a description of the motivation for the port. TL;DR: we've used Autosetup since 2011 in SQLite's sibling, the Fossil SCM, and we quite like it. > Or are there more fundamental reasons to prefer it over cmake? CMake is an out-of-tree tool, which is something the project tries to avoid at all costs for portability and maintainability reasons. GNU Autotools lives halfway in-tree and halfway out-of-tree. It's ubiquitous but also often problematic to upgrade, and is subject to breakage when project developers have different versions of the Autotools installed on their systems. Richard very specifically keeps an ancient version of Autotools on his system to reduce that pain, but that's not a satisfying situation to be in. Autosetup, on the other hand, lives entirely in the project's source tree, meaning we have not only consistency across all developers' machines, but also complete control over when to upgrade (or not) the tools. Over the past 13ish years of using Autosetup in the Fossil SCM we have never had any significant upgrade-related pains.
- chipdart 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? 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.
- account42 2y ago
  > Autosetup, on the other hand, lives entirely in the project's source tree Is it really desirable to have complex build tools be part of the project, especially after the xz-utils takeover?
  - MarkSweep 2y ago
    To my eyes, the TCL that makes up configs for AutoSetup as well as the tool itself are much easier to read and audit than the M4 used in AutoTools projects. So I think this is an improvement. See the sources in FossilSCM for an example (auto.def file) https://fossil-scm.org/home/tree?type=tree&ci=trunk https://fossil-scm.org/home/tree?type=tree&ci=trunk
  - sgbeal 2y ago
    > Is it really desirable to have complex build tools be part of the project, especially after the xz-utils takeover? That's a fair question, but i'm confident that in this case such a risk is simply not there. We've interacted with the maintainer of Autosetup and JimTCL (the same guy) for more than a decade and know he runs a proverbial "tight ship." Autosetup has two major components: - TCL-based scripts to process configure-style scripts and work with file templates in a way nearly identical to autotools (e.g. Makefile.in uses the same syntax). - JimTCL is a TCL implementation which lives in the tree, allowing folks who won't have the canonical TCL installed to run the build. Steve Bennett maintains both of those and is extremely conscientious about what goes into his trees. Over the years, as we've updated our in-tree copy in the Fossil SCM, it's become habit to peruse the diffs of the upgraded files, comparing them to our previous install. In the unlikely case that someone were to sneak some mischief in, i'm fairly confident that we would catch it, at the latest, at that point (before checking in that change to our project).
wolf550e 2y ago
They prefer tcl as the scripting language and they like the maintainer.
- sgbeal 2y ago
  > They prefer tcl as the scripting language and they like the maintainer. That's most definitely a big part of it, but see my other response in this sub-thread for other aspects which are equally important for the project.

sgbeal 2y ago

> Why autosetup? A link in the original post leads to a description of the motivation for the port. TL;DR: we've used Autosetup since 2011 in SQLite's sibling, the Fossil SCM, and we quite like it. > Or are there more fundamental reasons to prefer it over cmake? CMake is an out-of-tree tool, which is something the project tries to avoid at all costs for portability and maintainability reasons. GNU Autotools lives halfway in-tree and halfway out-of-tree. It's ubiquitous but also often problematic to upgrade, and is subject to breakage when project developers have different versions of the Autotools installed on their systems. Richard very specifically keeps an ancient version of Autotools on his system to reduce that pain, but that's not a satisfying situation to be in. Autosetup, on the other hand, lives entirely in the project's source tree, meaning we have not only consistency across all developers' machines, but also complete control over when to upgrade (or not) the tools. Over the past 13ish years of using Autosetup in the Fossil SCM we have never had any significant upgrade-related pains.

chipdart 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? 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.
account42 2y ago
> Autosetup, on the other hand, lives entirely in the project's source tree Is it really desirable to have complex build tools be part of the project, especially after the xz-utils takeover?
- MarkSweep 2y ago
  To my eyes, the TCL that makes up configs for AutoSetup as well as the tool itself are much easier to read and audit than the M4 used in AutoTools projects. So I think this is an improvement. See the sources in FossilSCM for an example (auto.def file) https://fossil-scm.org/home/tree?type=tree&ci=trunk https://fossil-scm.org/home/tree?type=tree&ci=trunk
- sgbeal 2y ago
  > Is it really desirable to have complex build tools be part of the project, especially after the xz-utils takeover? That's a fair question, but i'm confident that in this case such a risk is simply not there. We've interacted with the maintainer of Autosetup and JimTCL (the same guy) for more than a decade and know he runs a proverbial "tight ship." Autosetup has two major components: - TCL-based scripts to process configure-style scripts and work with file templates in a way nearly identical to autotools (e.g. Makefile.in uses the same syntax). - JimTCL is a TCL implementation which lives in the tree, allowing folks who won't have the canonical TCL installed to run the build. Steve Bennett maintains both of those and is extremely conscientious about what goes into his trees. Over the years, as we've updated our in-tree copy in the Fossil SCM, it's become habit to peruse the diffs of the upgraded files, comparing them to our previous install. In the unlikely case that someone were to sneak some mischief in, i'm fairly confident that we would catch it, at the latest, at that point (before checking in that change to our project).

wolf550e 2y ago

They prefer tcl as the scripting language and they like the maintainer.

sgbeal 2y ago
> They prefer tcl as the scripting language and they like the maintainer. That's most definitely a big part of it, but see my other response in this sub-thread for other aspects which are equally important for the project.