5 ms·

I suspect a large amount of the issue is sheer availability. There's an odd proclivity of developers of build tools to assume that their favorite runtime (be i

I suspect a large amount of the issue is sheer availability. There's an odd proclivity of developers of build tools to assume that their favorite runtime (be it python for scons, etc) is already available or trivial to nicely install. And that's just... not true. The build tool itself is the one place in the ecosystem of building software that we have the least room for manual dependency handling and manual setup, because there's nowhere left to punt the hard part. Make isn't better at this either, but it's been so widely packaged and is so nearly-default available (it's remarkably hard to get a working desktop system without some transitive dependency having gotten make installed for you) that it defacto gets a free pass on this. My hypothesis is that these newer build tools would have a much better shot at reaching adoption if they were well-packaged enough that a single tarball (with zero external deps) or a single-line install script (think: "gradlew", though even that was cheating by assuming an existing jvm) could bootstrap them. Most don't seem to have invested that effort. And it shows.

geezerjay 8y ago
Tarbals are a poor packaging method as they require users to install applications manually without ensuring dependencies or pre/post installation configuration. However, taking the time to put together a working installation package for specific platforms is something that does wonders to the app's adoption. It's all about providing a standard distribution method and standard installation in a platform so that it becomes a fixed target for end-users and developers.
- heavenlyhash 8y ago
  > require users to install applications manually without ensuring dependencies or pre/post installation configuration. Yet my point is the converse of this: by not supporting those things, it means for something to be well packaged as a tarball, it may not have any external dependencies nor may it have pre/post installation hooks. And that's a Good Thing. Because why would you need any of these things? And how can you survive that level of complexity when the thing in question is itself the build tool which is traditionally the thing that we use to handle these complexities? This may just be "my opinion", but I think my build tool should have packages available which have no further recursive dependencies -- the buck has to stop somewhere -- and it certainly shouldn't need post-install hooks for absolutely any purpose -- what would it use them for? Doing something stateful? That's antithetical to the core of what a good build tool should be doing.
mpweiher 8y ago
> ... sheer availability. I suspect you're right. And make (or whatever your platform default) is Good Enough™ for most people. The heavy hitters (Microsoft, Google, ...) have code bases that are orders of magnitude larger than what most others have so their needs may just be different. Anyway, one approach I find intriguing in terms of "availability" is what Jai uses: build "scripts" are just Jai programs evaluated at compile time. So if you are building a Jai program, it'll obviously be available. A related aspect that somewhat still bugs me is that build systems really just seem to be special-purpose instances of one-way dataflow constraints[1], a feature that is tremendously useful not just for build systems, but also for UI/model interaction (MVC, one-way-dataflow, bindings), spreadsheets, etc. Combining the two: shouldn't we have a language that supports dataflow constraints, and then use a part of the program that builds the rest of the program? [1] https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and-cocoa-bindings.html https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-an...
- cat199 8y ago
  > The heavy hitters (Microsoft, Google, ...) have code bases that are orders of magnitude larger than what most others have so their needs may just be different. and yet I can mostly-deterministically build any of the main BSD kernels + base systems + UI + all applications and sometimes even package them into release media using 1-3 PMake invocations.. (without needing to embed a QT-based configuration GUI to do it).. don't think msft or goog need to build anything more complicated than that.. and i'd wager if they do some other process isn't working correctly.. (side note PMake is much better than GNUMake imho; syntax is more 'shelly' and there are build in looping constraints abilty to dynamically define targets based on variable contents (e.g. define a target 'T' who's target name will be the contents of the variable 'V'), unlike GNUmake's bizarre quasi-lispy syntax and functions) > one-way dataflow constraints definately not up on the theory; this sounds very similar to make target heirarchies (e.g target X is constrained by presence/absence of artifact Y)

geezerjay 8y ago

Tarbals are a poor packaging method as they require users to install applications manually without ensuring dependencies or pre/post installation configuration. However, taking the time to put together a working installation package for specific platforms is something that does wonders to the app's adoption. It's all about providing a standard distribution method and standard installation in a platform so that it becomes a fixed target for end-users and developers.

heavenlyhash 8y ago
> require users to install applications manually without ensuring dependencies or pre/post installation configuration. Yet my point is the converse of this: by not supporting those things, it means for something to be well packaged as a tarball, it may not have any external dependencies nor may it have pre/post installation hooks. And that's a Good Thing. Because why would you need any of these things? And how can you survive that level of complexity when the thing in question is itself the build tool which is traditionally the thing that we use to handle these complexities? This may just be "my opinion", but I think my build tool should have packages available which have no further recursive dependencies -- the buck has to stop somewhere -- and it certainly shouldn't need post-install hooks for absolutely any purpose -- what would it use them for? Doing something stateful? That's antithetical to the core of what a good build tool should be doing.

mpweiher 8y ago

> ... sheer availability. I suspect you're right. And make (or whatever your platform default) is Good Enough™ for most people. The heavy hitters (Microsoft, Google, ...) have code bases that are orders of magnitude larger than what most others have so their needs may just be different. Anyway, one approach I find intriguing in terms of "availability" is what Jai uses: build "scripts" are just Jai programs evaluated at compile time. So if you are building a Jai program, it'll obviously be available. A related aspect that somewhat still bugs me is that build systems really just seem to be special-purpose instances of one-way dataflow constraints[1], a feature that is tremendously useful not just for build systems, but also for UI/model interaction (MVC, one-way-dataflow, bindings), spreadsheets, etc. Combining the two: shouldn't we have a language that supports dataflow constraints, and then use a part of the program that builds the rest of the program? [1] https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and-cocoa-bindings.html https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-an...

cat199 8y ago
> The heavy hitters (Microsoft, Google, ...) have code bases that are orders of magnitude larger than what most others have so their needs may just be different. and yet I can mostly-deterministically build any of the main BSD kernels + base systems + UI + all applications and sometimes even package them into release media using 1-3 PMake invocations.. (without needing to embed a QT-based configuration GUI to do it).. don't think msft or goog need to build anything more complicated than that.. and i'd wager if they do some other process isn't working correctly.. (side note PMake is much better than GNUMake imho; syntax is more 'shelly' and there are build in looping constraints abilty to dynamically define targets based on variable contents (e.g. define a target 'T' who's target name will be the contents of the variable 'V'), unlike GNUmake's bizarre quasi-lispy syntax and functions) > one-way dataflow constraints definately not up on the theory; this sounds very similar to make target heirarchies (e.g target X is constrained by presence/absence of artifact Y)