David Brown <david.brown@hesbynett.removethisbit.no> writes:
> 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.
> On Mar 4, 5:07 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
> wrote:
>> 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.
>
> 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.
Reply by toby●March 4, 20082008-03-04
On Mar 4, 5:07 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:
> 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.
How is that different from any other tool? Write, test, debug, rinse,
repeat.
>
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultanthttp://www.abvolt.com
Reply by toby●March 4, 20082008-03-04
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
> -- 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
Reply by David Brown●March 4, 20082008-03-04
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.
Reply by Vladimir Vassilevsky●March 4, 20082008-03-04
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
Reply by CBFalconer●March 4, 20082008-03-04
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
Reply by Anton Erasmus●March 4, 20082008-03-04
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
Reply by Lanarcam●March 4, 20082008-03-04
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.
Reply by Vladimir Vassilevsky●March 4, 20082008-03-04
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