tags:

views:

490

answers:

9

Is makefile an advanced problem or a general problem for a programmer? For a C++ programmer, how often will he be asked to write a makefile file?

+1  A: 

I have never thought of makefiles as problems, they are quite usefull...

The frequency would depend on the platform that you're using and your role.

For example, in some organizations there is a fairly fixed build file that doesn't often change, while in others there are frequent changes. Some organizations rely on the IDE to deal with the build, etc. You don't have to be the build engineer.

I think that most C/C++ developers should have at least some fundamental understanding of how makefiles work, though they don't have to be gurus. In my alma mater, that is part of first-year CS.

Uri
+16  A: 

Setting up a meaningful build system is part of the craft. I'd expect any non-super-junior developer to be able to come up with a makefile.

Nikolai N Fetissov
And saves you time later on. There's always some process of go back and tweak with any development process but having some form of understood structure really helps and that quite often resolves around the build system which is itself a natural extension of the project structure (speaking in abstract).
Ninefingers
I agree -- its very useful to know how to build a makefile.
Kevin Friedheim
I wouldn't want to build a makefile. That would require a makefile for the makefile? What exactly is a "super-junior" developer?
Matt Joiner
Hmm, in my book "super-junior" is a kid right out of college who is absolutely sure he knows it all based on 10-line code assignments in school.
Nikolai N Fetissov
+2  A: 

Programmers need to know how to build their projects. Typically (in my experience) the 'production build' is based on the original programmer's makefile. Many programmers go their entire careers just fumbling blindly when putting together their makefiles, but every programmer has to do it.

John Dibling
+4  A: 

As often as he is asked to start on a brand new project, which is not similar to an existing project whose builds scripts can be adapted. That is not a good answer I guess, but in my experience there has always been some code/resources/build scripts that I can adapt.

On a different note, for any C++ programmer, it is important to learn how his code is built. Makefiles, Ant scripts etc are just the implementation mechanism. So I think it is important enough to learn.

omermuhammed
+20  A: 

Nobody ever writes a Makefile. They take an existing Makefile and modify it.

Just be thankful you don't have to deal with IMakefile. (For those of you who were lucky enough to never deal with this, or who have managed to forget, IMakefile was a file that was sort of a meta-Makefile for X Window System based projects which would be used to generate a Makefile that knew where you'd installed all your X Windows libraries and binaries. Needless to say, it sucked.)

Paul Tomblin
So so true. I haven't written a makefile 100% from scratch since my second year in college. Copy, paste modify
JaredPar
+1, so true. Most build systems have been done before and all boil down to compile x into object y anyway.
Ninefingers
I write a makefile from scratch more often than I write an HTML file from scratch. Last time I did it was Monday, I think.
Steve Jessop
+1, very true, though they still need to understand what to copy/paste/modify :)
Nikolai N Fetissov
Modifying something you don't understand is dangerous. I was on a training gig many years ago where peoples start-up time for a UNIX console was of the order of five to ten minutes. Turned out they had all added things over the years to a standard script but never removed things from it, because they didn't understand what the older things did.
anon
And I would also observe that most build systems HAVE been done before - very, very badly, in almost all cases.
anon
Damn you for reminding me of `imake`! Makes me appreciate how much better `autoconf` is all over again, and I really don't like that blecherous pile of `m4` hackery...
Donal Fellows
I personally have a snippet of SnippetsEmu (a vim plugin) that I stole from somewhere and then changed to my taste. I expand the snippet for any new project or C/C++ sandbox I start, and then change it as I see fit.
wilhelmtell
Actually, edit an existing one rather than copying and pasting, or else you could lose the tabs.
JohnMcG
@JohnMcG: is that a joke, or do you actually have the worst text editor in the world? ;-)
Steve Jessop
Probably more like I did once, got burned, and never changed.I think if you just to a X-windows middle-button paste, the tabs turn to spaces.
JohnMcG
@JohnMcG, it's my belief that old xterm and rxvt weren't very good about preserving tabs, but the newer terminals are much, much better about this.
Paul Tomblin
I keep a template and it's easy to update it, plus it's a good reference for the most often used macros and setup - but it's not difficult to create one from scratch - it just shows that `you understand how the code is built`.
stefanB
@Steve Jessop:You mean Emacs? ;-)
slacker
A: 

It depends on the tools/libraries/frameworks you are using for your project. For my job I code using Qt so I never have to write a Makefile as qmake does it for me although I do have to know how to create a qmake project file instead.

I freely admit I probably couldn't write anything beyond the simplest Makefile without having to learn it all from scratch. I don't see that changing anytime soon as I would only learn it if I was forced to. Why learn something you may never need?

Troubadour
+1  A: 

One thing to note is that, if the build system is set up in a modular way one practice isn't to build one huge makefile for the whole thing but makefiles for bits that can be called from the master makefile recursively. This is a great feature as it means different products (libraries?) can be built as separate units, often in parallel.

Makefiles are designed to automate the build process. Therefore, they are most definitely not a chore; they save you writing gcc -c *.c etc all the time. Not only that, but a properly written makefile has phonies for clean, rebuild etc. On most of my projects, make rebuild does exactly that - cleans everything and starts again.

Makefiles are really useful. I can't say that enough.

Ninefingers
Not everyone considers recursive make to be a good thing - see http://miller.emu.id.au/pmiller/books/rmch/
anon
Interesting, thanks for the link. As always, depends on the project much as these things always do. I did say *one* practice... I'm not evangelising it, just highlighting it as an option.
Ninefingers
I guess we talk about `recursively` as in each module has its Makefile and from top you build each module before you link them into one executable. This assumes that your project is properly setup and it's modularized.
stefanB
@Stefan Read the link anon provides. Even properly set up, recursive make is inefficient.
dmckee
@dmckee:Not to mention often simply doesn't work. Include "submakefiles" of modern make implementations can very well replace recursive make, but the different usage style can take time to get used to.
slacker
+1  A: 

Even if you are using an IDE that deals with the details of building the project for you, makefiles can still be very useful. Occasionally you need to have some extra functionality as part of your build process, for instance to run a pre-processing step to generate a c++ file programmatically (if you use Qt then you may need to run moc on your header files or rcc on your resource files. You might need to process an .idl file to generate an implementation file), or as a post-build step to copy files to a destination. In these cases you typically have two choices:

  • run the scripts as pre- or post-build steps every time, which means the app will be rebuilt every time you build it
  • create a makefile to perform the action which will embody the dependency rule so that the step will only be invoked if the timestamp of the input file is newer than that of the output file. Building a project that is already up to date will do nothing

A C++ developer may go for many years without needing to create a Makefile if they're not working on Linux/Unix, but a decent developer will seek to understand how Makefiles work as they will probably improve part of your current workflow.

the_mandrill
"Building a project that is already up to date will do nothing" - Not exactly. It will typically mean that the makefile(s) spend five to ten minutes screwing around before concluding that there is nothing to do. Especially with a hairy old system that uses recur(recur(recur(recursion)sion)sion)sion.
Daniel Earwicker
Ok, slight exaggeration when I say 'nothing'... What happens will depend on the complexity of your project. If the project is doing horrendous amounts of Makefile faffage then you probably need to consider a separate build step. If you're just dealing with some simple makefiles to copy files around and do build pre-processing then this overhead is quite tolerable (especially compared to having stale builds where it doesn't get rebuilt when files change).
the_mandrill
@Daniel Earwicker:That is another reason why [recursive make is considered harmful](http://miller.emu.id.au/pmiller/books/rmch). Use *make* properly, not the way everyone uses it!
slacker
+1  A: 

I suppose it depends...

Personally, I am quite mesmerized by the syntax of Makefiles. Doing any kind of even a simple operation on the paths of the object is ever so tricky.

On the other hand, being able to build is just necessary, and understanding the various arguments on the compile line is too. Though perhaps not for a junior.

I had to rewrite the build system of our application barely a year after I left school. I did it using scons and it worked great. Build time went from 1h30 to barely 10m because I was finally able to have parallel compilation and put an automatic local replication of the libraries used in place.

The morale is: if you ask someone to pick up a build mechanism, do not force Makefile on him. Let him pick a more recent tool.

Matthieu M.
+1 - Although due to their widespread they are unavoidable, that's no reason to help perpetuate them any further. If there is an alternative in your programming environment, even if it's terrible it's probably going to be better than what you'll come up with if you start with `make`. Which is the whole point: `make` itself is not a build system; it lacks basic obvious things that a large project's build system needs, which have to be supplied by other tools and reams of make rules, and the resulting assemblage tends to run like an asthmatic dog.
Daniel Earwicker