Forums

Make script

Started by Nickolai Leschov March 4, 2008
Hello!

I have a project that used to be compiled via IDE. As I didn't like the 
IDE much, I made a 'make' script to compile it. I had to use extended 
syntax so it will run on NT-XP, not Win98 and the like.

Host OS: Windows XP
Target: PIC18F452 CPU
Language: C
Compiler: HI-TECH C Compiler
IDE: MPLAB IDE

Target is an embedded CPU, so I compile code on host machine then write 
it to CPU using a programmer (specialized piece of hardware). Currently 
I can only do this from IDE, but I hope I will be able to use 
command-line tool for this.

I see many projects that come from Unix land use 'make', on the other 
hand, Maranda IM project, for one, upon brief examination, excessively 
uses Windows' .bat files to build.

So here's my question:

Am I doing the Right Thing or am I reinventing the wheel when I use 
scripts for which there is a well working tool (make) ?

Best regards,
Nickolai Leschov

Here's the script (make.bat):

set PROJECT_NAME=6.2.ver
set PROJECT_BASE=\WORK\IKG\IKG-6
set COMPILER_PATH=C:\HTSOFT\PIC18\bin
set COMPILER_NAME=picc18.exe
set CPU=18F452

set SOURCE_FILES=EE_AT INI MI2C ISR START RD_WR CF48T TIME COMMON SIGNAL 
TEST MAIN SUPERVISOR KEY1 KEY2 KEY4 BUTTUM LOG_NEW COM_MODBUS_NEW

set PROJECT_PATH="%PROJECT_BASE%\%PROJECT_NAME%"
set COMPILE="%COMPILER_PATH%\%COMPILER_NAME%" -C
set LINK="%COMPILER_PATH%\%COMPILER_NAME%"
@setlocal EnableDelayedExpansion
@echo.
@echo Compiling
@echo ---------
@for %%s in (%SOURCE_FILES%) do %COMPILE% -Q -MPLAB -%CPU% 
-I%PROJECT_PATH% "%%s.c" -E"%%s.cce" -O"%%s.obj"
@echo.
@echo Linking
@echo =======
@set OBJECT_FILES=
@for %%s in (%SOURCE_FILES%) do @set OBJECT_FILES=!OBJECT_FILES! "%%s.obj"
%LINK% %OBJECT_FILES% -Q -MPLAB -%CPU% -M"ikg6.map" -E"ikg6.lde" 
-O"ikg6.cof" -O"ikg6.hex"
@echo Done.
Nickolai Leschov wrote:

>Hello! > >I have a project that used to be compiled via IDE. As I didn't like the >IDE much, I made a 'make' script to compile it. I had to use extended >syntax so it will run on NT-XP, not Win98 and the like. > >Host OS: Windows XP >Target: PIC18F452 CPU >Language: C >Compiler: HI-TECH C Compiler >IDE: MPLAB IDE > >Target is an embedded CPU, so I compile code on host machine then write >it to CPU using a programmer (specialized piece of hardware). Currently >I can only do this from IDE, but I hope I will be able to use >command-line tool for this. > >I see many projects that come from Unix land use 'make', on the other >hand, Maranda IM project, for one, upon brief examination, excessively >uses Windows' .bat files to build. > >So here's my question: > >Am I doing the Right Thing or am I reinventing the wheel when I use >scripts for which there is a well working tool (make) ?
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.
>Best regards, >Nickolai Leschov > >Here's the script (make.bat):
I'd name it build.bat to avoid confusion with batch scripts that invoke make.
>set PROJECT_NAME=6.2.ver >set PROJECT_BASE=\WORK\IKG\IKG-6 >set COMPILER_PATH=C:\HTSOFT\PIC18\bin >set COMPILER_NAME=picc18.exe >set CPU=18F452 > >set SOURCE_FILES=EE_AT INI MI2C ISR START RD_WR CF48T TIME COMMON SIGNAL >TEST MAIN SUPERVISOR KEY1 KEY2 KEY4 BUTTUM LOG_NEW COM_MODBUS_NEW > >set PROJECT_PATH="%PROJECT_BASE%\%PROJECT_NAME%" >set COMPILE="%COMPILER_PATH%\%COMPILER_NAME%" -C >set LINK="%COMPILER_PATH%\%COMPILER_NAME%" >@setlocal EnableDelayedExpansion >@echo. >@echo Compiling >@echo --------- >@for %%s in (%SOURCE_FILES%) do %COMPILE% -Q -MPLAB -%CPU% >-I%PROJECT_PATH% "%%s.c" -E"%%s.cce" -O"%%s.obj" >@echo. >@echo Linking >@echo ======= >@set OBJECT_FILES= >@for %%s in (%SOURCE_FILES%) do @set OBJECT_FILES=!OBJECT_FILES! "%%s.obj" >%LINK% %OBJECT_FILES% -Q -MPLAB -%CPU% -M"ikg6.map" -E"ikg6.lde" >-O"ikg6.cof" -O"ikg6.hex" >@echo Done.
-- ======================================================================== Michael Kesti | "And like, one and one don't make | two, one and one make one." mrkesti at hotmail dot com | - The Who, Bargain
On Tue, 04 Mar 2008 16:29:09 +0300, Nickolai Leschov wrote:

> Hello! > > I have a project that used to be compiled via IDE. As I didn't like the > IDE much, I made a 'make' script to compile it. I had to use extended > syntax so it will run on NT-XP, not Win98 and the like. > > Host OS: Windows XP > Target: PIC18F452 CPU > Language: C > Compiler: HI-TECH C Compiler > IDE: MPLAB IDE > > Target is an embedded CPU, so I compile code on host machine then write > it to CPU using a programmer (specialized piece of hardware). Currently > I can only do this from IDE, but I hope I will be able to use > command-line tool for this. > > I see many projects that come from Unix land use 'make', on the other > hand, Maranda IM project, for one, upon brief examination, excessively > uses Windows' .bat files to build. > > So here's my question: > > Am I doing the Right Thing or am I reinventing the wheel when I use > scripts for which there is a well working tool (make) ? > > Best regards, > Nickolai Leschov > > Here's the script (make.bat): > > set PROJECT_NAME=6.2.ver > set PROJECT_BASE=\WORK\IKG\IKG-6 > set COMPILER_PATH=C:\HTSOFT\PIC18\bin set COMPILER_NAME=picc18.exe > set CPU=18F452 > > set SOURCE_FILES=EE_AT INI MI2C ISR START RD_WR CF48T TIME COMMON SIGNAL > TEST MAIN SUPERVISOR KEY1 KEY2 KEY4 BUTTUM LOG_NEW COM_MODBUS_NEW > > set PROJECT_PATH="%PROJECT_BASE%\%PROJECT_NAME%" set > COMPILE="%COMPILER_PATH%\%COMPILER_NAME%" -C set > LINK="%COMPILER_PATH%\%COMPILER_NAME%" @setlocal EnableDelayedExpansion > @echo. > @echo Compiling > @echo --------- > @for %%s in (%SOURCE_FILES%) do %COMPILE% -Q -MPLAB -%CPU% > -I%PROJECT_PATH% "%%s.c" -E"%%s.cce" -O"%%s.obj" @echo. > @echo Linking > @echo ======= > @set OBJECT_FILES= > @for %%s in (%SOURCE_FILES%) do @set OBJECT_FILES=!OBJECT_FILES! > "%%s.obj" %LINK% %OBJECT_FILES% -Q -MPLAB -%CPU% -M"ikg6.map" > -E"ikg6.lde" -O"ikg6.cof" -O"ikg6.hex" > @echo Done.
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. -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Tim Wescott wrote:
> > 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. >
[snip]
> > 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.
There are dozens, googling for "linux make makefile" yields: http://www.linuxdevcenter.com/pub/a/linux/2002/01/31/make_intro.html http://www.wlug.org.nz/MakefileHowto http://linuxgazette.net/issue83/heriyanto.html etc.

Tim Wescott wrote:


> Done right, make can save you a tremendous amount of time waiting for > tools to finish building large projects.
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.
> It can also help with keeping a > release process structured, and other cool things.
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 http://www.abvolt.com
On Tue, 04 Mar 2008 12:07:59 -0600, Tim Wescott <tim@seemywebsite.com>
wrote:

[Snipped]
> >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.
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
Vladimir Vassilevsky wrote:
> Tim Wescott wrote: > >> Done right, make can save you a tremendous amount of time waiting >> for tools to finish building large projects. > > 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. > >> It can also help with keeping a release process structured, and >> other cool things. > > 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.
Then you have a mistake in your makefile, and it should get fixed. That way the mistake won't happen again. Not really hard. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. -- Posted via a free Usenet account from http://www.teranews.com

CBFalconer wrote:

> Vladimir Vassilevsky wrote: > >>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. > > Then you have a mistake in your makefile, and it should get fixed.
At first, the build mistake should get noticed. The files of the older revisions could be included without any warnings.
> That way the mistake won't happen again. Not really hard. >
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 http://www.abvolt.com
Vladimir Vassilevsky wrote:
> > > Tim Wescott wrote: > > >> Done right, make can save you a tremendous amount of time waiting for >> tools to finish building large projects. > > 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. > >> It can also help with keeping a release process structured, and other >> cool things. > > 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. >
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.
On Mar 4, 1:07 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Tue, 04 Mar 2008 16:29:09 +0300, Nickolai Leschov wrote: > > Hello! > > > I have a project that used to be compiled via IDE. As I didn't like the > > IDE much, I made a 'make' script to compile it. I had to use extended > > syntax so it will run on NT-XP, not Win98 and the like. > > > Host OS: Windows XP > > Target: PIC18F452 CPU > > Language: C > > Compiler: HI-TECH C Compiler > > IDE: MPLAB IDE > > > Target is an embedded CPU, so I compile code on host machine then write > > it to CPU using a programmer (specialized piece of hardware). Currently > > I can only do this from IDE, but I hope I will be able to use > > command-line tool for this. > > > I see many projects that come from Unix land use 'make', on the other > > hand, Maranda IM project, for one, upon brief examination, excessively > > uses Windows' .bat files to build. > > > So here's my question: > > > Am I doing the Right Thing or am I reinventing the wheel when I use > > scripts for which there is a well working tool (make) ? > > > Best regards, > > Nickolai Leschov > > > Here's the script (make.bat): > > > set PROJECT_NAME=6.2.ver > > set PROJECT_BASE=\WORK\IKG\IKG-6 > > set COMPILER_PATH=C:\HTSOFT\PIC18\bin set COMPILER_NAME=picc18.exe > > set CPU=18F452 > > > set SOURCE_FILES=EE_AT INI MI2C ISR START RD_WR CF48T TIME COMMON SIGNAL > > TEST MAIN SUPERVISOR KEY1 KEY2 KEY4 BUTTUM LOG_NEW COM_MODBUS_NEW > > > set PROJECT_PATH="%PROJECT_BASE%\%PROJECT_NAME%" set > > COMPILE="%COMPILER_PATH%\%COMPILER_NAME%" -C set > > LINK="%COMPILER_PATH%\%COMPILER_NAME%" @setlocal EnableDelayedExpansion > > @echo. > > @echo Compiling > > @echo --------- > > @for %%s in (%SOURCE_FILES%) do %COMPILE% -Q -MPLAB -%CPU% > > -I%PROJECT_PATH% "%%s.c" -E"%%s.cce" -O"%%s.obj" @echo. > > @echo Linking > > @echo ======= > > @set OBJECT_FILES= > > @for %%s in (%SOURCE_FILES%) do @set OBJECT_FILES=!OBJECT_FILES! > > "%%s.obj" %LINK% %OBJECT_FILES% -Q -MPLAB -%CPU% -M"ikg6.map" > > -E"ikg6.lde" -O"ikg6.cof" -O"ikg6.hex" > > @echo Done. > > 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.
It also ensures no change is overlooked.
> 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
'info make' on any decent system, or: http://www.gnu.org/software/make/manual/make.html
> -- 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. > > -- > Tim Wescott > Control systems and communications consultinghttp://www.wescottdesign.com > > Need to learn how to apply control theory in your embedded system? > "Applied Control Theory for Embedded Systems" by Tim Wescott > Elsevier/Newnes,http://www.wescottdesign.com/actfes/actfes.html