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
Wrong tool! Focus on what we need! (Score:5, Insightful)
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!
Re: Wrong tool! Focus on what we need! (Score:1)
We have that, it's called Docker.
Re:Wrong tool! Focus on what we need! (Score:5, Funny)
The code is closer to the original artistic vision when it's left in the original black and white.
Re: (Score:1)
The code is closer to the original artistic vision when it's left in the original black and GREEN.
The code is closer to the original autistic vision when it's left in the original black and GREEN
FTFY
Re: (Score:2)
Re: Wrong tool! Focus on what we need! (Score:1)
That would be a nice project for Pottering...
Re: (Score:2)
> 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
Re:Wrong tool! Focus on what we need! (Score:4, 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?
Re: (Score:2)
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
Re: (Score:2)
you're
The joke, you, whoosh etc.
Re: (Score:2)
> 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
Re: (Score:2)
something that Pascal solved 29 years ago
Surely you mean "what Modula-2 solved 38 years ago"?
Re: (Score:1)
What we need is fewer dependencies.
Re: (Score:2)
Re: (Score:2)
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)
Re: (Score:2)
Re: (Score:2)
Is there a list of packages available through Conan somewhere? Or am I misunderstanding the whole concept?
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Re:about time (Score:4, 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
Re: (Score:2)
Not really. The only saving grace of autotools is that they're fully written on m4, which is either already installed on every *nix system out there or readily available.
I'm very partial to CMake which does everything autotools does (and more, like creating VS/XCode projects) in a much saner way, but it requires an additional binary to be installed.
Re: (Score:3)
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 hav
Re: (Score:2)
It's hard to come up with something more horribly designed than automake and autoconf. Most other alternatives are better. The only problem is that there are too many of those alternatives, and there isn't a single one that became a de facto replacement standard because of that.
Re: (Score:2)
Re: (Score:2)
One thing is that they take forever to run. On a project I currently work on, Spice, autoconf and automake take over 70s, the build takes about 20s. So we are at the point where auto-configuration takes longer than actual compilation.
Re: (Score:2)
Re: (Score:2, Troll)
It's a fucking scripting language - the only "build" it requires is running the goddamned python interpreter.
The ant build script for my static websites generates the static files using Pelican, archives the output directory to a backup folder on the file server, and then transfer the output files to the web hosting server. I just type "ant all" from the command line for everything to get done automatically. Each static website has a build.properties file that has specific settings for the build script to use.
Like MakeXS (Score:4, Interesting)
Re: (Score:2)
For what it is worth, which is nothing. Coding has never landed me a job no matter what I do.
The tech industry can suck the rancid shit out of my old bitter asshole. Fuck you all to hell, you fucking motherfuckers.
You should try writing decent code, and maybe working on your people skills.
It is nice of you to warn potential employers off though.
Re: (Score:2)
Re: (Score:1)
Python 2.7 still works fine in the meantime.
If you still have Python 2.7 installed. I've been using only Python 3 for the last few years.
Re: (Score:2)
Python 3 is a slow bloated mess [...]
That's funny. Instagram made the transition from Python 2 to Python 3 [slashdot.org], and got an unexpected performance boost from CPU and memory savings.
Re: (Score:2)
Creimer, you've got an awful lot of opinions about Python for someone who apparently doesn't know how to run python projects inside a virtualenv.
Sorry, grandpa, your bias against Java and Python 3 is showing again.
https://slashdot.org/comments.pl?sid=10381487&cid=54110393 [slashdot.org]
Re: (Score:2)
Using a piece of python 2.7 code is trivially easy - install 2.7, set up a virtualenv for the tool you need to use, and you're done.
Are you planning to use virtualenv for when Python 2.7 comes to an end in 2020?
https://pythonclock.org/ [pythonclock.org]
If you're crazy enough to reinvent the wheel poorly, you deserve the pain you're incurring.
That's funny. Instagram made a smooth transition from Python 2 to Python 3.
https://slashdot.org/submission/7142015/instagram-makes-a-smooth-move-to-python-3 [slashdot.org]
Re: (Score:2)
Work with the upstream project to help them build python3 support, and in the meantime, make use of python 2.
Except that I don't have Python 2 installed because I'm using Python 3 exclusively. That seems to be an issue on Slashdot. I don't get any crap on the Python dev list for using Python 3 exclusively.
Re: (Score:2)
Time to reinvent every piece of python2 code that hasn't yet been ported to python3: days, weeks, months.
Which piece of Python 2 code am I reinventing?
I've never seen your name there that I can recall, and a quick look at the archives doesn't seem to show any activity from anyone with your name, either.
That's because I don't post under creimer.
Re: (Score:2)
How about the fabric functionality that's native to pelican?
I didn't consider fabric because it required Python 2.7. I've since learned that there is a Python 3 version, which isn't linked from the fabric web page, has two or three GitHub branches and screams not ready for a production environment.
You're using ant (poorly, I'm sure) to replicate functionality that's native to the pelican project itself.
I've previously used Ant for PHP projects. It took me 45 minutes to create a single build.xml file and build.properties files for a dozen static websites. As for the fabric file that Pelican installs, it has three times as many lines as the Ant build.xml file that I've cre
Re: (Score:2)
You mean progress instead of scrolling? Interesting idea.
A weekend project? (Score:1)
Why do we care? What makes it any better than that 50 other make alternatives? Is this a sponsored post?
Re: (Score:3)
This. CMake is damn close to perfect if you want portable builds.
Re: (Score:1)
It's sad that 30 years on, none of the existing config/build systems seem to offer even basic debugging capabilities.
Which is why on the Jsi project (jsish.org), the configure is handled by, well Jsi itself.
That is, a minimal interpreter is built with just enough language features to perform the configuration.
No external programs are used. If there is a problem, we can use the Jsi debugger to single step through it.
Try doing that with m4 (used by autotools), cmake, et al.
In fact, debugging is not possile wh
BSD Makefiles or automake (Score:3)
It looks like BSD Makefiles (sample below)... or just like automake's Makefile.am
WARNS=6
PROG= sed
SRCS= compile.c main.c misc.c process.c
Re: (Score:2)
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.
Wow (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.
CMake (Score:2)
CMake is easy too.
My bazel BUILD file (Score:1)
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",
Re: (Score:2)
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.
Reinventing the wheel? Greeting from NetBSD! (Score:4, 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... [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]
Because what this world needs... (Score:2)