4 ms·

> Of course it is great when you write a language to also throw in a build tool, but in the end if the build tool re-implements 30% or so of make in a broken wa

> Of course it is great when you write a language to also throw in a build tool, but in the end if the build tool re-implements 30% or so of make in a broken way I don't see the point. Well, other build tools sometimes also do a lot more than make ever did. (And in some areas, perhaps less.) Example: Cabal/cabal-install (for Haskell) can automatically fetch all your project's dependencies and automatically compile them for you. > Make does have its limitations, but most ordinary projects get nowhere close to reaching those. I suppose it depends on what you mean by "ordinary", but IME this Makefiles by virtue of being purely file-based is useless for most of my projects. There are a many langauges (e.g. Java/Scala, Haskell) where it just doesn't fit for normal development. As an example: Tracking intra-file dependencies for proper recompilation is really difficult to for Scala code without reimplementing a huge chunk of a Scala compiler. (I'd venture to suggest that you'd be foolish to even try doing this in Make.)

majewsky 10y ago
> Tracking intra-file dependencies for proper recompilation is really difficult to for Scala code without reimplementing a huge chunk of a Scala compiler. tup (http://gittup.org/tup http://gittup.org/tup) has a really nice way of handling interdependencies. They set up some filesystem magic to figure out which files were read while compiling a certain target, and record these files as dependencies for the target. Another instance of a hard problem ("reimplementing [...] a Scala compiler") that turns into a very easy problem once you look at it from the right angle.
- gavinpc 10y ago
  I love tup so much. It's a "functional reactive" build tool that practically nobody's heard of, so I'd argue that it's even more "hipster" than make (whatever that means). When I decided I needed a single build system to replace a hodgepodge of stuff, I looked at make because that was apparently the go-to thing. It took me about 2 minutes to decide that I wanted no part of make. I'd assumed it was basically what Tup is. I'm lucky that I learned about Tup from a thread on this site, because it's made me so happy (especially once the initial pain was over... and yeah, you have to change). So whenever I see these posts, I make sure that someone is mentioning Tup as a clean alternative. edit: to be explicit, Tup is obsessed with speed and correctness, and handles incremental builds optimally (see Mike Shal's whitepaper on this). The "price" is that you can't modify files during a build. A file is either "regular" (not touched by build) or "generated" (produced wholly from one build rule). You have to describe the complete DAG up front. Because of all this, Tup will actually remove build targets when they're not needed, which I believe no other build system does. I could never go back.
  - majewsky 10y ago
    The only practical problem with tup is that it's not make, which creates friction for packagers. And since I'm doing some packaging work myself, I'm heavily optimizing for packager happiness.
- lomnakkus 10y ago
  Sure, tup is very nice, but it doesn't solve the problem in a way that leads to anywhere near efficient re-compilation on small changes (for Scala, at least -- it might be workable for Java). For that you need something like zinc[1]. This is because the dependency units in Scala don't map cleanly to files. > Another instance of a hard problem ("reimplementing [...] a Scala compiler") that turns into a very easy problem once you look at it from the right angle. Only if you don't solve the problem fully. TBH, not even zinc solves the problem 100% and sometimes does a little bit of unnecessary re-compilation. It is very good, though. [1] https://github.com/typesafehub/zinc https://github.com/typesafehub/zinc

majewsky 10y ago

> Tracking intra-file dependencies for proper recompilation is really difficult to for Scala code without reimplementing a huge chunk of a Scala compiler. tup (http://gittup.org/tup http://gittup.org/tup) has a really nice way of handling interdependencies. They set up some filesystem magic to figure out which files were read while compiling a certain target, and record these files as dependencies for the target. Another instance of a hard problem ("reimplementing [...] a Scala compiler") that turns into a very easy problem once you look at it from the right angle.

gavinpc 10y ago
I love tup so much. It's a "functional reactive" build tool that practically nobody's heard of, so I'd argue that it's even more "hipster" than make (whatever that means). When I decided I needed a single build system to replace a hodgepodge of stuff, I looked at make because that was apparently the go-to thing. It took me about 2 minutes to decide that I wanted no part of make. I'd assumed it was basically what Tup is. I'm lucky that I learned about Tup from a thread on this site, because it's made me so happy (especially once the initial pain was over... and yeah, you have to change). So whenever I see these posts, I make sure that someone is mentioning Tup as a clean alternative. edit: to be explicit, Tup is obsessed with speed and correctness, and handles incremental builds optimally (see Mike Shal's whitepaper on this). The "price" is that you can't modify files during a build. A file is either "regular" (not touched by build) or "generated" (produced wholly from one build rule). You have to describe the complete DAG up front. Because of all this, Tup will actually remove build targets when they're not needed, which I believe no other build system does. I could never go back.
- majewsky 10y ago
  The only practical problem with tup is that it's not make, which creates friction for packagers. And since I'm doing some packaging work myself, I'm heavily optimizing for packager happiness.
lomnakkus 10y ago
Sure, tup is very nice, but it doesn't solve the problem in a way that leads to anywhere near efficient re-compilation on small changes (for Scala, at least -- it might be workable for Java). For that you need something like zinc[1]. This is because the dependency units in Scala don't map cleanly to files. > Another instance of a hard problem ("reimplementing [...] a Scala compiler") that turns into a very easy problem once you look at it from the right angle. Only if you don't solve the problem fully. TBH, not even zinc solves the problem 100% and sometimes does a little bit of unnecessary re-compilation. It is very good, though. [1] https://github.com/typesafehub/zinc https://github.com/typesafehub/zinc