Slashdot Mirror

← Back to Stories (view on slashdot.org)

GNU Make 4.0 Released

Posted by Soulskill on 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."

19 of 179 comments (clear)

  1. GNU Guile, eh? by rodrigoandrade · · Score: 2, Funny

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

  2. Re:Lua for GUILE? by kthreadd · · Score: 3, Informative

    From http://www.gnu.org/software/guile/:
    "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.

  3. Me gusta! by serviscope_minor · · 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.

    --
    SJW n. One who posts facts.
    1. Re:Me gusta! by Anonymous Coward · · 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.

    2. Re:Me gusta! by dyingtolive · · Score: 4, Funny

      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.

      --
      Support the EFF and Creative Commons. The war is coming, and they're supporting you...
    3. Re:Me gusta! by Darinbob · · Score: 2

      Ant is great if you are building something that works the way Ant expects it to. Make is a bit easier to adapt to products that don't fit simple patterns. Using Ant is a lot like building with an IDE, everything is great if you do things the way that the tool expects everyone to do things, but it becomes cumbersome when you want to do your build a different way. Now Ant may not be that bad if you use a pre-generated starting point (ie, Eclipse dumps a sample build.xml for you), but the result of a simple project there is much more verbose than the equivalent makefile, and essentially don't do anything new or different from Make. How can it hide more details of what is actually being performed (the actual shell commands) while still resulting in a larger and more difficult to read file?

      I evaluated several build methods when trying to replace an existing build system for an existing product, and almost all of them would have required far more work and customization (in Java or Python or something else) than GNU Make required.

      When the Ant documentation starts off by bitching that Make is "evil" (their words) because of the space versus tab thing and then their solution is to use XML style verbage, then the conclusiong is that it is not attempting to be objective.

      Make is very simple to learn. It looks hard mostly because it's so easy to hack it to do your build the wrong way and then someone other than the original author ends up having to maintain it. The hard part is knowing how to create a Makefile that is simple while still being maintainable and flexible. There are so many things it does right that there have been several alternative build systems over the years that create makefile on the backend to do the real work.

      Also use a decent Make as well. GNU Make is much better to use than some older basic implementations (like that absymal parody that comes with Visual Studio). Even better with GCC creating automatic header file dependencies for you, which is often the most difficult part to get working for novices.

    4. Re:Me gusta! by J'raxis · · Score: 3, Insightful

      Because if the last line of those 1000 lines is "make: *** Error 1", suddenly the one right above it is not so pointless.

      --
      Liberty in your lifetime
  4. Backward compatibility? by Anonymous Coward · · Score: 2, Insightful

    Have the developers made a statement concerning backward compatibility with makefiles developed for GNU make 3.80 (or 3.76, etc)?

  5. I'm ready to replace Make by steveha · · Score: 4, 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.

    --
    lf(1): it's like ls(1) but sorts filenames by extension, tersely
    1. Re:I'm ready to replace Make by Samantha+Wright · · Score: 2

      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. Maybe it's time for a classic fork of 3.x?

      --
      Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
    2. Re:I'm ready to replace Make by Anonymous Coward · · Score: 2, Insightful

      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.

    3. Re:I'm ready to replace Make by steveha · · Score: 3, 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.

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
    4. Re:I'm ready to replace Make by Anonymous Coward · · 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.

    5. Re:I'm ready to replace Make by spike_gran · · Score: 2

      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.

    6. Re:I'm ready to replace Make by X0563511 · · Score: 2

      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)

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    7. Re:I'm ready to replace Make by Chewy509 · · 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
      Maven: http://mojo.codehaus.org/maven-native/native-maven-plugin/ and http://blog.bigpixel.ro/2012/07/building-cc-applications-with-maven/

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

    8. Re:I'm ready to replace Make by Darinbob · · Score: 3, Funny

      I have an Italian compiler. Some times it tells me "your code, she is baroque on line 13".

  6. Obligatory SCons plug by goruka · · Score: 2

    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?

  7. Re:Scheme?!? by ebno-10db · · Score: 4, 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.