Slashdot Mirror
Announcing 'build', Auto-Configuration In 1000 Lines Of Makefile (github.com)
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
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!
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.
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
Why do we care? What makes it any better than that 50 other make alternatives? Is this a sponsored post?
Doesn't look like SCons made the transition to Python 3 yet.
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.
This. CMake is damn close to perfect if you want portable builds.
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...
Python 3 is a slow bloated mess [...]
That's funny. Instagram made the transition from Python 2 to Python 3, and got an unexpected performance boost from CPU and memory savings.
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
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.
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.
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
CMake is easy too.
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 when you are using:
bash
make
gcc/g++/ld/ar
autoconf/automake/libtool
m4
awk
sed
basename
chmod/chown
strip
grep
find
cpp
gdb
yacc/bison
lex/flex
tar/gzip/zip
man
cmake
lua
tcl
perl
python
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",
"-lPocoCrypto","-lPocoFoundation","-lPocoJSON","-lPocoNet","-lPocoNetSSL","-lPocoUtil",
"-lboost_date_time","-lboost_unit_test_framework","-lboost_random","-lboost_system","-lgtest",
"-lproxygenhttpserver","-lfolly","-lglog","-lgflags","-lpthread"],
)
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.
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/
... is NOT another build system.
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.
What exactly is it that people find so horrible with automake+autoconf? The Makefile they produce is completely horrible to look at but the configure.ac, Makefile.am and .in files are actually (IMHO) quite straight forward and they have very good docs at i.e https://www.gnu.org/savannah-c...
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/
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
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.
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.
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 created and lacked the zip/rsync functionality that I needed.
I'm on python-dev, I'd be interested to see what you've actually posted.
I post as Chris R. to avoid confusion with Chris A.
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.
-- Did you try Tao3D? http://tao3d.sourceforge.net
You mean progress instead of scrolling? Interesting idea.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Must be lots of tests :), I've noticed that autoconf is slow as a turtle on Windows but I have always thought that to be due to the MinGW filename mangling.