avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

sample makefile (was:Re: [avr-libc-dev] Sample project - LedFlash)


From: E. Weddington
Subject: sample makefile (was:Re: [avr-libc-dev] Sample project - LedFlash)
Date: Tue, 25 Feb 2003 15:13:34 -0700

On 25 Feb 2003 at 22:44, Joerg Wunsch wrote:

> As E. Weddington wrote:
>
> > > Bzgl. Makefile: Habe ich grundsätzlich aus dem Sample von Eric
> > > übernommen. Die TABs waren mir auch aufgefallen, da es aber keine
> > > Probleme gab, habe ich die nicht rausgemacht. Da sind auch COMPILE
> > > anstelle CC etc. drin. Kann ich aber gerne überarbeiten.
>
> [In short: my complaint was that all our examples should follow a
> single Makefile style, and all those non-conventional makefile macros
> like COMPILE for CC etc. annoyed me a little.  Also, TABs are only
> allowed in front of commands not macros, even though gmake tolerates
> them in front of a macro.  Since TABs are hard to distinguish them
> from spaces, i'd vote to have no spaces before a macro name either.]

<rant topic="off">
Yeah well any program that has to distinguish between hardcoded tabs
and spaces instead of just looking for whitespace is brain dead and
should have been redesigned years ago!
</rant>


> > Yes, I make no claims that the sample makefile in WinAVR has
> > anything to do with Unix standards.
>
> Ah, i didn't know you're the culprit. :-)
>
> > It was modified from the AVR Freaks
> > distribution and I kept the same variable names because it would be
> > slightly easier for newbies to understand COMPILE than CC, etc.
>
> Maybe.  But i'd rather annotate the Makefile then somehow as opposed
> to deviate too much from traditional conventions (that have a more
> than 20-year tradition).  Most of these macros have reasonable
> predefined values, only some of them need overrides to cope with our
> special tool names (avr-cc instead of cc), and a few others need
> additions.

> > But because this sample would be rolled into avr-libc and be for
> > *all* platforms then I would encourage changing the makefile to
> > conform to Unix standards.
>
> Plus whatever is required to make the Win users happy (like the
> addition of objtool).  Could probably be handled by the auto* tools
> again.  We've been ignorant about this by now, but when we are going
> to ship our example Makefiles to the Great Unwashed Masses, we need to

I like it, "ship it to the GUM"!

> make sure they won't cause us too much support hassles :), because as
> we all know, people don't RTFM, then they don't RTFM, then they ask in
> a forum or mailing list, then they don't RTFM, and only eventually
> when being forced, they start RTFMing. :-)

Well considering all the problems I keep having with the sample
makefile, Jörg,  if you're willing to hack it to bring it in line
I'll be happy to have it.:-) However, I certainly don't want to
overload you either. (I can think of a different feature I'm more
desperate to have. ;-)

I don't care either way whether a sample makefile is rolled into avr-
libc or not. If people think that there is a use for a sample
makefile for Linux / FreeBSD / Solaris users then by all means roll
it in.

I could see a use for a (somewhat) "standard" sample makefile that
can be used for all the examples. I agree that some concessions would
have to be made for Windows and if it is handled by auto tools that's
fine too.

And this brings up another point about line-endings. I know there are
issues in WinAVR 20030115 about the Unix line endings in the avr-libc
example sources. I didn't think to convert them to Windows (I was in
a rush at the time), and that's made for some problems. I'm
completely at fault for that. I'm planning to do it in a script on my
end for the next WinAVR release but, again, it might be good to make
that platform dependent. Line ending conversion would also apply to
any sample makefile as well.

But before we go too crazy about auto tools and platform dependencies
I think it would be good if more people (me for example) where up to
speed on the auto tools to help poor Ted out. He must be sick of
hacking up auto* fixes! :-)

Eric




> --
> J"org Wunsch                                         Unix support engineer
> address@hidden
> http://www.interface-systems.de/~j/
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/avr-libc-dev






reply via email to

[Prev in Thread] Current Thread [Next in Thread]