Slashdot Mirror
GNU Make 4.0 Released
jones_supa writes "A new major version of the classic GNU Make software has been released. First of all, Make 4.0 has integration support for GNU Guile Scheme. Guile is the extension system of the GNU project that is a Scheme programming language implementation and now in the Make world will be the embedded extension language. 4.0 also features a new 'output-sync' option, 'trace-enables' for tracing of targets, a 'none' flag for the 'debug' argument, and the 'job server' and .ONESHELL features are now supported under Windows. There are also new assignment operators, a new function for writing to files, and other enhancements. It's been reported that Make 4.0 also has more than 80 bug-fixes. More details can be found from their release announcement on the mailing list."
Excuse me Slashdort, I'm gonna be away for a while recompiling all my linixes with the new GNOME Maker!
UNITE with the Campaign for a Free Internet because today, our future begins with tomorrow!
I myself prefer GNU Ryu and GNU Ken, but a lot of people seem to do well with GNU Chun Li.
Didn't they plan to introduce a Lua frontend to GUILE? Does anyone of you know what happened to that?
You've quoted exactly from the original article, with only a blind link to it. You have not credited the original author whatsoever. jones_supa should receive a permament HORRIBLY EVIL karma rating, and all his posts should start with -9999 moderation.
I'd rather eat my own feces than use that (((awful))) fucking crap-language Scheme, or any variant thereof. ((OH) (WHAT) (CRAP) defun)
This looks good.
The --trace option is really nice. For some reason people think it is prettier to have makefiles not print put the compile lines. It is, of course, until it breaks.
Make is one of those widely misunderstood tools. Despite being far simpler than, e.g. C it seems to be understood much worse. It's also sad that it diverged long ago, but it's good to see GNU trying to make it compatible with the divergent BSD and POSIX variants too.
One Make to rule them all! While it seems fashionable not to use the GNU tools these days (for instance distros using less featureful and now slower AWKs than gawk by default), GNU Make is truly the superior one. It is very featureful and an excellent part of a build system.
SJW n. One who posts facts.
Have the developers made a statement concerning backward compatibility with makefiles developed for GNU make 3.80 (or 3.76, etc)?
There is a lot I don't like about Make, including GNU Make. The extensions it has received over the years make it incredibly baroque. I can't work on nontrivial makefiles without keeping a copy of the reference manual open to look things up, and the magic differences between tabs and spaces mean I need syntax highlighting to make sure I know what my makefiles really will do.
So now GUILE integration. How many Slashdot users are big fans of the Scheme language? I appreciate the elegance but I don't want to work in it, and I don't look forward to trying to debug makefiles that make heavy use of it.
I'm not sure what to use to replace Make though. I'm a Python guy so I would probably want Scons or something like that, but Ruby fans probably want Rake, Java fans probably want Ant, and in general I don't think there is any consensus on what might be the best replacement for Make.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Why isn't there a changelog on the gnu make website?
Did they get rid of the required TAB character in front of the rules? Or at least report a non-TAB character?
people still use make? i switched to Ant a long time ago and have never looked back.
No matter what you do to it, Make is an antiquated pig. No offense to the GNU folks, who generally make the best versions of the traditional *nix utilities, and yes, you do need to keep Make around for backwards compatibility, yada, yada, yada.
What's really needed is a ground up re-think of how to create a build utility. A number of folks have tried it. I used to use SCons, and before that it's Perl based predecessor, Cons. The reason I'm not using them now has nothing to do with the software, which I though was excellent. The project lead's idea of alpha is what some people call final release.
I suspect the biggest problem to a widely used Make alternative is the sheer variety of options out there. Nevertheless, what are other people's experiences with build utilities other than Make?
Most abandoned make long ago, in favour of automake/cmake/etc.
At our company we use SCons to build our large projects, which span several platforms (mobile, desktop and consoles), and have plenty of autogenerated code, shaders, etc.
My point of view is that if you are going to need a complex, scripted build system, why not use a friendlier and more accessible programming language such as Python?
Does it build Linux, this time ?
The Linux build system broke when upgrading GNU Make from 3.81 to 3.82, and all stable branches had to add a fix to handle the changes.
Make might not have many friends, but when something doesn't go as expected (eg, compiling an Ubuntu utility on openwrt) it's usually straightforward to dive in and change things. scons and cmake are nice, too; nicer when they work but more painful when things break. And as for the abomination that is autoconf. WTF? 2 hours chugging through ./configure to give an error like "Can't compile -llibbaz" which it turns out means I'm running autoconf 1.2.8 and need autoconf >= 1.2.11 Now, how long before GNU standardises on guile-scripted makefile generated from configure scripts from autoconf autogenerated by cmake from a ./install.sh script???
Some of us actually have directories like that...
then Jordan Hubbard 7hen disaapeared
Why do we still insist on using make when we have much better tools, such as git tup. http://gittup.org/tup/
Tup understands the dependencies between source files, so if you modify a header, only the appropriate source files will be rebuilt, only the libraries/binaries that are dependent on those will be relinked. Whereas make spends most of its time figuring out what to build and what not to.
Hasn't everyone moved to Ninja yet?
SQL is being replaced with NoSQL DBs + imperative code. Want a join? Code up a couple of loops.
How long before makefiles get replaced with something imperative? Is there anything else widely used that's declarative?
Make 4.1 will be able to read mail.
How is the state of that?
Some Qt insider?
By having the object code format be JVM bytecode, CIL, or LLVM bitcode.
There are a lot of build systems that provide more built-in features than straight-up make. Heck, GNU make itself has LOTS more features than POSIX make.
But many of those more-automated build systems run on top of... make. In particular, if you use cmake or automake/autotools, they *generate* makefiles, so you still need a capable "make" program. In fact, you *want* a "make" underneath with lots of capabilities, so the tool you use directly can generate better results.
Ant and Maven are nice tools... but usually they're only used with Java. Rake is great, but is typically only used with Ruby. I like Python (the language), but there are several articles showing that at least at the time Scons was *slow* (and thus had trouble scaling). Autoconf's syntax is still baroque, but if you follow certain conventions it's actually not too bad, and it's much easier to use now that a number of annoying bugs have been fixed.
For general-purpose build systems, the autotools or cmake are still reasonable build systems to look at (unless you're using Java or Ruby). And since they generate makefiles, it's important to have a great tool underneath to process the makefile, even if you don't use make directly.
- David A. Wheeler (see my Secure Programming HOWTO)
Previous poster: "Being simpler for a computer means it is simpler to write evaluators for LISP expressions. Because of the simplicity of LISP an evaluator + applicator gives you a compiler or runtime environment. That is a huge huge advantage."
Yes, but that doesn't require using the old s-expression notation from the 1950s.
Check out http://readable.sourceforge.net./ This adds additional abbreviations to s-expressions, just like 'x currently means (quote x), so that people can produce much more readable code and data. It's implemented in Scheme and Common Lisp, and is released as open source software using the MIT license.
- David A. Wheeler (see my Secure Programming HOWTO)
Make scales just fine. Badly using make, through mistakes like using recursive make, causes scalability problems.
The paper "Recursive make considered harmful" by Peter Miller identifies common mistakes in using make, and how to fix them. The biggest mistake is using recursive make; this is a common mistake that is NOT required by make. Once you stop making this mistake, make is suddenly much faster.
Two other issues with standard make were not part of POSIX, but they are now:
Issue 1: Historically, standard make only implements deferred assignment (where values are calculated when referenced, not when set). This meant that as size grows, there was an exponentially increasing calculation effort (eek). Miller recommends using immediate assignment op, but although GNU make has one (as :=) that wasn't in the POSIX standard. He also suggests using an appending assignment (+=_, which wasn't in POSIX either.
Since then, POSIX has added the immediate-assignment operator ::= and the appendix-assignment += (see http://austingroupbugs.net/view.php?id=330). GNU make 4.0 implements "::=", so you can now start using it. This gets rid of a major scalability problem.
Issue 2: The "obvious" ways to implement automatic dependency generation in make require the ability to "include" multiple from one line, and the ability to silently ignore errors when including, and those weren't in POSIX either. These have since been added to POSIX (in http://austingroupbugs.net/view.php?id=333 and http://austingroupbugs.net/view.php?id=518).
Just getting something into the POSIX spec doesn't cause anything magical to happen. But if a capability is in a standard, it's way more likely to be implemented, and people are far more willing to depend on it.
- David A. Wheeler (see my Secure Programming HOWTO)
See page 184 of the Unix Haters Handbook, http://web.mit.edu/~simsong/www/ugh.pdf. That has to be the most obstinate bug in the world.
Helpful comments in the source code:
if (wtype == w_eol) /* There's no need to be ivory-tower about this: check for
{
if (*p2 != '\0')
one of the most common bugs found in makefiles... */
fatal (fstart, _("missing separator%s"),
(cmd_prefix == '\t' && !strneq (line, " ", 8))
? "" : _(" (did you mean TAB instead of 8 spaces?)"));
continue;
}
So they detect it, and they'd rather insult the user. But "no ivory tower", no no, we will just not parse a space when the ATT code only parsed tabs. It's a "makefile bug", not a "make bug". Sure.
And for the fun, I just tried to build make. On MacOSX, supposedly some kind of Unix that I head a few folks actually use to build stuff. Could be a prime citizen. OK, no configure out of the box with the git repository. OK. No makefile, obviously. No install script. Bogus information in the INSTALL that tells me to run nonexistent configure. Well, running the magic incantation, aclocal ; autoheader; automake ; autoconf. Still does not work, missing files like config/compile. Running automake --add-missing. Whatever. Still an error where it's looking for po/Makefile.in.in. Huh?
So to build make, I need not just make, but four other utilities and makefile input inputs? WTF?
Make alone was bad enough. But it was not good enough for portability, so autoconf was added. But it did not work so automake was added. But it did not work, so... And now at version 4.0, we have a system here you need half a dozen commands just to build the damn thing, and it still does not build out of the box. Seriously?
This whole archaic build system is doomed. Go cmake.
-- Did you try Tao3D? http://tao3d.sourceforge.net