Slashdot Mirror

← Back to Stories (view on slashdot.org)

Announcing 'build', Auto-Configuration In 1000 Lines Of Makefile (github.com)

Posted by EditorDavid on from the making-build dept.

Christophe de Dinechin created the XL programming language -- and as descubes he's also Slashdot reader #35,093. Today he shares his latest project, a simple makefile-based build system that he's split from ELFE/XL: Most open-source projects use tools such as autoconf and automake. For C and C++ projects, build is a make-based alternative that offers auto-configuration, build logs, colorization, testing and install targets, in about 1000 lines of makefile. A sample makefile looks like this:

BUILD=./
SOURCES=hello.cpp
PRODUCTS=hello.exe
CONFIG= <stdio.h> <iostream> clearenv libm
TESTS=product
include $(BUILD)rules.mk


3 of 103 comments (clear)

  1. Wrong tool! Focus on what we need! by Anonymous Coward · · Score: 5, Insightful
    The C and C++ world does not need another build system, it needs dependency management systems! It needs tools like https://conan.io/, tools where you can specify what libraries you need independent of what is installed on the host system. Essentially, we need a system like Maven but for native code.

    Multiple versions locally that don't conflict (so .deb doesn't cut it), control over C++ ABI and build type, transitive dependency closure, the works. Work on that, not another damn build system!

  2. Re:about time by F.Ultra · · Score: 3, Insightful

    Everyone thinks that automake+autoconf+libtool are horrible so they create their new build tool. Then once their new build tool gets close to having similar functionality that automakte+autoconf+libtool has they often tend to be far more ugly and horrible.

    And it does not help that we have braindead things like i.e Java JNI where there is a jni.h file in a well hidden non-standards location with a jni_md.h in a system dependent subfolder (so you might have .../freebsd/jni_md.h or ../win32/jni_md.h and so on).

    Or why there might be __BYTE_ORDER__, __BYTE_ORDER or plain BYTEORDER (or due to the infinite wisdom of Microsoft, no such thing at all). Or the good ol boys from OpenSSL that thought that instead of having a define for the presence of an algorithm there should be a define for if the algorithm is supported by the version of OpenSSL but disabled by the configuration. Or why not the flameretarded OpenBSD that decided to hardcoded the OpenSSL version as 2.0 in LibreSSL when they forked the 1.0 API from OpenSSL when OpenSSL then changed some of their API in v1.1 so now you cannot check if version

  3. Reinventing the wheel? Greeting from NetBSD! by hubertf · · Score: 3, Insightful

    BSD based Unix systems have this for along time.
    Both in the base system, and for 3rd party software.

    Base system example:
    http://cvsweb.netbsd.org/bsdwe...

    Then again, there's not much need for "autoconf"-like system environment detection there. The actual build system is also in a lot of Makefile snippets in the share/mk directory:
    http://cvsweb.netbsd.org/bsdwe...

    For 3rd party software that's build from a make-based system, see http://www.pkgsrc.org/