Hacker News Reader

Comment by anemitz | Hacker News Reader

Jason stole my HN love here, but basically lazymake is a top-down recursive build mechanism that's (hopefully) simpler to use than writing lengthy makefiles for all the sub-components in the project.

At the heart of the system is a common makefile that defines rules for building the targets. The sub-components can then define simpler makefiles, which include just a list of directives (targets, sources, dependencies, etc.). The common makefile interprets those directives, compiles them into make targets and executes the make.

Would love to hear how everyone else deals with Makefiles for their random side-projects. Don't be shy, C++ is still cool:)

View on HN

I haven't had a hard look, but this reminds me of the Android build system. Was that an inspiration / have you had a look at it? It's quite nice. One issue I have with all build systems, Android's included, is the amount of magic that goes on -- variables defined in other files which are automatically in scope for your Make file, and, worse, variables you define being magically modified by something else. This is an issue for all Make-based systems because there are so many possible sources for variable definitions. Scons is also guilty of this. Any thoughts on reducing that issue?

> Would love to hear how everyone else deals with Makefiles

I use SCons.

I wrote better-makefiles, a project that appears to be similar in scope. I've used it on half a dozen small to medium projects. Since I'm very familiar with it, I can get a new project up and running in about a minute.

https://github.com/kbob/better-makefiles

We're in the process of switching from scripts + Makefiles to scripts + CMake. The scripts with CMake are simpler (do less than the old scripts), and the CMake files are really easy to deal with--but public documentation completely sucks for CMake.

I've been using premake4 (after trying SCons and waf). But to be honest, I'm never happy. Here I really love the simplicity of just including a single file. I'll definitely give lazymake a whirl next time I make a small project.

What do you do for including a subproject that already has its own Makefiles? For example, my huge build system includes a bunch of components, including the Linux kernel and a bunch of libraries, as well as my app.

I don't know if there's a 'correct' answer to this, but if you wanted to try the path of least resistance you could make your existing sub-components build with a RUNNABLE option in lazymake. You'd end up just using the existing make files that way.

Not sure if that answers your question...

I generally stay away from building external dependancies at the same time as my project. Whenever I start a new project that needs 3rd party libs I build them all statically and version them off in my repo.

What are the advantages of this over something like the GNU Autotools? In particular over Automake which seems to handle a lot of what this does?

Don't mean to criticize, just curious. :)

The main advantage here is that it should be easier to learn and use. The disadvantage is that the simplicity comes with a price -- it isn't as customizable as the automake. But the intention isn't to replace a system like that, just make it easier for projects to get up and running quickly.

Do you use automake for all of your projects or just the larger scale ones?

Reply on news.ycombinator.com