> * detects if, say, libpng is available

You just compile with -lpng. If libpng is available, it will work, otherwise it will fail with a clear error message. What else do you need?

> * links the executable to the library and the library to libpng

    LDLIBS = -lpng
 
    BIN = foo bar baz
    OBJ = lib1.o lib2.o lib3.o
    LIB = libmine.a

    default : $(BIN) $(LIB)
    $(BIN)  : $(OBJ)
    $(LIB)  : $(LIB)($(OBJ))
    clean   :        ; $(RM) $(BIN) $(LIB) $(OBJ)
    check   : $(BIN) ; ./foo -test

This will compile the code from lib*.c into libmine.a, and then compile the source code of a few test executables from foo.c, bar.c and baz.c

The .a is useless often, but there you have it just in case. Otherwise, just remove all references to $(LIB) and get a shorter makefile.

> you can't seriously say that this (which covers an immense part of software project needs) is easier to do in make, right ?

This is rather subjective. In my case the makefile seems easier. It will work for all unices, but probably not for windows, and will not create an "app" package, your are right about that.

But the makefile covers indeed all my personal needs, and it is much more powerful and easier to use than the cmake/make combo. For example, you can test multiple compilers and compiler options with a shell loop:

    # test all compilers in debug and release modes
    for i in gcc clang tcc icc; do
    for m in "-O3 -DNDEBUG" "-g"; do
	    make clean check CC=$i CFLAGS=$m
    done
    done

doing that in cmake would be a nightmare, wouldn't it?

> You just compile with -lpng. If libpng is available, it will work, otherwise it will fail with a clear error message. What else do you need?

well, no you don't "just compile", because one of the most used compilers out there does not support "-l". Also because you may have multiple libpng versions on your machine - debug, with special testing flags, in your ~/work/libpng_build, etc.

Also, you may have libpng.so but not the headers. You may be compiling on Nix or GoboLinux or whatever system which does not respect the FHS. It won't work as is on OS X because you have to add -L/usr/local/lib. Users won't know what to do when they see whatever missing include error the compiler spits out.

> doing that in cmake would be a nightmare, wouldn't it?

.. it would be mostly the same than your example ? just tested and this works fine (normal practice with cmake is to build outside of src which helps):

    for i in gcc clang; do        
        for m in "-DCMAKE_BUILD_TYPE=Debug" "-DCMAKE_BUILD_TYPE=Release"; do #not using -g because that's something compiler-specific
            rm -rf ** ; CC=$i cmake ../ $m ; cmake --build . 
        done
    done

Spare your fingers ;) - you'll never convince anybody of the value of cmake by telling them about it. You just have to put them in a situation where they're looking after a program that has to build on multiple desktop platforms, and they'll figure it out eventually...

(The combination I've always had to deal with is Linux, OS X and Windows/VC++ - but any combination that includes both Windows/VC++ and a POSIX-type OS is probably enough to make it worthwhile. The POSIX/non-POSIX differences are rather annoying to deal with otherwise, and that quite apart from how most Windows programmers will quite reasonably want to use a Visual Studio project rather than a Makefile.)

506c

Yeah, CMake and autotools solve different problems than make. I'm definitely not a fan of either one but if I need to really distribute and compile something on more than one OS there isn't much of a choice.

The posted makefile example fails right away on multiple platforms since headers are often in somewhere else than in /usr/include directly, for example in Debian the right (atm) path would be /usr/include/libpng16 and Makefile does not handle that.

> The posted makefile example fails right away on multiple platforms since headers are often in somewhere else

And that's the intended behavior. Finding system headers around your disk is not a problem that a build system must try to solve. This is the task of a distribution or a packaging system, which is a different problem as you say.

Yeah I agree, it's not the ideal situation but it is the real world. Simple makefiles do not work often and there are systems that can solve the problem. Not elegant, brilliantly designed tools but ones that work anyway.

Thanks for your answer, I see that cmake is not as cumbersome as I thought.

> Also, you may have libpng.so but not the headers.

Then how on earth are you supposed to compile it? You write the definitions verbatim on your code?

> It won't work as is on OS X because you have to add -L/usr/local/lib.

For that case it is better to not mess with compiler options and set up the compiling environment so that -lpng works, e.g. by setting LIBRARY_PATH=/usr/local/lib, and similarly for C_INCLUDE_PATH. These variables are recognized by all unix linkers and compilers that I care about.

Of course, this attitude may not be appropriate for everyone. Yet, I am in the happy position to be able to say say "this program requires gcc, clang, tcc or icc to be compiled, otherwise, please edit the makefile to suit your needs". Are there really other C compilers around? (notice that visual studio is not a C compiler, and cannot compile modern C code, so it does not enter into the discussion if you are a C programmer).

Yes, quite a few, mainframes, embedded OSes, bare metal deployments for SoC, surviving commercial UNIXes.

> Then how on earth are you supposed to compile it? You write the definitions verbatim on your code?

what I mean is that an user might download your source archive, run `make`, and have hard-to-understand failures because of this.