GNU Make 4.0 Released 179
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."
GNU Guile, eh? (Score:2, Funny)
Me gusta! (Score:5, Informative)
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.
Re:Me gusta! (Score:2)
For some reason people think it is prettier to have makefiles not print put the compile lines. It is, of course, until it breaks.
That drives me crazy. Why would anyone want not to actually see the commands that are getting run? Make them pretty if you must, but show what you are doing.
Re:Me gusta! (Score:2, Insightful)
That drives me crazy. Why would anyone want not to actually see the commands that are getting run? Make them pretty if you must, but show what you are doing.
Too much build spew means it's harder to spot the compiler warning spew. It's pretty useful to only see the unexpected output.
Re:Me gusta! (Score:2)
That's what set +x is for.
Re:Me gusta! (Score:2)
Re:Me gusta! (Score:2)
Once your project reaches a certain size the actual commands and their arguments end up making a multiline mess for each command and aren't actually that helpful unless it's the build process itself you are debugging. It gets even worse if you generate dependency files which involve piping the output of gcc through some arcane sed commands.
I generally prefer having make tell me what it's doing (Generating depfile.d, building file.c, linking file.o) etc. And then it's very easy to spot what file threw the error. Where I work, we turn on every GCC warning we can find and that alone is several lines per gcc execution (programmers are under orders to not leave warnings). Compiles here happen several times an hour but the build system only gets worked on when I have some free time and feel like I need some pain in my life (once a year at best). The other programmers don't know or care that the build system crawls the source tree, duplicates the tree structure in a build folder, generates dependency and object files in the corresponding subfolders of the build folder etc etc. They only want to see what source or include file they broke.
Re:Me gusta! (Score:2)
Re:Me gusta! (Score:2)
Why? It autodetects source files and subfolders so they never need to touch the build system.
Re:Me gusta! (Score:2)
Comment removed (Score:2)
Re:Me gusta! (Score:2)
Re:Me gusta! (Score:2)
Because I just downloaded the lastest snapshot of X and want to build it. I only care about every specific line if something breaks (to report it). I probably won't understand most of what it's doing anyway.
Re:Me gusta! (Score:2)
Re:Me gusta! (Score:2)
You've never done a parallel build on a large project, have you? The output gets disgustingly obnoxious (the include path being the worst offender). You can't see what the compiler is doing, and that's the point.
Instead, it's better to just print a simple line like "Compiling File1.c" -- that's 90% of what you want to know anyway. If something goes wrong, use the -n option to see the compile line. The --trace option is even better.
A common workaround up to this point was to conditionally define a variable like QUIET=@, and then use that at the start of any actions ($(QUIET) $(CC) ...). Redefining QUIET to empty lets you see the line. I prefer the -n option, but it might not be as portable.
In reality, you only care about the compile options when debugging the build process itself. But in normal usage, get rid of the internals and just let me see the results of the compilation.
Re:Me gusta! (Score:5, Funny)
You say pointless, but I think what you mean is ESSENTIAL.
Re:Me gusta! (Score:2)
Why would anyone want to see 1000 lines output by compiling gcc? It's completely pointless.
Because it's not completely pointless.
Re:Me gusta! (Score:4, Insightful)
Because if the last line of those 1000 lines is "make: *** Error 1", suddenly the one right above it is not so pointless.
Re:Me gusta! (Score:2)
At which point you type 'make --trace' and figure things out. But in the general case, it is completely pointless.
Re:Me gusta! (Score:2)
Make has flags to enable and disable printing of output. If you want to debug your shit, just enable the output printing.
"Just enable" works when the 'make' you execute is the only one. In a maze of scripts and Makefiles and scripts generating Makefiles and scripts generating scripts that call make, euphemistically called "a custom buildsystem", hunting down the right 'make' to change into 'make -d' can take a while.
Comment removed (Score:3)
Backward compatibility? (Score:2, Insightful)
Have the developers made a statement concerning backward compatibility with makefiles developed for GNU make 3.80 (or 3.76, etc)?
I'm ready to replace Make (Score:5, Interesting)
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.
Re:I'm ready to replace Make (Score:2)
and the magic differences between tabs and spaces mean I need syntax highlighting to make sure I know what my makefiles really will do
Just like python!
Actually, GNU Make has got pretty good in this regard and usually does the correct thing if you use the wrong kind of indent.
Re:I'm ready to replace Make (Score:2)
Just like python!
The right thing to do is just ban the use of the @%#^! tab character. You can't do that w/ make, but you can with just about everything else. I once wrote a pre-checkin validation script for a VC system, and it would reject any file (of the appropriate source types) that contained a tab.
Re:I'm ready to replace Make (Score:4, Interesting)
Just like python!
Actually, no.
Python lets you use spaces or tabs, and will do pretty much the right thing. You can sometimes get into trouble if you mix spaces and tabs.
If you have multiple lines and they are indented identically, they are a block. It's easy to indent identically if you use nothing but spaces; still easy if you use nothing but tabs. (If you indent with a mix of tabs and spaces, and use the identical indent on each line, it will still work but this is very non-recommended. If you indent two lines such that they visually line up, but they have spaces and tabs in a non-identical configuration, it won't work right... but Python will raise an exception and warn you.)
Recommended practice in the Python community is just to use spaces for indenting. Everyone's editor agrees on how that would work. Most editors have an option to use spaces automatically even if you hit a tab when indenting a line.
The white space situation in Python is not perfect, but you really cannot say that Python has a syntactic distinction between tabs and spaces like Make does.
Actually, GNU Make has got pretty good in this regard and usually does the correct thing if you use the wrong kind of indent.
This has not been my experience, but perhaps you are right. I have been using vim with syntax highlighting, and every time I use spaces instead of a tab, the highlighting reveals my mistake and I fix it, so I haven't screwed this up in a while.
If the tabs vs spaces thing was the only issue with Make, I could live with it (just as I can live with Python's handling of white space). The baroque syntax bothers me much more.
Re:I'm ready to replace Make (Score:2)
You could always use Haskell. You have a choice between {}; C-style syntax, and Python style whitespace. Ok, that's a bit of a kluge, but in practice everyone uses the whitespace anyway, so it's not a problem.
Re:I'm ready to replace Make (Score:3)
The way notepad++ does it works superbly well. You get visually low-contrast dots or arrows indicating what kind of white-space it is. It's there, and it's visible - but it's not distracting. (you have to turn this on btw)
Comment removed (Score:2)
Re:I'm ready to replace Make (Score:2)
Baroque: "extravagantly ornate, florid, and convoluted in character or style [reference.com]," not unlike the architectural style of the same name. Seems fitting for at least some Makefile instances I have seen.
Comment removed (Score:4, Funny)
Re:I'm ready to replace Make (Score:3)
Re:I'm ready to replace Make (Score:2)
and I am quite fond of the Lisp language family, but it doesn't make sense to me to put it into a build system,
Ignoring the de/merits of LISP, why not? If you want the build system to be programmable, it's better to embed a "proper" language than to keep kludging Make so that it does become a turing tarpit.
Re:I'm ready to replace Make (Score:2)
Re:I'm ready to replace Make (Score:2)
Actually I'm more militantâ"I think embedding a language is still pretty kludgy. I'd opt for writing a new language that replaces the whole Make syntax, rather than $(encrusting everything). (But I'm not really a fan of the syntax of shell scripting, so admittedly I'm a bit biased.)
I see your point, but I'm not convinced I agree or disagree.
There's an annoying tradeoff between such things. Shell syntax is certainly horrible for programming. Partly it's because it's clearly an aggregation of features. Partly it's because of the way data strings are the primary entity, not sane syntactic tokens. That leads naturally to whitespace in data being a pain. Thing is though for a lot of stuff, especially short scripts and one liners where you get to control the environment, it's short, simple and easy. Just not scalable.
It's a better UI than a language.
I *think* the tradeoff is worth it.
Make "suffers" the same thing in that it's designed to throw stuff at the shell. It's a bit more sane in that things mostly aggregate only inside $() rather than with every new possible combination of bracketing characters and worse in the shell.
Again not sure. For many things Make is quite easy. Many of my makefiles are only 4 lines long (augment CXXFLAGS, augment LDFLAGS, target:lost of objects, linker line).
Also, most of what you need to do in building is the same. Fundementally, Make is a language for expressing lines and nodes in a DAG. Assuming you treat building in the same way, a new language would eiher have to have a new DSL for expressing that data and then a whole new language to go along to make it programmable, or be written in something with decent enough support for an EDSL. The choice is:
1. New DSL with turing completeness available.
2. DSL with embedded "proper" language.
3. EDSL inside existing language.
It's not clear to me which is the best by any means.
Comment removed (Score:2)
Re:I'm ready to replace Make (Score:2)
Considering all the extensions to standard make it would be nice if they'd relax the tab requirement so writing makefiles is more convenient.
Comment removed (Score:2)
Re:I'm ready to replace Make (Score:2, Insightful)
Not bloody likely. Gradle kicks Ant's ass by about a bazillion times. Even Maven is better than Ant, even if the XML used to define artifact construction is terribly named and terribly complex.
Re:I'm ready to replace Make (Score:2)
Are those build utilities just for Java, or do they handle other languages?
Re:I'm ready to replace Make (Score:2)
Both Ant and Maven can compile C/C++ code, either through native support or via plugins.
Ant: http://codemesh.com/products/junction/doc/ant_cpp.html [codemesh.com]
Maven: http://mojo.codehaus.org/maven-native/native-maven-plugin/ [codehaus.org] and http://blog.bigpixel.ro/2012/07/building-cc-applications-with-maven/ [bigpixel.ro]
Mind you, we have so many build tools available, why not just pick one that suites you and your target environment? (eg make for C/C++, groovy/ivy/maven for Java, etc).
eg cmake and scons all are popular as well...
Comment removed (Score:2)
Re:I'm ready to replace Make (Score:2)
Maven is great when you are ready to give up many freedoms in how to setup your build structure and do things exactly as intended. Then it works very well. Most of my projects work with a single parent pom defining stuff like metadata, repositories, java version, a project pom for every module with nothing more then dependencies and a single aggregator pom bringing it all together. if you stay simple, Maven is great. If you want to do complicated stuff, stay away from it.
In my personal opinion, that is a great way to do things. Leave the individuality and innovation to the software, let the build system be conservative and dumb. A well written Maven build is short, uses few plugins and is easy to read and understand. It still needs work to set it up, learn about the right way to do things and possibly change old habits.
I you are not prepared to give up individuality in your build system, stay away from Maven, there are better tools for scripting a build.
Re:I'm ready to replace Make (Score:2)
Leave the individuality and innovation to the software, let the build system be conservative and dumb.
Agreed. This is especially true when you have sizeable development team (or teams), and you're doing continuous integration and deployment. Once you accept the "convention over configuration" approach, Maven is a breeze to work with.
Lipstick on a pig (Score:2)
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 [scons.org], 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?
Re:Lipstick on a pig (Score:2)
How do those non-make utilities compare? Why are they better? Is it syntax or do they do something more sophisticated than representing the dependency chain as a DAG? Or better integration with other tools?
Re:Lipstick on a pig (Score:2)
I have tried SCons and cmake as replacements for Makefiles and I'm pretty happy with cmake. Both tools are better than make in that they have more insight in what you're trying to accomplish and end up doing the right thing in many cases. You certainly don't have to spell out every command explicitly like you have to do with Makefiles.
SCons gives you a lot of programmer's freedom by handing you a whole Python interpreter to work with. That can be cool in some situations, the downside for me is that you have to come up with all the code that configures the build by yourself. The big plus with SCons is that it knows what to do with about any kind of file that can be compiled without having to tell it how to invoke the corresponding compiler.
cmake on the other hand brings a lot of tools that let you spell out the configuration of the build in terms of user-set variables in a very straight-forward manner and it also has. It doesn't run the build, but can generate build scripts or project definition for a lot of environments and IDEs. I find it to be very easy to write cmake scripts that compile moderately complex builds with lots of dependencies on multiple platforms, where each user has his/her dependencies layout it in a different fashion from everyone else.
Comment removed (Score:2)
Re:I'm ready to replace Make (Score:2)
Ant? Seriously, you have to be kidding!
The bottom line is that there is no replacement for Make; it still does what it was designed for very well. I use it when ever I have lots of small files with unix commands to convert them; python normally shows up there as well.
But make sucks for Java, hence ant, and then maven. And I use leiningen for Clojure. I'm not sure having one build tool per language is a great situation, but there you have it. But make fills its niche and it will be there in quite a few years time.
Re:I'm ready to replace Make (Score:2)
Try SCons [scons.org]. It blows the doors off of Make, and once you get the hang of it, is much simpler to use. It's also written in Python, and you write the "build files" (equivalent to make files) in Python. Real honest-to-goodness Python, not just some restricted kind-of-like Python stuff.
Re:I'm ready to replace Make (Score:2)
..which is nice until you sit on a system without Python (go to big compute clusters and things like Python are suddenly scarce). Make is completely standalone; and the Autotoools look the way they do because, again, you can run them with minimal external dependencies.
As I heard it told, the reason Make (and Autotools) is the default despite all the suck is because all proposed alternatives suck more once you leave their original use-case.
Re:I'm ready to replace Make (Score:2)
nice until you sit on a system without Python (go to big compute clusters and things like Python are suddenly scarce)
I'll take your word for it about Python being scarce on such systems, but why? Installing Python is no big deal. If you can install autotools, etc., you can install Python.
As I heard it told, the reason Make (and Autotools) is the default despite all the suck is because all proposed alternatives suck more once you leave their original use-case.
You may have heard it told, but I've tried it, and I disagree. What do you mean by "leave their original use-case"?
Re:I'm ready to replace Make (Score:2)
I have installed Python on such a machine. It was a big deal and nothing I would ever attempt just to get a make-like utility working. It would be far less work to replace that utility with Make than to get Python onto the machine.
Sorry; I get a bit abridged at times. What I meant is that Make alternatives normally are born from a specific need. A group wants to build Java programs (for example) and come up with a tool that works better than Make for that.
But then it almost invariably (so far) turns out that the tool that works great for the original use case is lacking features, or lack flexibility, or has dependencies that make it unsuitable for very different kind of projects. Make-replacements that really are general enough to fully replace it are no easier to learn and use than Make itself. It seems for all its cruft and oddities, Make does seem to represent a floor in the complexity needed to support all the different situations you may encounter.
I have tried a number of alternatives over the years because I was frustrated with Autotools (which, rather than Make itself, is what people often really complain about). Finally, for one project I bit the bullet, got myself a book and really learned Autotools properly. And found out it's not bad at all, just unintuitive until you get a good explanation. There is some cruft there of course; but many oddities are due to the portable nature of the tools, and others are simply conventions that modern languages don't follow - they're not wrong, just different.
If you really want to replace make I suspect the best replacement would be - Make. That is, define an optional "new Make" mode that is not backwards compatible, with cleaned up syntax and parsing rules; the surface stuff that people get annoyed by.
Re:I'm ready to replace Make (Score:2)
If you write a lot of Python in an SCons build file, then you're doing something wrong. The capabilities, including things like checking for header file dependencies, are all built in. It even knows something about commonly used tools, like gcc, so you can start out by saying "use the usual gcc stuff".
Just because your declarations and whatnot are written in Python, doesn't really mean you have to actually write a Python program - that's already been done for you. Sure you can abuse it, but what powerful tool can't be?
Re:I'm ready to replace Make (Score:2)
Using a static data structure, as make does, to describe dependencies rather than executable code such as Python, as SCons does, is hugely important in reducing the complexity and increasing the understanding of large build graphs
This is a common misunderstanding about SCons. Just because the user-written construction files are Python files, does not mean that the user writes code to determine dependencies. SCons dependency specifications are just as static as they are in Make - typically just lists of the source. SCons figures out all the dependencies from there.
Re:I'm ready to replace Make (Score:2)
So, how does it figure out that main.cs depends on util.dll?
Depends('main.cs', 'util.dll')
Magically figuring out dependencies by looking for #include lines is a case of being good for one specific job, while failing to keep up with good old make as soon as you venture outside that one specific job.
Nope. SCons is a very general and extensible tool, that has many pre-written facilities for common cases, like finding header file dependencies in C/C++. You need something different? No problem. It also has facilities for creating your own Builders. And no, even for those, you don't write the Python from scratch. Don't feel like writing a Builder (though it's not that hard), and want a quick hack for one oddball case? No problem, you can do that too, including specifying the dependencies (see above).
Re:I'm ready to replace Make (Score:3)
In the mailing lists, the maintainer of Make implied that the Guile integration was put there essentially as a hedge. People would ask for extensions to Make that he didn't want to commit to, so now the Guile is there so that people can extend make their own way.
I would imaging that the Guile stuff would be valuable to do complicated pattern substitutions than Make can easily handle. It is trivial in GNU Make to convert a variable containing a list of *.c files to a list of *.o files, etc. But something more complicated of that nature is where a Guile extension would come in.
re: I'm ready to replace Make (Score:2)
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
I went back and forth on different Pythonic build tools for awhile. Scons is pretty great if you're doing 'standard' sorts of builds, but I found it a little heavy for my tastes and really hard to customize to my tool flow (in FPGA land, there are all kinds of nonstandard vendor tools that all need to play together).
I've been using doit more and more over the past few months, and I'm continually impressed by the tool (aside from the goofy name). It works amazingly well for automating tricky/exotic build processes.
Check it out! http://pydoit.org/index.html/ [pydoit.org]
Re: I'm ready to replace Make (Score:2)
That link gives a 404.
Comment removed (Score:2)
Comment removed (Score:2)
Re:I'm ready to replace Make (Score:2)
There are millions of replacements for make, which is part of the problem. I doubt there will ever be one canonical replacement, but Scons is a good choice for many projects IMHO. I'm trying to replace the use of make where I work with Scons, which especially makes sense we use Python for the application code. I think a Scheme-extensible replacement for make could be a very good thing, but adding more languages to the ugliness of Make is not the way to go.
Replacing make with... make (Score:2)
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.
Re:I'm ready to replace Make (Score:5, Informative)
> Protip: If you need another tool to build a project other than the compiler, then you're doing it wrong.
Protip: If the only tool your project needs to build is the compiler, it's a trivial project.
Generating any non-trivial product (package, installer, resources, doc, etc.) takes a pile of tools.
Comment removed (Score:2)
Java, .NET, or LLVM (Score:2)
Re:I'm ready to replace Make (Score:2)
The answer is languages that aren't retarding. Seriously. The only reason make is required is because you let implementation details leak into the damn language.
Personally I need this. When doing builds off a single source tree for multiple targets then the "implementation details" such as the target name, target bit-width or whatever else is needed can be passed into the code using Make. Other "implementation details" are useful - embedding the git hash into the code makes it easier to determine which version of software sent the crash report. Signing a binary using a hash of the source is another "implementation detail".
Just because you're too stupid to do things like the git hash in your software doesn't mean that everyone wants to be stupid too; there's a reason why other build systems come and go while Make is still around year after year.
Obligatory SCons plug (Score:3)
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?
Re:Obligatory SCons plug (Score:2)
That's why a lot of projects don't use Make directly. You typically use a combination of programs like autoconf, automake and libtool to generate the makefiles for you. In the end you get a shell script that you can send to users and they don't need to have the tools you used installed.
Re:Obligatory SCons plug (Score:2)
That's the way some people have to do it, but it's a kluge. SCons is much cleaner and easier to use. Also cross-platform.
Re:Obligatory SCons plug (Score:2)
Autotools are obsolete technology.
If you want something similar, but truly multi-platform and modern, try CMake.
Re:Obligatory SCons plug (Score:2)
It can't be that large if you're using scons.
SCons is known for being inefficient and scaling badly. It is however fairly powerful at scripting your build rules.
Re:Obligatory SCons plug (Score:2)
Much of the scaling issue comes from SCons' default use of hashes to determine if a file has changed. That means in a large build, it has to read and generate a hash for every file. No big deal if you're re-building the whole thing, but a big slowdown if you've changed only one or two files. You can easily switch to timestamps though, ala make. It's not as robust, but it's good for modify-compile-test on big projects. For the real "gotta make sure everything is right", you can go back to hashes.
Re: Obligatory SCons plug (Score:2)
you realize make doesn't scale well either, right?
Re: Obligatory SCons plug (Score:2)
So what does scale well?
Re: Obligatory SCons plug (Score:2)
ninja, tup, tundra...
Make scales just fine (see: Peter Miller) (Score:2)
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 [sourceforge.net] 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 [austingroupbugs.net]). 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 [austingroupbugs.net] and http://austingroupbugs.net/view.php?id=518 [austingroupbugs.net]).
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.
Re:Obligatory SCons plug (Score:2)
I'm a big Python fan, but not so fond of SCons. I think this is mostly a documentation issue: there is a manual which explains things superficially and contains some examples, but what I really want is to have the underlying concepts explained thoroughly. When working on a build system, there are usually multiple ways you could implement something, but they are not equivalent in terms of reliability (robustness against transient failure or user error) and flexibility for future changes in requirements (new platforms with their own weirdness etc). With SCons I could get things to work, but I never really had the feeling I knew why this was the right way to do it.
(I'm sorry if this is a bit vague, but it's been several years and I don't remember all the details anymore.)
There isn't really a build system that I do like; most of the time I settle on plain GNU Make (for simple projects) or GNU Make with included Makefiles generated by Python scripts (for complex projects).
Re:Obligatory SCons plug (Score:2)
First, Makefiles are essentially a declarative language. Second, even though the utility is written in Python, and your "make files" are also in Python, SCons largely uses a declarative approach. You tell it what you have to build, and how to build it, then let it figure out the order and so forth.
But... (Score:2)
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.
Ninja (Score:2)
Hasn't everyone moved to Ninja yet?
First they took away SQL... (Score:2)
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?
Zawinski's Law, next stop. (Score:2)
Make 4.1 will be able to read mail.
And tab vs. space bug still not fixed. (Score:2)
See page 184 of the Unix Haters Handbook, http://web.mit.edu/~simsong/www/ugh.pdf [mit.edu]. 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.
Re:Lua for GUILE? (Score:4, Informative)
From http://www.gnu.org/software/guile/ [gnu.org]:
"In addition to Scheme, Guile includes compiler front-ends for ECMAScript and Emacs Lisp (support for Lua is underway),..."
So unless that page is inaccurate I guess that means it's still underway.
Re:Lua for GUILE? (Score:2)
From http://www.gnu.org/software/guile/ [gnu.org]:
"In addition to Scheme, Guile includes compiler front-ends for ECMAScript and Emacs Lisp (support for Lua is underway),..."
So unless that page is inaccurate I guess that means it's still underway.
Where in the announcement of Make 4.0 is there any mention of Lua?
Re:Lua for GUILE? (Score:2)
I still say it has nothing to do with Make. I guess I shouldn't have replied to a post responding to an AC.
Re:Scheme?!? (Score:2)
I see a lot of words but not a lot of arguments. State your position on _why_ you should not use it as an extension language.
Re:Scheme?!? (Score:2)
His arguments were clear to me. Too many bloody brackets!
Re:Scheme?!? (Score:2)
He's saying that he's too stupid to understand functional languages, therefore functional languages are bad.
It's more like the average Joe-sixpack developer doesn't want to have to spend weeks learning the subtle distinctions between "let", "let*" and "letrec" just so they can add some scripting to their makefiles.
Re:Scheme?!? (Score:2)
Comment removed (Score:2)
Re:Scheme?!? (Score:5, Insightful)
Human need contrast, but all lisp-likes provides is data structure like XML. (Haha, this comparison must make LISPers mad.)
I hope you realize that you've just started a war that will make the Wars of the Reformation seem tame. Get out of Bohemia while you can! I'm staying neutral.
Re:Scheme?!? (Score:2)
In this Lisper's experience, that more than makes up for the unique syntax
Thank you! It drives me nuts when Lispers defend the human readability of the "unique" syntax by saying things like "it's simpler" (true for a computer, a human not so much) and "you don't have to worry about operator precedence" (you can get the same effect in C by putting everything in parentheses, which makes it look like Lisp).
By contrast, you admit that it's a tradeoff. I don't have enough Lisp experience to say whether it's a worthwhile tradeoff, but it's a very solid argument.
Re:Scheme?!? (Score:2)
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.
You really can only do LISP in LISP. The real tradeoff is between layers of DSLs vs. layers of libraries as a way of designing large systems. Libraries obviously won some of the fights for example on operating systems or large application. While on places like networking, or hardware DSLs won.
Lisp s-expression notation can be readable (Score:2)
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./ [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.
Re:Lisp s-expression notation can be readable (Score:2)
For lurkers the link you wanted was: http://sourceforge.net/projects/readable/ [sourceforge.net]
The idea you are proposing is the idea behind Dylan: http://en.wikipedia.org/wiki/Dylan_(programming_language) [wikipedia.org]. It certainly is a reasonable idea for the base language. But when you construct a DSL you want your DSL code to be easy to construct and destruct data in the lower language. That is you don't want to have write complex parsers. Because once you start writing complex, you want to isolate them i.e. make them methods, make the protocols for putting data into and out of the DSL data structures isolated as well.... and soon you are looking at object oriented code. You've changed the whole paradigm.
What is truly unique about LISP is how easy it is to create a LISP and those s-expressions which are pre-parsed is a large part of that.
Re:Scheme?!? (Score:2)
Having tried to deal with Scala's macros I have joined the camp of "it's a seriously worthwhile tradeoff".
Honestly doing anything with reflection in Scala (or pretty much every non-Lisp) is just horrifyingly unintuitive (and as a result: painful). In a Lisp you're just manipulating lists using typical list manipulation functions, it is, comparatively, a piece of cake.
Re:Too little, too late (Score:2)
Both these tools use make as a backend, and some of the new features (--trace and --output-sync, for instance) will be useful even for users of automake and cmake.
Re:Why not tup? (Score:2)
Because tup is experimental software.
It's similar to ninja, except ninja is production quality and actually even more efficient.