Make script

An advantage of using make rather than batch scripts is make's dependency checking. This optimizes builds by eliminating steps that need not be performed because derived files are no out of date.

I'd name it build.bat to avoid confusion with batch scripts that invoke make.

Unless you only have one or two source files, make is way better than batch files. It's hard to wrap your head around at first because a make file is _not_ entirely a procedural script -- it's more a description of the structure of your build, with some procedural bits thrown in.

The idea of make is that if you have built your code and you change one source file, make will figure out the _minimum_ amount of work that needs to be done to rebuild your target and do so. For instance, in a normal environment, when you change a .c file you'll need to compile it, then link the result, then (possibly) convert the linker output into a hex file. On the other hand, if you change a .h file, you may need to recompile a dozen or more .c files, then link and convert to hex.

Done right, make can save you a tremendous amount of time waiting for tools to finish building large projects. It can also help with keeping a release process structured, and other cool things.

I'd be interested to know if anyone has a good site on this, or book recommendations -- I absorbed most of my 'make' knowledge by osmosis over the years, so while I know how to use it, I'm not a good candidate for instructing beginners.

I am writing this as the large project is being rebuilt. However the build time can hardly be important for the small projects up to 10k lines or so.

The minor mistake in makefile can result in a file not being rebuilt when it is required. This type of mistake is easy to do when you have different sorts of files and toolchains included into one project.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

There are dozens, googling for "linux make makefile" yields:

etc.

A Very good book is "Managing Projects with GNU Make" by Robert Mecklenburg, published by O'Reilly.

It is available in PDF from their online library as well. Definitely a worthwhile purchase.

Regards Anton Erasmus

Then you have a mistake in your makefile, and it should get fixed. That way the mistake won't happen again. Not really hard.

At first, the build mistake should get noticed. The files of the older revisions could be included without any warnings.

It certainly will. The major weakness of make (as well as many other scripting tools) is there is no simple way to debug and verify their operation.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Mixing different toolchains or different types of tools can make makefiles challenging, but most projects consist of a bunch of C files which are compiled and then all linked together. With a bit of one-time effort, you can write a makefile that calculates the dependencies automatically (gcc will generate dependency files for you) and compile all the C files in a directory as needed. The lazy method is to make all your C compiles depend on the C source file and all headers in the directory - a change to a header will cause more recompiles than strictly necessary, but it's better to err on that side if you are not keen on generating dependency files. Either way, your makefile will last for many projects, and you don't have to track dependencies manually.

It also ensures no change is overlooked.

'info make' on any decent system, or:

How is that different from any other tool? Write, test, debug, rinse, repeat.

And make *does* have some debugging tools (at least, gnu make does - I don't know about others). You can easily print out variables such as current targets, and use dry-run modes to see what is going to happen. It's not a step-by-step debugger, but I expect most programmers can figure it out.

Actually there is a step-by-step debugger for GNU Make (version 3.80):