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


11 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!

    1. Re:Wrong tool! Focus on what we need! by Chris+Mattern · · Score: 4, Funny

      but... but... colorization

      The code is closer to the original artistic vision when it's left in the original black and white.

    2. Re:Wrong tool! Focus on what we need! by johannesg · · Score: 3, Interesting

      > Multiple versions locally that don't conflict

      That would be a god send if it was standardized across platforms: Win, Linux, OSX. Gee, how did *nix solve this problem? :-)

      Not? Compile something on one version of Linux, and pray it works on another. Sending a binary to a customer is just about plain impossible, it will never work on their system.

      I'm sure you guys all love the open source thing, and so do I. But my customers aren't that technical; they don't want to hear about compiler instructions, they want to get a binary they can use without worrying about anything... Copying it to the right location on the machine is about the toughest I can ask of them.

      >control over C++ ABI

      Agreed. Except the retarded C++ committee doesn't think this is important. Every C++ compiler can call C code generated by ANY compiler but you MUST only call a .lib compiled with the SAME compiler. It is utterly stupid that in 2017 there is STILL no support for an Application Binary Interface.

      Amen. As well as the stupid insistence that undefined behaviour is just fine and dandy (I understand it can only be avoided at great cost in some situations, but in others it can be trivially removed from the standard. Forget about that though...), as well as thinking that apparently 'switch' could only ever be used for things that could theoretically be implemented through jump tables... It's 2017, why can't I switch on strings or constexpr classes, at least?

  2. Like MakeXS by ozzee · · Score: 3, Interesting

    I have a similar make based build system called MakeXS. It's used in the Austria C++ project. It has similar features but my plan was to migrate away from make. Now that Google has released bazel I'm thinking of migrating to it instead.

  3. 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

  4. Re:cmake by Lisandro · · Score: 2

    This. CMake is damn close to perfect if you want portable builds.

  5. Re:about time by F.Ultra · · Score: 2

    CMake to me is way more horrible than automake, i.e tried to add a --pkgconfig-dir option to a CMake build for hours until I found out that CMake caches the initial value and always uses the cached value regardless of what you supply to the "cmake ." step. And trying to make cmake work in say an initial mingw32 install is always fun.

    Of course it's because I'm way more familiar with automake so it's syntax comes naturally to me. Don't really know why my post was modded as troll though. Must be people who have never tried to make a portable JNI or endian build...

  6. BSD Makefiles or automake by manu0601 · · Score: 2

    It looks like BSD Makefiles (sample below)... or just like automake's Makefile.am

    .include <bsd.own.mk>
    WARNS=6

    PROG= sed
    SRCS= compile.c main.c misc.c process.c

    .include <bsd.prog.mk>

  7. Wow by Crackerjack · · Score: 2

    I'm slashdot user #15,884 and my make-based autoconfiguration system is at least 3x as long. I could really learn from this guy.

  8. CMake by sshock · · Score: 2

    CMake is easy too.

  9. 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/