Hacker News Reader

Hacker News

Comment by oau123 | Hacker News Reader

Full thread

oau123

Also known as Makefile :P

View on HN

Tell me you’re not a C/C++ developer without telling me you’re not a C/C++ developer.

Gotta be one hell of a makefile.

GNU Autotools: A beutiful thing

GNU Autotools: A hideous thing

What? Makefile doesn't cache anything

make recompiles source code files by detecting the last modified date on a file, hence it only recompiles source files as necessary. So if you have 10 source files with 5000 lines of C in them, and you only change one of them, it will not recompile everything, it will only recompile that source file which has changed.

Which makes me agree with the parent above, I don't see how exactly Ccache is supposed to be used. Maybe for a distributed source directory with many developers working on it?

If you have perfect description of dedepencies, and you develop alone, ccache is not useful.

But how many times have I seen perfect description of deps?

    gcc -o hello hello.c

Or if you never switch branches in git, or never rerun configure, never switch between -O0 and -O3, never run make clean, never…

It was my experience that building a native Android project with older NDKs benefitted hugely from introduction of ccache. Especially if you had multiple branches of the same code (release/nightly) that shared a significant code base.

That was pre-Android Studio times. IDK what is the situation now.

Still true now, especially if you switch branches/variants/flavors or do multiple builds.

On ccache site, there is section "Why bother?", the very first line:

>If you ever run `make clean; make`, you can probably benefit from ccache. It is common for developers to do a clean build of a project for a whole host of reasons, and this throws away all the information from your previous compilations. By using ccache, recompilation goes much faster.

Putting aside my tongue-in-cheek comment, honestly this argument does not convince me very much.

What is the purpose of "make clean" other than to invalidate the whole cache so that it is cleanly recompiled? In such a situation I would want to invalidate the cache from ccache also completely.

I'm sure there are legitimate reasons for using ccache but it is not very obvious to me what it is:

"Only knows how to cache the compilation of a single file. Other types of compilations (multi-file compilation, linking, etc) will silently fall back to running the real compiler. "

Well yes, traditional use of makefiles has been exactly to cache the compilation of single compilation units and trigger the compile of changed units - ccache does not help with granularity here it seems.

Distributed development might be a good argument for this, but then what does it offer to faciliate that? It seems to suggest using NFS - which I could do with a Makefile as well. So is the advantage that it uses hashes instead of timestamps? Timestamps work quite well for me, but maybe that is a valid point.

Another argument could be that is stores the precompiled units somewhere else and therefore doesn't clutter the file system. But is that really a good argument? Build directories exist, so even if you'd like to keep compiling several variants in parallel you could do so with a few different build directories.

And yes, there are quite a lot of newer alternatives to Makefiles as well, so it would have to compete with those alternative build systems as well.

I basically never `make clean` but ccache is a boon for `git bisect`. In theory bisect takes log time; in practice, without ccache, it’s slower because handwave build time goes by something like the log of the number of commits you jump across.

It's still log(total commits) of full rebuilds. I don't think git bisect ever promised anything more.

If it’s my branch, I often have a build of every commit in my cache. Even if not, each jump back and forth makes a bunch of new cache entries, many of which will be reused in subsequent bisect steps.

When switching branches, won't the modified times change and invalidate everything (with just make)?

The commenter was referring to having compilation and linking in separate stages, as is standard in Makefiles to enable Multi-Threaded compilation. As in

  cc -c main.c -o main.o
  cc -c init.c -o init.o
  cc init.o main.o -o final_binary

In that specific setup, ccache does indeed not provide a speedup, since those .o file are kept. The Makefile simply checks if the source file has a younger modification date than the object file and recompiles only if it's older. In that sense the Makefile does in fact cache the results. Once we go beyond single-user and onward to bigger projects, ccache starts making sense.

Unless you `make clean` as creators of ccache notice on the linked site

All rules inherently depend on the Makefile they are defined in. The second you touch the Makefile rules, you have potentially invalidated all the object files. So, ccache is great when working on the build rules.

Using ccache is also nice when you have generated files. If you edit the generator code but the output is identical, Make will needlessly rebuild everything and ccache will make it quick.

Reply on news.ycombinator.com