I noticed that many assembly coders are industriously into using batch scripts when making their project. I tried to search the forum for makefile and didn't find all that much so I decided to make a basic usage tutorial using Microsoft Program Maintenance Utility (NMAKE.EXE)
First I will explain some of the bads of using a typical batch script, where you compile your program without much more thought than that.
- All modules will be forced to re-assemble and linked everytime you make slight changes to one or several modules
- Build time will go up accordingly
- Hard drive will be more busy, and having a quiet and idle hard drive is always better in pretty much any situation
- Using batch files will in most cases give little clue which files were altered before you rebuilt them, because all of them are rebuilt without any further notice
- Another minor problem with batch scripts is if you have a security program on your computer, it might block each new batch script by default,
and if you create a new batch script to each new asm project you have to unblock the script every time, this won't happen using makefiles as nmake.exe
is the only file you will really need, and you only need to unblock it once. (Just a minor problem)
Let's make a simple makefile:
open your text editor, save the file as MAKEFILE without extension and store it in your project root folder, then edit it with your text editor.
NAME=MyProgram
$(NAME).exe: $(NAME).obj $(NAME).res
c:\masm32\bin\polink /SUBSYSTEM:WINDOWS $(NAME).obj $(NAME).res
$(NAME).res: $(NAME).rc
c:\masm32\bin\rc /v $(NAME).rc
$(NAME).obj: $(NAME).asm Include.asm
c:\masm32\bin\ml /c /coff /Cp $(NAME).asm
The first line is a variable where I put the name of the program file so that you can easily change the program name later without having to change the entire makefile.
The second line "$(NAME).exe: $(NAME).obj $(NAME).res" is a dependency line, it means that MyProgram.exe depends on the two files MyProgram.obj and MyProgram.res. If any of the two files are altered, it will rebuild MyProgram.exe by following the command on the next line. Remember that all commands that follow dependency lines must be indented with one tab character, or else it will not work. However you may put empty lines between dependencies to make the file more readable.
MyProgram.exe is dependent on the two files mentioned, these two files also have dependencies further down. Pay attention that the MyProgram.obj depend on the include file called Include.asm. If you alter your include file only, without altering any other source files, it will trigger that .obj needs to be rebuilt for one reason:
1: The object file is the main program and its source file depends on the include file.
To build your project, simply type NMAKE in your project folder.
If you run NMAKE for the first time, it will build the entire project. You will get a similar screen like this:(http://i.imgur.com/NTGrZ.png)
If you try to re-run NMAKE right afterwards, you will notice it will not rebuild it, because it is up to date:(http://i.imgur.com/wVTPW.png)
I guess that is pretty much it for a basic makefile.
NMAKE Reference (http://msdn.microsoft.com/en-us/library/dd9y37ha.aspx)
Perhaps is it possible to create it with the c++ ?.
Yes that should be possible. It is not an assembly specific tool, it is used in ms visual c++. But for the sake of my ego I prefer to look at it as an masm-only tool :lol
it may make sense for larger projects
but, be careful you are not spending more time setting up make than you are on code :bg
:bg
What is the date of the last Microsoft NMAKE utility ? :P
Its basically a clapped out piece of junk that was needed back in the DOS days. There is nothing you can do with NMAKE after you waste the time to learn its syntax which varied from version to version that you cannot do with batch files and libraries.
Build each module, make a library then link it all together. Its extendable, efficient and flexible, everything that NMAKE is not. All that NMAKE does is check the system times of files and build those that are out of date. Larger IDEs manage their own projects without a piece of junk like this, why waste your time ? :P
I don't know if they keep adding the same version number every time they build masm, but it has the same version as ml.exe and link.exe which was built April 12, 2010
If you don't have it and intend to get it, then you need msvcr100.dll too nmake.exe is dependent on it.
NMAKE made more sense in the day when rebuilds of even relatively small projects could take a significant amount of time.
or large projects with hundreds/thousands of small files (function per file) which are common in the commercial space.
The make file also provides a method of expressing dependency when a single file change might have local or global ramifications.
Sure IDE's can mask this, or generate make files, but some systems without a graphical interfaces work much better with scripts or make files.
Learning GNU Make might be a better choice, but being familiar with all available tools helps you make better solutions.
Like hutch, I mostly use batch files, especially for simple build tasks, but there are certainly times and places where make files are preferable.
makefiles has its place, no doubt. Pointing out 20 reasons why it is good makes no difference, somebody will just scream no and the one who screams loudest is usually right. If you have used batch files for 30 years, there is no reason to argue with that person, he will prefer to 'shoot you dead' before anything else :lol There comes a point in life where change is unwanted and actually poses a threat, a threat of 'change'
Better not mention distributed build processes, hutch's head will explode... Ducks.
MSbuild is the more current 'make' program, though it's tailored more towards an integrated IDE than a command line script
-r
:bg
It comes from being an NMAKE jockey with Microsoft C 6.0 (not VC 6), MASM 6.0 and later and the pro version of Microsoft basic long ago. It had its place in the DOS days but computer hardware is some powers faster and with vastly more powerful capacity and many of the considerations from way back then no longer exist.
My problem with such a restricted old tool is my larger projects do far more than just use compilers or assemblers. Where I have libraries in a project I simply link them into the final result, then with an installation I use archiving to get the entire package into a more compact size, convert the archive to an object module then link it as well, depending on the project I do a current build of the entire directory tree before archiving then remove anything that is constructed dynamically to get the size down further. On my own EXE and DLL files I regularly use exe compression as it suits the design I have for faster loading.
I do any of thse projects with a combination of batch files, dedicated exe files, external archivers, exe compressors, post compile patching etc etc .... this is why I long ago gave up on NMAKE, its an antique pile of junk from the DOS era.
Quote from: hutch-- on August 03, 2011, 12:29:25 AM
:bg
It comes from being an NMAKE jockey with Microsoft C 6.0 (not VC 6), MASM 6.0 and later and the pro version of Microsoft basic long ago. It had its place in the DOS days but computer hardware is some powers faster and with vastly more powerful capacity and many of the considerations from way back then no longer exist.
My problem with such a restricted old tool is my larger projects do far more than just use compilers or assemblers. Where I have libraries in a project I simply link them into the final result, then with an installation I use archiving to get the entire package into a more compact size, convert the archive to an object module then link it as well, depending on the project I do a current build of the entire directory tree before archiving then remove anything that is constructed dynamically to get the size down further. On my own EXE and DLL files I regularly use exe compression as it suits the design I have for faster loading.
I do any of thse projects with a combination of batch files, dedicated exe files, external archivers, exe compressors, post compile patching etc etc .... this is why I long ago gave up on NMAKE, its an antique pile of junk from the DOS era.
1: commandline makesfiles is not a replacement of similar gui alternatives, both constitute alternatives for both ways.
2: Older software does not become worse over the years, it becomes better, im not entirely sure if you are aware of this
3: I'm not arguing for that nmake is better than gui systems, im arguing that nmake is more practical for the specific job than batch scripts, im not sure if you have read my initial post.
4: About the philosophy of "computer hardware is better so we dont need it" has been refuted so many times over. Every rational thought says that if you can save resources, you will save it for the next program to use. Apparently as hardware grew more powerful, the amount of software that runs at the same time also increased proportionally. Which leads me to ask why do you code assembly in the first place, is it not to save resources and increase overall speed (Ofcourse also for its power)
5: About "antique pile of junk", it has been said the same thing about windows, it is from the dos days :) Software from the dos days that is not being updated, not being shipped anymore IS antique pile of junk. Software that continues to be updated, continues to be shipped and constitutes an alternative to gui is not antique pile of junk. It is antique, but not antique pile of junk.
hutch, the first point is more important. :wink
================================================
I also would like to say that, nmake is not really all that much about speed or saving resources. It is about redundancy, despite all the power we have today there is something fundamentally uncharming about redundancy (and we still feel the waste, we still feel it, we're not that super yet), it is about wearing out computer parts, it is about build numbering, it is about saving a few seconds here and there, it is about getting feedback which modules were assembled and linked and which were not, it is about being able to immediately switching back to the code editor once you discover that "is up to date" message, instead of waiting for the project to be built, then running it to manually see if there were any changes made to gui (which you could eliminate by reading the "up-to-date" message, then you would know there were nothing to check out)
All these little details, it makes nmake a very cool tool. I certainly like it, and I see no reason to skip it if you already are in the commandline. :U
Quote
All these little details, it makes nmake a very cool tool. I certainly like it, and I see no reason to skip it if you already are in the commandline.
So, there is only one thing to say to you 'Good laern of it !'
As my understanding, nmake or other kinds of make tool is used for automatically compile/link , I prefer to bat script if the project is not so huge ,here is an example: http://four-f.webs.com/KmdTut/kmd03.html
Just to add another funny layer in this thread. I actually use a batch file to CREATE the makefile whenever I create a new project. I call it CMAKE.bat
I type CMAKE <programname> and it will automatically create the makefile for me. :lol
Batch files are very useful, don't get it wrong.
Quote from: zemtex on August 04, 2011, 06:07:19 AM
Just to add another funny layer in this thread. I actually use a batch file to CREATE the makefile whenever I create a new project. I call it CMAKE.bat
I type CMAKE <programname> and it will automatically create the makefile for me. :lol
Batch files are very useful, don't get it wrong.
Actually, threre's a well known build system generator called CMake (http://www.cmake.org/). It's used by big open source projects like KDE, MySQL, etc. :green
:bg
I haven't tried that one out.
Very good ！ :U