Makefile vs Batch file
- Thread starter corsair
- Start date
It depends on what you are doing. If your project consists of a single source file then there is probably no advantage in using make.
On the other hand if your project has multiple source files then you should be using make as it will only re-compile the files need re-compiling i.e. file that have changed or files that are effected by changes in other files.
On the other hand if your project has multiple source files then you should be using make as it will only re-compile the files need re-compiling i.e. file that have changed or files that are effected by changes in other files.
someonesdad
- Joined Jul 7, 2009
- 1,583
Alex's answer is spot on, but here are some other things to consider.
1. Projects always grow and add files and complexity. Having a well-written makefile makes it trivial to add new stuff to the build. It's also only a little more work to add handling for special cases.
2. If you use a portable make tool like GNU's, you can easily port your builds to other platforms with little to no work (assuming the other tools can also be ported).
3. GNU make can construct the include file dependencies for you -- this can be a non-trivial task on a larger project and can help you refactor code when necessary.
4. A 'make -n' can show you the files that have changed in your project and need to be rebuilt.
For a small project (here, small can be interpreted to be on the order of 1 to 10 source files), make might be considered to be overkill, especially if you have to spend a good chunk of time coming up to speed with using the tool. However, it scales pretty well and your make knowledge will be usable over and over again.
Here's what I do. Unless the project is only one or two files that compile/assemble pretty quickly, I use a makefile. If you do a lot of software development (e.g., make a living at it), you'll probably construct a boilerplate makefile and set up make to work as you like it on your system (many makes can be customized to your tastes). Then a new makefile for a small project only takes a minute or two -- you'd still be thinking through a script's logic. I use a shell function called vm that edits the makefile in the current directory or creates a new one from boilerplate if it doesn't exist. (I work in bash on Windows, but this could also be done with a DOS batch file.)
There are numerous tools similar to make that can also can do the same job as make, sometimes better. One advantage to using make is that your knowledge is pretty portable (not perfect) to other systems -- it's usually pretty straightforward to start using other flavors of make. If such portability is important to you, then learn to use only the elementary features and the old suffix rules syntax; otherwise, you'll have portability problems. This isn't much of an issue anymore because GNU make is available on any system I've worked on and GNU make has a good feature set.
1. Projects always grow and add files and complexity. Having a well-written makefile makes it trivial to add new stuff to the build. It's also only a little more work to add handling for special cases.
2. If you use a portable make tool like GNU's, you can easily port your builds to other platforms with little to no work (assuming the other tools can also be ported).
3. GNU make can construct the include file dependencies for you -- this can be a non-trivial task on a larger project and can help you refactor code when necessary.
4. A 'make -n' can show you the files that have changed in your project and need to be rebuilt.
For a small project (here, small can be interpreted to be on the order of 1 to 10 source files), make might be considered to be overkill, especially if you have to spend a good chunk of time coming up to speed with using the tool. However, it scales pretty well and your make knowledge will be usable over and over again.
Here's what I do. Unless the project is only one or two files that compile/assemble pretty quickly, I use a makefile. If you do a lot of software development (e.g., make a living at it), you'll probably construct a boilerplate makefile and set up make to work as you like it on your system (many makes can be customized to your tastes). Then a new makefile for a small project only takes a minute or two -- you'd still be thinking through a script's logic. I use a shell function called vm that edits the makefile in the current directory or creates a new one from boilerplate if it doesn't exist. (I work in bash on Windows, but this could also be done with a DOS batch file.)
There are numerous tools similar to make that can also can do the same job as make, sometimes better. One advantage to using make is that your knowledge is pretty portable (not perfect) to other systems -- it's usually pretty straightforward to start using other flavors of make. If such portability is important to you, then learn to use only the elementary features and the old suffix rules syntax; otherwise, you'll have portability problems. This isn't much of an issue anymore because GNU make is available on any system I've worked on and GNU make has a good feature set.
