Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

GNU Make 4.0 Released

Soulskill posted 1 year,21 days | from the onward-and-upward dept.

GNU is Not Unix 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."

Sorry! There are no comments related to the filter you selected.

Awesorme! (1, Offtopic)

For a Free Internet (1594621) | 1 year,21 days | (#45084201)

Excuse me Slashdort, I'm gonna be away for a while recompiling all my linixes with the new GNOME Maker!

GNU Guile, eh? (2, Funny)

rodrigoandrade (713371) | 1 year,21 days | (#45084207)

I myself prefer GNU Ryu and GNU Ken, but a lot of people seem to do well with GNU Chun Li.

Re:GNU Guile, eh? (0)

Anonymous Coward | 1 year,21 days | (#45084351)

GNU Chun Li? I'm afraid that would look like this [deviantart.net] .

Lua for GUILE? (1)

Anonymous Coward | 1 year,21 days | (#45084227)

Didn't they plan to introduce a Lua frontend to GUILE? Does anyone of you know what happened to that?

Re:Lua for GUILE? (3, Informative)

kthreadd (1558445) | 1 year,21 days | (#45084261)

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? (0)

Anonymous Coward | 1 year,21 days | (#45084839)

Thanks.
Unfortunately, web sites are often not up-to-date.
The last repo entry is from a month ago, so I hoped one of the developers could confirm it's well-being/death/hiatus state...

Plagiarism (0)

Anonymous Coward | 1 year,21 days | (#45084269)

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.

Re:Plagiarism (-1)

Anonymous Coward | 1 year,21 days | (#45084345)

Why jones? Jones just submitted a story to the queue; it was Soulskill's job to edit it, because he's the editor and that's his job.

I say that they should shitcan Soulskill instead. Also timothy, samzenpus, UL, and Rob, while they're at it.

Scheme?!? (0)

elloz (3382559) | 1 year,21 days | (#45084291)

I'd rather eat my own feces than use that (((awful))) fucking crap-language Scheme, or any variant thereof. ((OH) (WHAT) (CRAP) defun)

Re:Scheme?!? (1)

kthreadd (1558445) | 1 year,21 days | (#45084381)

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?!? (0)

Anonymous Coward | 1 year,21 days | (#45084461)

He's saying that he's too stupid to understand functional languages, therefore functional languages are bad.

Re:Scheme?!? (1)

Waffle Iron (339739) | 1 year,21 days | (#45084551)

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?!? (0)

Anonymous Coward | 1 year,21 days | (#45085459)

That makes me raise the question, why do average Joe-sixpack developers need scripting in their makefiles to begin with? Shouldn't they be using something that does everything for them already?

Re:Scheme?!? (0)

Anonymous Coward | 1 year,21 days | (#45086951)

As soon as one needs anything more complicated than "compile these files", it's time to use a better build system or write one.

I've seen complex pure-make based build systems.. it's terrifying stuff.

Re:Scheme?!? (1)

Anonymous Coward | 1 year,21 days | (#45084949)

Strictly spoken, it's not functional.
Also, its language is only good for the lazy parser writers.
Human need contrast, but all lisp-likes provides is data structure like XML. (Haha, this comparison must make LISPers mad.)
It wouldn't even make sense to cheat this away with clever syntax highlighting, because it would be a logical flaw and pretty pointless, because then one could implement/use a good syntax anyway.
Also, add on paradigms can't be used by the same logic, so no CLOS or similar crap is allowed.

The best about lisp-likes is that some runtime implementations are really good.

Re:Scheme?!? (4, Insightful)

ebno-10db (1459097) | 1 year,21 days | (#45085885)

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?!? (0)

Anonymous Coward | 1 year,21 days | (#45086095)

I just did it for the trullz.

Re:Scheme?!? (1)

Anonymous Coward | 1 year,21 days | (#45086897)

but all lisp-likes provides is data structure like XML. (Haha, this comparison must make LISPers mad :)

XML is just an ugly syntax for S-Expressions :)

More seriously, the reason for Lisp's syntax is that it makes it easy to write Lisp code that manipulates Lisp code (since Lisp code is really just a list). In this Lisper's experience, that more than makes up for the unique syntax

Re:Scheme?!? (1)

interval1066 (668936) | 1 year,21 days | (#45085463)

I don't think so. Scheme has enough issues to where I'd rather use lisp if I feel the need to go the functional route (object-oriented model is horribly mis-defined if not out and out plain broken, whomever implements that language needs to understand how valuable "standard" structures like arrays and hash tables are, and I know some love the multiple return types but I think they're a huge pain in the ass.)

Re:Scheme?!? (1)

Darinbob (1142669) | 1 year,21 days | (#45087177)

Lisp is great as a language for Emacs. It has also been well used in some other contexts for customization. I dont doubt that Scheme would work too in some instances. However often the pure functional nature of Scheme would seem to collide with the quick-and-dirty nature of scripting languages, but could be worked around (a lot of Scheme implementations relent and add some more traditional Lisp features instead of staying minimalist).

However Scheme being good at something doesn't say too much about Guile. Guile last I looked seems larger than I would expect a Scheme to be.

Re:Scheme?!? (1)

cheater512 (783349) | 1 year,21 days | (#45086389)

His arguments were clear to me. Too many bloody brackets!

Re:Scheme?!? (0)

Anonymous Coward | 1 year,21 days | (#45086935)

Don't worry, guile is basically a pink stain where a horse used to be that the GNU guys insist on beating. It's been around for literally 2 decades and in that time has largely been ignored.

Me gusta! (5, Informative)

serviscope_minor (664417) | 1 year,21 days | (#45084295)

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! (1)

phantomfive (622387) | 1 year,21 days | (#45084327)

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! (0)

Anonymous Coward | 1 year,21 days | (#45084459)

Why would anyone want to see 1000 lines output by compiling gcc?
It's completely pointless.
Do you have your kernel print a trace of every function it calls?
Make has flags to enable and disable printing of output. If you want to debug your shit, just enable the output printing.
Also, the reason everyone hates gnu make is because the documentation is horrible.
The documentation actually gives examples that are wrong and inefficient.
It doesn't help that autotools default are also completely brain dead and inefficient.

Sure if you plow through all the docs you can find all the information, but it should just not be this hard.

Re:Me gusta! (4, Funny)

dyingtolive (1393037) | 1 year,21 days | (#45084955)

Any time I want to slack off or if I need some more time to work on something useful rather than the pointless tasks delegated in the name of excess micromanagement, I just kick off a kernel build on three or four different boxes and tell my boss I'm testing a client issue.

You say pointless, but I think what you mean is ESSENTIAL.

Re:Me gusta! (1)

phantomfive (622387) | 1 year,21 days | (#45086403)

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! (0)

Anonymous Coward | 1 year,21 days | (#45086575)

That's why everyone has moved on to CMake or SCons.

Re:Me gusta! (0)

Anonymous Coward | 1 year,21 days | (#45084733)

I usually have my makefiles just summarize what they're doing rather than dump the commandline, as I only really need to see the commandline if I've been messing with build settings, etc. But I set up a make variable, so when I _do_ need to see the actual commandlines, I can use 'make VERBOSE=1' instead of just 'make'.

I'm interested to see what new features are added by make 4.0, as I've yet to find anything I couldn't do with make 3.8 - especially when using features like $(eval $(call my_dynamic_target_syntax)). Having access to Scheme syntax could be beneficial, but I've always thought that advanced usage of make starts to approximate some kind of Lisp anyway, so...

Re:Me gusta! (2, Insightful)

Anonymous Coward | 1 year,21 days | (#45084743)

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! (0)

Anonymous Coward | 1 year,21 days | (#45084969)

Exactly this.
When ther's 10K lines of complier input to sort through, missing a new warning is far more likely then spotting it.

Re:Me gusta! (0)

Anonymous Coward | 1 year,21 days | (#45084773)

not to actually see

The motivation for me is to quickly identify where a build breaks. That is more difficult when output is obscured by tool commands wrapping around the terminal 12 times per line. I rarely care about the content of the commands; I'm interested in picking out compiler/linker/whatever diagnostics from among all the noise.

Crafting recipes is something that shouldn't be happening frequently; once you've figured out how to build something you are supposed to have moved on to actually building it, not dwelling on the tools and their invocation. If you need to read, re-read and re-read again the same commands used to build you're doing something wrong. If you're not doing it wrong then the rare times when you need to see all the gory detail can be accommodated with non-default switches, such as --trace.

Re:Me gusta! (1)

X0563511 (793323) | 1 year,21 days | (#45086161)

That's what set +x is for.

Re:Me gusta! (1)

gmack (197796) | 1 year,21 days | (#45086611)

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! (1)

Anonymous Coward | 1 year,21 days | (#45084499)

... For some reason people think it is prettier to have makefiles not print put the compile lines. It is, of course, until it breaks.

...

"Think" has nothing to do with that. People who do that are certainly not thinking.

Re:Me gusta! (0)

Anonymous Coward | 1 year,21 days | (#45084535)

people still use make? i moved to Ant a long time ago and have never looked back.

Re:Me gusta! (0)

Anonymous Coward | 1 year,21 days | (#45084791)

Call me when Ant can understand that an inner class has changed and recompile dependencies of it. As I type this, I'm beating Ant about the head trying to get it to understand when it needs to recompile which class files. By contrast, none of my projects with make have ever had this issue.

Re:Me gusta! (0)

HomelessInLaJolla (1026842) | 1 year,21 days | (#45084897)

GNU make [linuxfromscratch.org] is great!

War in La Jolla, seventh year, seventy-third entry (http://slashdot.org/journal.pl?op=display&uid=1026842)

The new national standard stupidity test. How many new random tourist single day stay dogs, daily, would "they" need to bring to you for you to figure out what their power trip is and what they do for their money? Ten dogs, daily? Background noise. Twenty dogs daily? There's an excuse here, for the money, that more people with dogs are moving in. New dogs, single day stay? Don't pay much attention. Good excuse (laugh at this and then walk down that ramp). Thirty dogs? More people moving in. New dogs? Don't care. For weeks now? Too busy. Forty dogs? Would you be able to figure it out at forty new dogs daily? Don't pay much attention. Move the dogs that they surprise you at significant frames in time; at cash register transactions, when you cross through a doorway, in particular when you leave the lavatory or just as you begin eating. Would that help you pay more attention? How stupid are you? Fifty dogs, up to months? Would you be able to figure out what they do for their money, what their power trip is, that their game is to play the passive aggressive pranks on unsuspecting workers (and each other)? Sixty dogs? What's your IQ?

If they were all wearing K-mart t-shirts, would you be able to figure it out? What if they all wore arm bands? Do you need a new witness for every dog or do you need seven different signatures in red ink for every dog every day? When are you required by law to be smarter than the telephone? When are you required by law to be more intelligent than the fork you dropped while eating? When are you absolutely required by law to be more intelligent than the video game controller? When, watching football, are you required by law to be smarter than the remote control? When do you figure out what their power trip is and what they do for their money?

Once you figure out what they do for their money, what are they doing with all those children? Those are all the super hammer chldren, the disposable heroes [youtube.com] . They eat the ham that the contracted "they" are not required. Travel agencies worldwide are offering vacation pacakages including a complimentary one-to-three day stay in La Jolla, if you qualify with dog and super hammer child. Then they bring the hammer children, with dog, to see the homeless man.

Jesus. You're supposed to go for a long walk. Moses and Elijah told you so. It's a food chain. The difference between wood alcohol and grain alcohol. Farm sh*t reduces to methanol. They know exactly how super that super hammer child must be to go blind. Jesus, when you go for your forty day walk, they ramp the kid up to be a superstar futures investor, and then you walk back into town and the Sadduccees claim some space-time continuum thing makes you responsible for the blindness. Not just one. They probably have a few dozen super farm sh*t eating disposable heroes lined up for somebody like Jesus. There are entire scary movie subdivisions completely stocked, like SimCity, to hide rings of super hammer children. Then, when appropriate, the hammer children are brought into contact with an eligible target. When the super hammer child goes blind then all hell breaks loose on the target's life and the background gossip is that they deserve it. They control the horizontal and the vertical, they control all contact you have and everything you see and what else goes on around you all day long, but when that super hammer farm sh*t eating proxy child ("WE LET YOU WATCH AND NOW YOU MUST EAT IT! IT'S YOUR PART! WE LET YOU WATCH!" barking of machine gun fire, does nothing to me now) goes blind, then YOU'RE TO BLAME, YOU'RE AT FAULT, IT WAS YOU, YOU DESERVE WHATEVER WOE YOU'RE GETTING, WE HOPE IT HAPPENS TO YOU, WAAH WAAH WAAH.

Sure. Show me another farm shit eating pedophilia doll with a dog. We're up to a hundred daily, for ten months and running. Would you be able to figure out that they f*ck dogs for their money and make the child eat the sh*t to cover for them? Their idea of a normal family appears to be man, woman, dog, and child to eat the sh*t for them.

Seven years in this area and all I am able to say about these people, over the course of time appearing to be "the millionaires", is that they get to fiddle their dogs and faddle their children about a hundred times every day. I really don't know anything else about them.

Some space-time continuum thing. Like the excuse for the animals all having big black dark receded eyes. Like little boys bedwetting after visits to grandma's house.

Had Jesus gone for a longer walk then, when the super hammer child went blind, he'd be not-so-happily stumbling his way to Cairo and, by the time he got back, the disposable hero would have recovered, gone to the drowning pool, or been checked into a storied career in the pornography industry. I have always posited that porn people were all dead; three or four months away from dead when they began shooting porn for money. Of course. That's a handout for all the super hammer children that have gone blind; until they meet the drowning pool or some other convenient route to hell.

http://mapfortu.wikidot.com/ [wikidot.com]

Backward compatibility? (2, Insightful)

Anonymous Coward | 1 year,21 days | (#45084303)

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 (4, Interesting)

steveha (103154) | 1 year,21 days | (#45084313)

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 (1)

serviscope_minor (664417) | 1 year,21 days | (#45084429)

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 (1)

ebno-10db (1459097) | 1 year,21 days | (#45084657)

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 (3, Interesting)

steveha (103154) | 1 year,21 days | (#45084755)

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 (0)

Anonymous Coward | 1 year,21 days | (#45085245)

Let me start off with I really like python (my best hey try this out language).

However the spaces thing is a real PITA. You must be consistent with it. Which means if you add a new member to the project you need to say exactly what you are doing. The differences between 3 spaces and 4 spaces in many fonts is rather minimal. Line breaks for readability are a pain as they better be on the same indentation level as the next line or the previous line (or woe unto you when the compiler acts oddly).

Would it have killed them to put in begin/end qualifiers?

I can not tell you the number of bugs I have 'fixed' in my python code because I had an indentation level wrong. This feature of python makes bugs.

Re:I'm ready to replace Make (1)

ebno-10db (1459097) | 1 year,21 days | (#45085645)

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 (2)

X0563511 (793323) | 1 year,21 days | (#45086207)

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)

Re:I'm ready to replace Make (0)

Anonymous Coward | 1 year,21 days | (#45085725)

What do you think the word baroque means?

Re:I'm ready to replace Make (0)

Anonymous Coward | 1 year,21 days | (#45084999)

Not like python. Because, in reality, everyone who actually knows how to program uses spaces, because you can't show tabs in HTML. And everyone who knows how to program knows how to configure his IDE/Editor.

Re:I'm ready to replace Make (2)

Samantha Wright (1324923) | 1 year,21 days | (#45084445)

Well put. I haven't had the displeasure of working with huge makefiles personally, 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, and the tab magic thing is slightly Turing tarpit worthy [dur.ac.uk] . Maybe it's time for a classic fork of 3.x?

Re:I'm ready to replace Make (1)

serviscope_minor (664417) | 1 year,21 days | (#45086035)

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 (1)

Samantha Wright (1324923) | 1 year,21 days | (#45086231)

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

Re:I'm ready to replace Make (1)

wiredlogic (135348) | 1 year,21 days | (#45084473)

Considering all the extensions to standard make it would be nice if they'd relax the tab requirement so writing makefiles is more convenient.

Re:I'm ready to replace Make (2, Insightful)

Anonymous Coward | 1 year,21 days | (#45084491)

Java fans probably want Ant

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 (1)

ebno-10db (1459097) | 1 year,21 days | (#45084913)

Are those build utilities just for Java, or do they handle other languages?

Re:I'm ready to replace Make (2)

Chewy509 (1178715) | 1 year,21 days | (#45086431)

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

Re:I'm ready to replace Make (0)

Anonymous Coward | 1 year,21 days | (#45085761)

With Maven, you managed to mention the one tool that sucks even compared to .BAT files, let alone Make or Ant. Congratulations!

Re:I'm ready to replace Make (0)

Anonymous Coward | 1 year,21 days | (#45084531)

I use nakefiles [github.com] because they are written in a really cool programming language much better than python or ruby [nimrod-code.org] and compiled to binary code, which makes them instant. But I reckon if you want something more stable/supported you should give tup a try [gittup.org] .

If somebody uses today make that's really like living in the past ignoring all the much better new options.

Re:I'm ready to replace Make (-1)

VortexCortex (1117377) | 1 year,21 days | (#45084549)

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.

Protip: If you need another tool to build a project other than the compiler, then you're doing it wrong. Additionally, if your intermediate "object code" isn't cross platform and your debug symbols can't be removed without recompiling, then you've also done it very wrong.

I'm ready to replace make too. I'm ready to replace the whole damn OS stack, in fact. They've all done things the stupid way. Programs can't even negotiate a simple data exchange without a programmer in the middle being the damn translator and providing a shell script. Don't get me wrong, I like the 70's, but come the fuck on people, this shit is dumb.

It's not the user's fault this shit is so complex; It doesn't have to be this way, that's just the way it was designed.

Re:I'm ready to replace Make (5, Informative)

Anonymous Coward | 1 year,21 days | (#45084875)

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

Lipstick on a pig (1)

ebno-10db (1459097) | 1 year,21 days | (#45084619)

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 (1)

serviscope_minor (664417) | 1 year,21 days | (#45086107)

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 (1)

gmueckl (950314) | 1 year,21 days | (#45086823)

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.

Re:Lipstick on a pig (0)

Anonymous Coward | 1 year,21 days | (#45086263)

Nevertheless, what are other people's experiences with build utilities other than Make?

They are all slower than make, and less portable.

Re:I'm ready to replace Make (1)

Phillip2 (203612) | 1 year,21 days | (#45084799)

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 (1)

ebno-10db (1459097) | 1 year,21 days | (#45085163)

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 (0)

Anonymous Coward | 1 year,21 days | (#45085267)

That's the problem with Scons - because the "build file" is a Python script, it's easy to abuse and soon you find all sorts of code in your build system.

I hate nothing more than trying to figure out how a program works before I can build the program I need to work on...

Re:I'm ready to replace Make (1)

ebno-10db (1459097) | 1 year,21 days | (#45085369)

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 (0)

Anonymous Coward | 1 year,21 days | (#45085677)

Try SCons [scons.org]. It blows the doors off of Make

No it does not. If you think it does you don't understand dependencies. 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 and reducing bugs. e.g. just for starters executable code has both the halting problem and order dependencies that just don't need to exist for dependency management. Executable code should be restricted solely to the build itself.

Re:I'm ready to replace Make (1)

ebno-10db (1459097) | 1 year,21 days | (#45087117)

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 (1)

JanneM (7445) | 1 year,21 days | (#45086375)

..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 (1)

ebno-10db (1459097) | 1 year,21 days | (#45087153)

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 (2)

spike_gran (219938) | 1 year,21 days | (#45085017)

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 (1)

SkOink (212592) | 1 year,21 days | (#45085519)

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 (0)

Anonymous Coward | 1 year,21 days | (#45085829)

I'm a fan of Scheme. But I'm no fan of Guile, I've had no end of stability issues with it over several years.

Re:I'm ready to replace Make (1)

greggman (102198) | 1 year,21 days | (#45086697)

Mostly because I used to work on Chrome but I like gyp [google.com] . It will generate projects for XCode and Visual Studio so developers on those platforms can use the tools they're comfortable with. It will also generate projects for Ninja [github.io] which is much faster than Make.

Re:I'm ready to replace Make (0)

Anonymous Coward | 1 year,21 days | (#45086887)

Gradle.

It's finalizing its support for asm/C/C++

Changelog? (1)

Anonymous Coward | 1 year,21 days | (#45084319)

Why isn't there a changelog on the gnu make website?

Tab (0)

Anonymous Coward | 1 year,21 days | (#45084389)

Did they get rid of the required TAB character in front of the rules? Or at least report a non-TAB character?

make!?? (0)

Anonymous Coward | 1 year,21 days | (#45084511)

people still use make? i switched to Ant a long time ago and have never looked back.

Too little, too late (0)

Anonymous Coward | 1 year,21 days | (#45084621)

Most abandoned make long ago, in favour of automake/cmake/etc.

Re:Too little, too late (1)

doti (966971) | 1 year,21 days | (#45084871)

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.

Obligatory SCons plug (2)

goruka (1721094) | 1 year,21 days | (#45084627)

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?

Re:Obligatory SCons plug (1)

kthreadd (1558445) | 1 year,21 days | (#45084895)

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 (1)

ebno-10db (1459097) | 1 year,21 days | (#45085207)

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 (1)

loufoque (1400831) | 1 year,21 days | (#45086097)

Autotools are obsolete technology.
If you want something similar, but truly multi-platform and modern, try CMake.

Re:Obligatory SCons plug (1)

Anonymous Coward | 1 year,21 days | (#45085137)

Because the idea of using a sequential language for building is shit.
Building is no complex task, so even with all special stuff and such it should be possible to cover this with a declarative or at partial declarative language.
Unfortunately, cmake repeated the mistake and it shows.

Re:Obligatory SCons plug (1)

ebno-10db (1459097) | 1 year,21 days | (#45085277)

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.

Re:Obligatory SCons plug (0)

Anonymous Coward | 1 year,21 days | (#45085923)

Agree.

Make was designed to manage source code within a single directory. SCons nimbly takes care of complex directory structures.

That said, there are many ways to use SCons, and I think it is a mistake to build on Python and scripting too much. I recommend sticking to basic, explicit idioms so that developers who don't know Python can understand and maintain the SConscript files. For example, if you encounter this expression:

env.StaticLibrary('foo', [ 'a.c', 'b.c', 'c.c' ])

you have a very good chance at correctly adding d.c to the library even if you had no prior exposure to Python.

Re:Obligatory SCons plug (1)

loufoque (1400831) | 1 year,21 days | (#45086079)

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 (1)

MtHuurne (602934) | 1 year,21 days | (#45086253)

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 (0)

Anonymous Coward | 1 year,21 days | (#45086499)

I used SCons for about two years, after using autotools, after using straigt up makefile. Then I moved on to my own project and research: http://bca.stoverenterprises.com

But... (1)

romiz (757548) | 1 year,21 days | (#45084651)

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.

I like make. (0)

Anonymous Coward | 1 year,21 days | (#45084801)

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

Can it handle spaces in directory names yet? (0)

Anonymous Coward | 1 year,21 days | (#45084919)

Some of us actually have directories like that...

(0pluS one Informative) (-1)

Anonymous Coward | 1 year,21 days | (#45085553)

Why not tup? (0)

Anonymous Coward | 1 year,21 days | (#45085899)

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.

Re:Why not tup? (1)

loufoque (1400831) | 1 year,21 days | (#45086137)

Because tup is experimental software.
It's similar to ninja, except ninja is production quality and actually even more efficient.

Ninja (1)

loufoque (1400831) | 1 year,21 days | (#45086063)

Hasn't everyone moved to Ninja yet?

First they took away SQL... (1)

Coppit (2441) | 1 year,21 days | (#45087121)

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?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?