Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming Technology

Managing Projects with GNU Make 49

Posted by michael from the making-trouble dept.
sarumont writes "Every Open Source developer uses or has used GNU make at some point or another. Everyone who has ever compiled a piece of Open Source software has used GNU's make. So what exactly is GNU make and how does it work? The 3rd Edition of 'Managing Projects with GNU Make' tells you all about using GNU make and more."
This discussion has been archived. No new comments can be posted.

Managing Projects with GNU Make More

Managing Projects with GNU Make

Comments Filter:

  • Quite the assumption (Score:4, Informative)

    by dave1g ( 680091 ) on Saturday January 29, 2005 @04:32PM (#11515592) Journal
    I'm pretty sure there are plenty of open source developers who have never touched GNU Make.

    you might try these guys.

    www.virtualdub.org [virtualdub.org]
    www.dscaler.org [dscaler.org]

    And many [sourceforge.net] more. [sourceforge.net]

    Open source on windows, OMG it does exist!!!!

    Step out of your Linux bubble.
    • There's a *lot* of open source in Java, and basically all of them use ant [apache.org].

      I'm sorry, what was this article about?

    • Re:Quite the assumption (Score:4, Insightful)

      by Umbral Blot ( 737704 ) on Saturday January 29, 2005 @05:05PM (#11515823) Homepage
      As a Sourceforge admin (see my sig) I can testify from personal experience that Sourceforge has a heavy Linux bias. I do not think that this necessarily comes from the site, but who the site affiliates with, and the people who are drawn to it. First off is FreshMeat. FreshMeat is a great way to create interest in your project and attract developers, and yet windows only projects cannot use it. There is no good reason for this except an anti-windows bias. And secondly the majority of Sourceforge users are Linux users, which means that Linux projects attract more developers and users, which means in turn that their projects shoot up in popularity and name recognition much faster than a Windows project. And finally those Linux projects, being popular have an easy time finding someone to port to Windows, but a low key windows project has a hard time finding someone to port it to Linux since no one knows about it. Hence a kind of self-perpetuating process has arisen that downs out windows projects.
      • I have no problem with the linux bias on sourceforge (personally have only dabbled in linux, but Im taking a begining linux user course and hope to some day make the switch).

        I just wanted to point out that not all open source development is done on linux.

        The fact that the author thought that all open source developement has something to do with GNU shows he is just another close minded linux fanboy.

        While arguably we can thank GNU for the existence of the free software movement, since then it has branched

      • Re:Quite the assumption (Score:3, Insightful)

        by zerblat ( 785 )
        Well, you do know that Sourceforge was created by VA Linux (now known as VA Software)? And Freshmeat has always been a directory of software for *nix. There are zillions of sites that only list Windows software. There was a need for a site where you could find *nix software, and Freshmeat filled that gap.

        And secondly the majority of Sourceforge users are Linux users

        I'm not so sure about that. Certainly, SF is a site for open source-software, and a lot of OSS is *nix-centric (since, well, the most popular

    • Re:Quite the assumption (Score:5, Insightful)

      by Haeleth ( 414428 ) on Saturday January 29, 2005 @06:15PM (#11516275) Journal
      I'm pretty sure there are plenty of open source developers who have never touched GNU Make.
      Open source on windows, OMG it does exist!!!!
      Step out of your Linux bubble.

      What's [cygwin.com] Linux-centric [sourceforge.net] about [mingw.org] GNU make [freebsd.org]?

      I'm primarily a Windows user, and I used to use GNU make all the time. Until I realised I preferred omake [metaprl.org].

  • SCons is much better than GNU Make (Score:5, Informative)

    by Eric Smith ( 4379 ) * on Saturday January 29, 2005 @05:08PM (#11515848) Homepage Journal
    I used to use GNU Make extensively, and considered myself to be reasonably close to being an expert with it. But a friend introduced me to SCons [scons.org], and I've found it to be much easier to use.

    SCons has automatic dependency checking built in, supporting many kinds of source files, but if it doesn't have what you need it can be easily extended.

    SCons remembers the command line used to compile/build a given file, so it automatically figures out that it should rebuild that file if the command line arguments change. With Make it is very difficult to do that, so "make clean" is used much more often than it should be needed.

    SCons is written in Python, and the SConstruct files it uses analagously to Makefiles are fundamentally Python scripts, but you don't need to know Python to use SCons. However, if you do know Python you can easily extend SCons.

    SCons integrates well with Steven Ellis' 'nc' network compilation tool [brouhaha.com] (though nc works with make also).

    • I'll second this. While scons doesn't solve every damn problem, it's
      much easier to use over make.
      I'm not going to look back.

    • Re:SCons is much better than GNU Make (Score:5, Interesting)

      by slamb ( 119285 ) * on Saturday January 29, 2005 @08:00PM (#11516888) Homepage

      SCons remembers the command line used to compile/build a given file, so it automatically figures out that it should rebuild that file if the command line arguments change. With Make it is very difficult to do that, so "make clean" is used much more often than it should be needed.

      There are a couple other reasons "make clean" is used more often than it should:

      • Generating proper dependencies from source is a pain. SCons does this automatically for all of the built-in builders (notably including C/C++), and it has infrastructure for making your user-supplied builders do the same.
      • Most makefile setups are recursive. They should not be (see Recursive Make Considered Harmful [pcug.org.au] for a good explanation). It's a pain to make non-recursive make, because the tools aren't set up for it. SCons is.

      SCons is written in Python, and the SConstruct files it uses analagously to Makefiles are fundamentally Python scripts

      ...which is wonderful. The thing about make is that you have to be familiar with so many different syntaxes and APIs to do the simplest thing. There's the shell + make + m4 + autoconf's libraries (workarounds for non-portable shell utilities) + automake's libraries. It's a huge pain, because there's not a single place to look things up. You have to find the appropriate shell utility...then check in the autoconf/automake documentation to see if there are portability wrappers. scons is simpler; you can find most stuff with just their manpage, and possibly Python's documentation when you need to do actual programming in the build system. One (very simple) syntax. Two sources of API documentation.

      The autoconf/automake system is nice in that it makes no assumptions about the user's system beyond make - everything is just generated to plain shell scripts and makefiles. But it's such a pain for the developer that it's not worth it. SCons assumes the user has a working Python installation, which makes everything more pleasant. Python provides the same level of functionality with the same interface on every platform.

      • Most makefile setups are recursive. They should not be (see Recursive Make Considered Harmful for a good explanation). It's a pain to make non-recursive make, because the tools aren't set up for it. SCons is.

        This is my biggest (but not only) problem with GNU Make. It does not have support for the theoretically correct way to use it. It's not like the paper is new, or even that the maintainer disagrees with it's findings, but there is no movement at all to add support for the features that would make it easy

        • I'm interested to know what you mean. Why does GNU make not have support for the right way to use it (namely, a single Makefile with correct depedencies)? Which features would you like the maintainers to add?

  • Build tools (Score:3, Insightful)

    by SunFan ( 845761 ) on Saturday January 29, 2005 @05:16PM (#11515893)

    One thing I find quite remarkable is that in a couple of decades, make is still the only mainstream multi-language multi-platform build tool. The alternatives are either not widely used or are language-specific like Ant. With so many people not liking make, it's suprising an alternative tool hasn't really caught on.

    • sh (uselss for scripting, completely broken at anything but trivial command line work) and make (terrible, painful and not very featureful) are probably top of the list for me...I'm amazed these were not replaced long ago. The entire autotools chain should be discarded.

      Would love to see a distro that replaces sh with python/perl...replaced make with scons etc.,....at least this distro could claim a differentiating point beyond the installer. I would use it.

      • I think the main problem is that many people still want their projects to be pretty portable, at least among unix variants. Once you start requiring people to have "super-duper-make" (requiring pyperl version X.Y.Z) installed, they often just give up on your software rather than deal with the hassle of installing whatever your favorite tool is.

        Traditional make is a lowest-common-denominator, however much it sucks. GNU make is slowly becoming widespread enough that it may be a viable alternative.

        The auto
        • You could either use the stick or the carrot...the "carrot" approach would be to get a hugely pivotal piece of code pushing alternatives. As I said in another post, if the kernerl was to use an alternative to make, this alternative would almost certainly see widespread adoption elsewhere.

          The "stick" approach would be to mandate inclusion in the LSB so that all distros carry the tool. The BSDs and other OSs would certainly follow suit.

          I agree its a difficult legacy problem to solve but it is not intractable.

  • GNU Make is certainly a wonderful tool, and as a Solaris admin of 10 years, it is typically a tool that I install on systems where I need to compile/install open source software but, I have compiled quite a bit of of open source software using

    /usr/ccs/bin/make

    Some applications have problems with the make that ships with Solaris, but most work fine. My statement is is reference to the opening paragraph that states:

    "Everyone who has ever compiled a piece of Open Source software has used GNU's make."

  • Everyone? (Score:3, Insightful)

    by Brandybuck ( 704397 ) on Saturday January 29, 2005 @06:13PM (#11516266) Homepage Journal
    Everyone who has ever compiled a piece of Open Source software has used GNU's make.

    It is quite possible to compile a piece of Open Source Software without GNU make. It's not easy, to be sure, since there are so many projects out there that require GNU make (automake doesn't help matters much), but it is possible. There is BSD make, Solaris make, Microsoft's strange nmake, and several others. GNU is but one of many, and it's not even the only free make.

    The problem is that the make standard is so tepid that to get a decent make you need to extend it. So what we end up in reality is a lack of a make standard. I can write a complete C program that will compile with any standard C compiler. I can write a powerful bourne shell script that runs on any Bourne compliant shell. But to write a Makefile that will work under all makes is quite difficult.

  • Newer and better alternatives to make (Score:5, Interesting)

    by Anonymous Coward on Saturday January 29, 2005 @10:01PM (#11517451)
    There are newer and much better alternatives to make.


    1. boost-build v2 [sourceforge.net] is the absolute BEST if you want to build C/C++ projects with multiple compilers & versions & targets--or even on simple projects that require a one-liner to feed into boost-build2 (normally taking 5-20 lines in GNU make).


    Upside for boost-build2? Wraps compiler/linker flags in a generic language for many compilers and versions(gcc, msvc, bcc, etc). Also very easy for simple projects but truly shines on huge and complex projects. Jamfiles can inherit properties , requirements, targets, etc. from parent directories. Very very cool.


    Downside to boost-build? Documentation truly sucks compared to other tools. Docs getting better but new users should prepare to unexpectedly find features they could've used to avoid hours of effort.


    Boost-build v2 uses bjam but there seems to be a plan to add support for Python.


    2. Scons [scons.org] is the next best thing to boost-build v2. The underlying language is Python but you don't have to be a Python expert to use it. And the documentation is much better than boost-build v2. However, it takes many more lines to get things done than boost-build v2 (which isn't all that bad considering boost-build v2 can do things in only 5 lines to replace a 40-line gnu makefile).


    3. rake [rubyforge.org] is a make-alternative written in Ruby. For all you recent Ruby converts, be sure to check it out. I love Ruby but I gotta admit, I don't see anything out there being better than boost-build v2 today.


    GNU make served us well but it is time to move on to better choices that make us more productive. Just like cvs having served us well but svn [slashdot.org] and others being a better choice today.

    • A-A-P (Score:3, Informative)

      by Noksagt ( 69097 )
      A-A-P [a-a-p.org], led by Bram Moolenaar (of vim fame) looks promising too.

    • tmk (Score:1)

      by systems ( 764012 )
      And there is also tmk at http://tmk.sourceforge.net/ [sourceforge.net]
    • All these tools (and also cmake [cmake.org] and A-A-P mentioned in the other reply) are great for developers but not ideal for the end user who almost surely doesn't have them installed on his machine.

      If you want to use something as easy on developer but which would still require no additional on the users machine, have a look at bakefile [sf.net]. This is a very useful tool, especially for open source programs where users often have or are asked to rebuild the program from source and installing additional tools is just an ext
  • GNU Make is so cool I use it to rip DVDs!@#$%^&

    • Re:Ripping DVDs (Score:3, Informative)

      by mvdw ( 613057 )
      I agree with the fact it's cool - I generate static internal web pages using make + sed + cat on cygwin. I'd hate to regenerate all the pages just because one page changed...

      The pages are essentially built up from a header file, a sidebar file, a text file (the only bit that changes regularly), and a footer file. The make file scans the directory for all the *.src files, then generates a page for each *.src file, copies it into the right folder as index.html, making the folder if it's not there already. Ea

  • Some [openbsd.org] would [netbsd.org] disagree [freebsd.org].
  • One of my peeves is people who use make, but don't make use of its basic functionality.

    One place I worked, they used a program that was similar (and equivalent) to make. But, rebuilding after one source file changed would recompile all 100 source files. Other components coded the build files correctly.

    Another place I have worked uses gnu make. They rebuild a minimum of one file from each source directory during every build. This causes quite a bit of visual cruft - and makes it more likely that warnin

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close