MakeMake: Generate make files from C source code

There's generally a much nicer way to handle this so that the dependencies don't have to get generated before the first compile (and are instead generated as a side effect of the first compile, which is sufficient as the first build will always be complete and you only need granular dependency information for proper incremental rebuilds).

    CFLAGS += -MD
    -include $(wildcard *.d)

I personally like to also pass `-MP` to add phony targets so removing a header doesn't complain about headers which are intentionally removed.

You can pass `-MMD` instead of `-MD` to avoid having system includes in the generated depfiles just like the example you wrote does.

I also personally prefer to be explicit and avoid wildcards in makefiles wherever possible so I would do something like this:

    CFLAGS += -MD -MP
    objs := foo.o bar.o ... baz.o
    deps = $(objs:.o=.d)
    
    ...
    
    -include $(deps)

That being said, this doesn't solve the "everything should depend on the Makefile" problem as well as the "what if I generate a generate source code" problem or finally "what if I have to compile C to generate C to compile my program" problem.

As such, I have personally switched to redo.

Going on a tangent here, but properly integrating support for such "discovered" dependencies in GNU Make can get a bit complicated.

In particular, you probably want to use `-include` instead of `include`, to continue even a given .dep file doesn't exist (as on the first run).

The GNU Make maintainer wrote in-depth about ways to do it here: https://make.mad-scientist.net/papers/advanced-auto-dependen...

Clang's docs say -MM includes only user dependencies, -MD includes user and system dependencies. A better choice if your system includes might change.

It's also not like this is new - I know I've been using gcc to output dependencies for Makefiles for at least 2 decades, presumably it was around long before then.

That's the way to go in my opinion. The FreeBSD folks build their entire damn project with make, although I'll admit my eyes glaze over a bit anytime I take a look at it.

CMake is just a little too high level for my taste. Like I don't really understand how its figuring stuff out under the hood. Now that is of course because I haven't bothered studying up on it, but the point is you don't really have to with Make since the basic concept is dead simple.

>My interest in make and makemake has recently been rekindled.

Did you have an interest in makemake before? This github repo looks brand new.

Might have something to do with https://en.wikipedia.org/wiki/Makemake:

> In July 2008, in accordance with IAU rules for classical Kuiper belt objects, 2005 FY9 was given the name of a creator deity. The name of Makemake, the creator of humanity and god of fertility in the myths of the Rapa Nui, the native people of Easter Island, was chosen in part to preserve the object's connection with Easter.

It builds a Android APK with one line of comand line on a fresh install linux to begin with (Thanks to Felix) thats pretty cool.

Id say the main use case is to move dependencies from a project file to the actiual C files that have the dependencies, This way if the dependencies change all projects that use the file have their build process automaticaly updated. It also removes the need to list the files included in a project since this is information that already exists in the .c files.

Any time you have to define the same thing in two places, you have the risk of them not beeing in sync. This way there is only one canoical ground truth. Source and build process can never be out of sync.

I use CMake, but can completely understand wanting to avoid it. The Makefiles that CMake produces are not at all what you want for correct reproducible builds.

* Before CMake 3.20, released in 2021, CMake tracked dependencies at configuration time. As a result, any time you add/remove a header file, you need to re-run CMake in order to have correct builds. CMake 3.20 finally delegated this out to the underlying compiler.

* The Makefile produced by CMake does not have a target for the object file. Even though it prints out the path `CMakeFiles/cmake_target.dir/src/my_file.cc.o`, and generates that file, you cannot run `make CMakeFiles/cmake_target.dir/src/my_file.cc.o` from inside the build directory. Instead, you need to run `make src/my_file.cc.o`, a PHONY target which actually builds the object file.

* Wildcard rules in CMake are expanded to static rules in Make, rather than wildcard rules. As a result, any time you add/remove a file, such as when checking out a new branch, you need to re-run CMake in order to have a correct build.

* Until recently, the makefiles produced by CMake did give useful information with `make --dry-run`. Instead of printing the command required to compile a file, it instead printed an internal delegation back to cmake.

* Non-transferable build. The `CMakeCache.txt` stores a record of what options have been enabled/disabled, but also has local file information. As a result, the contents of `CMakeCache.txt` are essential to know what I actually built, but I cannot send it to somebody else as a way to reproduce my build. Makefiles generally avoid this by having explicit include files, which then can be transferred.

So, in order to have correct and reproducible builds, I need to re-run CMake every time I'm building a project, the usual tools for debugging a build error are broken, and including my build environment in a bug report is useless for reproduction. I can see why somebody would want to avoid it.

Because Cmake requires a configuration file for each project. With makemake i can with a single command line build a new project without any configuration needed. Its one less thing to maintain.

If you're never using any external dependencies, it can work. It's just the no-dep C projects are few and far between. As soon as you have things like dependencies or compiler detection, CMake or other build systems really start picking up a lot of slack.

FD: CMake developer

Yep, modern CMake makes this super easy, its a solved problem.

And with CMake, you also get a standard framework for testing, installing, packaging, and integrating external packages.

You are shooting your future self in the foot by going out of your way to use a handbuilt new framework.

It can still be valuable as a learning project.

Here is the fundamental problem it solves for me: my code in 99% pure C code without dependencies. Then i have a few wrappers for platform specific stuff. I have many many projects that use the same wrappers. Make files store both what files are used and what dependencies there are, but that creates a lot of duplication. Its better if the wrappers themselves can say what dependencies they have. Then thats stored in one place, and a change affects all projects. Then we have the issue of what files are needed. That information already exists in the .c files, so again why duplicate it? Its better to parse it out.

Yes, even MS' cl has `/sourceDependencies` and `/scanDependencies` by now, which generate JSON files with the needed information.

Nice quick and dirty hack, but the latency isn't great and it will hammer the file system in large projects calculating time stamps. It's especially bad on windows although polling on mac has also historically been rather expensive (linux is better in this regard though polling still isn't free).

I'd much rather install entr if it's available and do something like

`ls ** | entr -c make`

THIS is the lightest way to have continuous make, without wasting cycles and hammering the file system. inotifywait is a pretty standard tool that does exactly what's needed.

watch : while true; do \ clear; $(MAKE) -j all tests; \ inotifywait -qre close_write src tests; \ done

Yes. I had an early implementation that did look for any function declarations, but using extern made it more robust, and enforces the use of extern, something i think helps with clarity.

That's built in. Read the readme. :)

m4?

Autotools are so big for tiny projects though. Like if I need a small util I'm not configuring autotools.

Do you have a link or more info on this?

Can you please make your substantive points without swipes?

This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.

(Edit: I see downthread that you mentioned it wasn't your intention.)

Um, you do know that the word "can" indicates a personal preference and has no effect on functionality, so there is no need to be passive aggressive?