Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Software Programming

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

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


This discussion has been archived. No new comments can be posted.

Announcing 'build', Auto-Configuration In 1000 Lines Of Makefile

Comments Filter:
  • by Anonymous Coward on Saturday June 17, 2017 @04:08PM (#54639987)
    The C and C++ world does not need another build system, it needs dependency management systems! It needs tools like https://conan.io/ [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!

    • by Anonymous Coward

      We have that, it's called Docker.

    • by Anonymous Coward

      That would be a nice project for Pottering...

    • > it needs dependency management

      I would argue it first needs modules (PDF) [open-std.org] modules (2016 CPPcon) [youtube.com], something that Pascal solved 29 years ago [wikipedia.org]

      > 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? :-)

      >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 co

      • by johannesg ( 664142 ) on Sunday June 18, 2017 @04:50AM (#54641805)

        > 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?

      • Agreed. Except the retarded C++ committee doesn't think this is important

        Ah yes, because "I don't understand the problem == your a retard moran".

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

        OK, genius, write a proposal. Here's why it will fail:

        1. Unixy platforms have settled on the Itanium ABI, which makes exceptions zero cost. They're

        • > The C++ committee isn't "retarded" simply because you don't understand what they do or why. They are experienced and battle hardened.

          BZZZT. Thanks for Playing.

          1. C++ has become such over-engineered bloated crap that even the committee members themselves admit that they only uses a sub-set of it [youtu.be]

          2. This is the same committee that officially recognizes iostreams' performance is shit [youtu.be]. When a committee member admits "... fixing iostreams which I hate in all its forms." you know something is rotten in Denmar

      • something that Pascal solved 29 years ago

        Surely you mean "what Modula-2 solved 38 years ago"?

    • by Anonymous Coward

      What we need is fewer dependencies.

    • by Jherico ( 39763 )
      CMake + Github is about as close as we have in C++ to Maven. Its still pretty ugly though, because C++ doesn't have a consistent build system and the number of options for building and linking is at least two orders of magnitude more than you have to deal with in Java.
      • The compiler options complexity is irrelevant.
        It can be put into a Maven/Ivy directory structure trivially.
        Instead of only putting libs under repository control, you could do that with *.o files, too.
        And when the compiler (more precisely a frontend to it) figures it can fetch the o file from a repository instead of compiling it, it just copies it (like the original "clea case build system" before IBM bought the name and used it for an revision control/issue tracker system)

    • Is there a list of packages available through Conan somewhere? Or am I misunderstanding the whole concept?

    • Use Ivy, it is the same like maven but does not build the software, it only manages the dependencies.
      Or use gradle.

      Software written in Java/Groovy, does not really care about the source code languages nor the artifacts it manages in the repository nor about the build tools it calls :D Java is your friend, and Groovy is your buddy :D

    • by Greyfox ( 87712 )
      You could just link your binaries statically. That's always where I end up when I'm writing native software.

      Back in the day when there were dozens of different unixes that you had to conform to, I would have said that a better build system would have been nice, but I'm currently working with ffmpeg on OSX and Linux and find that good old-fashioned makefiles more than adequate to build my code. It'd be fine for Java, too, if you didn't need to bring in 8000 separate components when building your system.

    • I remember years back when we used to discuss cross platform capabilities. This was around the time that Java was starting to be taken seriously, so last century.

      There were some attempts at using a DOSBox like "container" to provide a common target, I recall IBM trying to go with Linux from mainframe to PC to provide a virtual host. Today we see that really coming forward with the Docker type containers.

      But there was another approach that was talked about that would use C or C++ as the cross platform

  • Like MakeXS (Score:4, Interesting)

    by ozzee ( 612196 ) on Saturday June 17, 2017 @04:13PM (#54640009)
    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.
  • by Anonymous Coward

    Why do we care? What makes it any better than that 50 other make alternatives? Is this a sponsored post?

  • by manu0601 ( 2221348 ) on Saturday June 17, 2017 @08:08PM (#54640669)

    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>

    • by descubes ( 35093 )

      Yes, it's intended to be similarly short. Compared to the BSD makefiles, what's new is the configuration step. Compared to automake, it's that it does not require a (lengthy) makefile generation phase to run first.

      There are also drawbacks, obviously. Autoconf and automake are more feature-complete. But for simple projects, it's probably a good choice.

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

  • CMake is easy too.

  • My bazel BUILD file:

    cc_binary(
    name = "HttpEchoServer",
    srcs = ["src/HttpEchoServer.cpp"]
    +glob(["src/common/**/*.cpp"])
    ,
    includes = [],
    copts = ["-g","-std=c++1z","-I/usr/include/mysql++","-I/usr/include/mysql","-Isrc","-Isrc/common"],
    linkopts = ["-L/usr/local/lib",
    "-lcairo","-lcryptopp","-lpq",
    • by Orphis ( 1356561 )

      When you hardcode paths local to your machine and compiler options specific to your compiler, you can use build tool, it doesn't really matter.

  • by hubertf ( 124995 ) on Sunday June 18, 2017 @04:21AM (#54641763) Homepage Journal

    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... [netbsd.org]

    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... [netbsd.org]

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

  • ... is NOT another build system.

The world is coming to an end ... SAVE YOUR BUFFERS!!!

Working...