Slashdot Mirror
Managing Projects with GNU Make
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."
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
www.dscaler.org
And many more.
Open source on windows, OMG it does exist!!!!
Step out of your Linux bubble.
You insensitive clod!
There's a *lot* of open source in Java, and basically all of them use ant.
I'm sorry, what was this article about?
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 (though nc works with make also).
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.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
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."
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.
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.
Don't blame me, I didn't vote for either of them!
1. boost-build v2 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 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 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 and others being a better choice today.
A-A-P, led by Bram Moolenaar (of vim fame) looks promising too.
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.
And there is also tmk at http://tmk.sourceforge.net/
GNU Make is so cool I use it to rip DVDs!@#$%^&
Some would disagree.
Dewey, what part of this looks like authorities should be involved?
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 warning messages won't be noticed.
make is just not that difficult to use correctly. When makefiles work nicely, the development process runs smoother.
Where law ends, tyranny begins -- William Pitt
Since it had been so long since the second edition came out, I was really looking forward to this updating. Although in general it's a fine effort with a lot of good information, I have to say I was extremely disappointed with the chapter discussing portability. In this day and age of multiple platforms and cross-compilation, the author basically just punts and says, "It's really hard, use Cygwin."
That advice might work for software you're developing yourself, but it's of no use if you're trying to ship software that others must build. You can't assume that everyone has Cygwin installed on their systems, and you can't force them to do so without losing a lot of potential users/customers.
It's a real shame, because the world could use a good discussion of how to write really portable Makefiles, and who knows how long it'll be until there's a fourth edition?