Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix Open Source Programming Software Upgrades News

GNU Make 4.0 Released 179

Posted by Soulskill from the onward-and-upward dept.
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."
This discussion has been archived. No new comments can be posted.

GNU Make 4.0 Released More

GNU Make 4.0 Released

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

  • Me gusta! (Score:5, Informative)

    by serviscope_minor ( 664417 ) on Wednesday October 09, 2013 @02:22PM (#45084295) Journal

    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.

    • 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: (Score:2, Insightful)

        by Anonymous Coward

        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.

      • That's what set +x is for.

      • Re: (Score:2)

        by gmack ( 197796 )

        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

        • That kind of thing works fine if you understand the build process already, but if you don't, then having all the stuff print out is very useful.

          • Re: (Score:2)

            by gmack ( 197796 )

            Why? It autodetects source files and subfolders so they never need to touch the build system.

            • That part is fine, I am referring to hiding the details about the build. It's a real pain to download a project, try to get it to compile on a different platform (or even the same platform), and then have all the build commands hidden. Especially when you don't have a coworker nearby who understands what is going on.

      • Often it scrolls by too fast. You want to see how far along you are in a build but if every command has 5 lines long and scrolls by faster than you can read then it's not helpful, except to review a log file afterwords.

        • Yeah, if it goes into a log file I can check afterwards, that's fine with me, as long as the location of the log file is easy to figure out.

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

      • 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 variab

  • Backward compatibility? (Score:2, Insightful)

    by Anonymous Coward

    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)

    by steveha ( 103154 ) on Wednesday October 09, 2013 @02:24PM (#45084313) Homepage

    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.

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

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

        by steveha ( 103154 ) on Wednesday October 09, 2013 @03:03PM (#45084755) Homepage

        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.

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

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

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

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

        • Keep the makefiles simple and use a higher level shell script that ties together the more complicated build system. I think some places make a mistake of trying to have a top level makefile that tries to do everything across multiple groups and projects. Also Make is perfectly happy spawning off a shell script or perl script or even external guile script if asked to do so.

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

      • I wish they'd get rid of all the parentheses to make Lisp more convenient. And get rid of all those angle brackets in XML to make it more convenient.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      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.

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

    • 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 thoug

      • 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: (Score:2)

          by gmueckl ( 950314 )

          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

      • Scons feels to me like a clumsy way of doing Make, just with a Python syntax. Yes when your project gets really complicated you can break out of it and write raw Python code, but that's only helpful if you're a Python expert and understand what happens under the hood of Scons. The Scons wiki even points this out as one of the drawbacks.

        At its core Make is agnostic. It doesn't have any opinions on how you should build your project instead you tell it what to do. Most of the Make replacement systems seem

    • 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

      • 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: (Score:2)

          by JanneM ( 7445 )

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

          • 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: (Score:2)

              by JanneM ( 7445 )

              Installing Python is no big deal.

              ..is no big deal on things that look and act much like an X86 workstation. On big machines you frequently need to cross compile; the compiler/assembler/linker suite is not GCC or closely compatible; the system libraries are intended to be compatible these days but are separate implementations with their own quirks; and the environment is geared toward specific use so you lack many libs that are taken for granted in all-round systems.

              I have installed Python on such a machine

    • 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

    • 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 pro

    • Comment removed based on user account deletion

    • The spaces versus tabs is not that big an issue anymore. But people keep pointing to it as the difficult part. If there is a mistake, GNU Make won't just guess what was intended and go on, however it will give a legible error message about what it thinks was wrong. Just use spaces almost everywhere (everyone should already do this in their source code I hope) and tabs only go in a few clearly defined places. It mostly breaks when poeple have poor editors that insist on hard tabs for indentation.

      Yes, GNU

    • Re: (Score:2)

      by Jonner ( 189691 )

      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.

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

  • Obligatory SCons plug (Score:3)

    by goruka ( 1721094 ) on Wednesday October 09, 2013 @02:54PM (#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?

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

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

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

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

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

    • 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

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

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

  • 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)
    {
    if (*p2 != '\0') /* There's no need to be ivory-tower about this: check for

Slashdot Top Deals

Real Programmers think better when playing Adventure or Rogue.

Close