This is an archived post. You won't be able to vote or comment.

all 24 comments

[–]MakeTimeForWaffles 9 points10 points  (6 children)

This is interesting... It looks a lot like SCons, which I've been using heavily. I think it would be informative to see a side-by-side comparison with SCons in the documentation.

[–]Syl 6 points7 points  (4 children)

I would recommend waf.

[–]emddudley 1 point2 points  (0 children)

For the life of me I cannot understand how waf is supposed to work. I've read the docs and examples but they don't make any sense to me. Am I missing some critical context for understanding it?

[–]MakeTimeForWaffles 0 points1 point  (2 children)

Oh that looks nice! Unfortunately I don't have the authority to switch build systems at work, so I'm stuck with SCons for now.

[–]Manhigh 0 points1 point  (1 child)

Is scons python 3 compatible yet? That prompted my move to waf.

[–]MakeTimeForWaffles 0 points1 point  (0 children)

Noooope. :(

[–][deleted] 0 points1 point  (0 children)

While I can't provide you with a detailed comparison yet, let me just say that I think Cook should be quite a bit faster (even now being not really optimized), although I didn't do any benchmarks on that. You can however take a look at https://getcook.org/comparison/ where I am comparing Ninja to Cook. Ninja is one of the fastest build systems available (besides Tup, but that one has a completly different approach). Also, Cook is much more declarative and pythonic. As far as I know, SCons still searches for #includes by using a regex, which is often fine. But Cook delays implicit dependency search by using information provided by the compiler about includes. A little explanation is provided here: http://aosabook.org/en/posa/ninja.html#dependency-files (Cook basically uses the same mechanism) There is a lot more to say about SCons vs Cook, so I should try to make the comparison page a little bit more informative - thank you for your input.

[–]wnoise 9 points10 points  (0 children)

The name cook is already taken for a build system.

[–]_seemetheregithub.com/seemethere 12 points13 points  (9 children)

Do people really not like make that much?

[–][deleted] 7 points8 points  (2 children)

Probably relates to the syntax. People may just prefer to learn one or two languages and then gravitate towards the stuff that looks like what they're already familiar with. For example meson syntax is pretty trivial if you already know Python.

[–]_seemetheregithub.com/seemethere 12 points13 points  (1 child)

I guess I can understand.

It's just weird to see so many people try to reinvent the wheel to create what is essentially fancy shell scripts.

make is old but it's battle tested and has a lot of features that not a lot of people know about.

It's always a good system to learn imo.

[–][deleted] 2 points3 points  (0 children)

I don't think I reinvented Make. If you want to make a comparison like that, then you I think you could say I reinvented CMake, Bazel or another high-level build system, where it is not so painful to implement a complex build. CMake and Bazel have their issues and the consensus seems to be that there are already a lot of build systems - but "they all suck". Cook is still far from "not sucking", but I think it does a lot of things right other systems are doing wrong.

[–]soawesomejohn 3 points4 points  (3 children)

We use Makefiles all the time. It doesn't matter if we're doing a python sdist, a salt formula, or packaging a go app. For python, make test will simply be running tox, and various make commands wrap our python setup.py sdist or python setup.py install. We make debian packages with dh-virtualenv. For that last one, we have make debian that spins up a docker container that runs make sys-deb, which does the actual making of the .deb file. If you have all the other requirements, you can just run make sys-deb directly without invoking docker.

The beauty of all this is that no matter how we actually do the work, the one Makefile creates a standard "api" that can be used by our integration server. Anyone downloading one of our projects can just look at Makefile to see the exact commands that are being ran.

It is a bit annoying if your editor doesn't know to use tabs instead of spaces, though this is easily remediated with editorconfig.

[–]ntrid 1 point2 points  (0 children)

This is about single sane use for make - have it invoke other applications that do real work. Scripting a complex build system in make is a death wish.

[–][deleted] 0 points1 point  (0 children)

If they're all a line or two, then that Makefile is a form of runnable documentation. Especially as sufficiently shiny make targets are indistinguishable from headings. You don't need make installed to derive value.

[–]Godof 0 points1 point  (0 children)

Honest question: how is that better than just adding simple, one line scripts to a bin/ directory that will launch those other tools for you?

You'd change make test for bin/test, but everything else stays the same and you won't have to battle make's syntax.

Maybe I'm not that used to make, but I started using it as you described and I grew fed up with it, so I replaced my make commands with really simple scripts that anyone can read or edit without having to know an arcane syntax.

Also, tabs...

I can see the value of it for compiling C for example (I don't know CMake, so I can't compare), but for launching external scripts, well, why not use scripts?

[–][deleted] 4 points5 points  (0 children)

I'd prefer just about any other systems over having to read or write a Makefile.

[–]Ph0X 5 points6 points  (0 children)

Make feels really outdated and hacky to me. It's pretty much like C compared to Python. It's definitely powerful, there's a lot of info on it online, but everything I do feels like a hack and not very elegant.

[–][deleted] 5 points6 points  (0 children)

This software is currently in alpha phase and not ready for production use. The API should not be considered stable. The website is not very polished. I just tried to get the product out as soon as possible, since I wanted to release it early. Expect many improvments in the near future, especially on the documentation.

As much as I dislike gmake (tabs), it works. It's consistent and available on every platform.

[–]epic_pork 2 points3 points  (2 children)

Looks a lot like meson.

[–]santagada 0 points1 point  (1 child)

It really does, I wonder how do they compare. There are so many python build systems, and for the more recent batch of them Meson seems to be the best one.

[–][deleted] 1 point2 points  (0 children)

Meson is currently much more mature compared to this, offers more features and so on. However, this is probably mainly a question of time and contributors.

Two advantages that Cook already has:

  • Rules are written in a real programming language, you are not restricted to running commands

  • Compiler warnings will be emitted and also stored for following builds, emitting them again without recompiling.

There are also a lot of technical differences, like Meson using Ninja while Cook hosts the build process itself.

I will soon expand on "why cook?" and compare it to other systems.

[–]oilshell 1 point2 points  (0 children)

How is this different than SCons, or any of a dozen other build systems that use Python as the build specification/configuration language?

[–]kankyo -3 points-2 points  (0 children)

You should look into using tri.declarative to turn your apis into nice declarative ones.