Re: [avr-libc-dev] more ac branch updates

[Theodore A. Roth]

On Sun, 2 May 2004, Joerg Wunsch wrote:

> As Theodore A. Roth wrote:
>
> > > Would you mind changing that to the generic #!/bin/sh?
>
> > No problem. It should probably be changed to '#! /bin/sh' for best
> > portability, but I think that's only and issue for some very obscure
> > systems that nobody is going to be doing avr-libc development on
> > anyways.
>
> [I hope we aren't going to bore the non-Unixers now...]
>
> Curious: do you have any evidence of a system where #!/bin/sh would
> not work but #! /bin/sh would?  While the BSD manual (that claims to
> be the origin of the #! interpreter feature, starting at 4.2BSD, which
> sounds trustworthy) always documented the space after #!, the code
> always allowed for both.  I doubt that anyone who cloned it would have
> done stricter than that.

This autoconf manual has a lot to say about portable shell programming:

  
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_114.html#SEC114

>
> The only portability issue I know of is that BSD restricts the args
> after the #! to be just the interpeter path name, plus at most a
> single argument passed on the command line.  Other implementations (I
> think Linux belongs to them) allow for an arbitrary number of args on
> the command line.

I don't plan on adding any args to the she-bang line, so we should be
fine.

>
> > I've committed a fix.
>
> Thanks.
>
> > The only questionable feature I've used in the <<-EOF to allow
> > pretty-ing up the code with indentation.
>
> I think that's indeed not backwards compatible to the V7 UNIX
> shell. ;-)  However, it's portable to any newer dialect of /bin/sh I
> know of, including the Solaris one (which is a pretty ancient one
> otherwise, since they never had the heart to make /bin/sh Posix
> compliant).
>
> > Hmmm, 'mkdir -p' might be a portability issue too.
>
> Probably more than <<-EOF, albeit any recent Unix I've seen implements
> this one, too.  The oldes system I've got access to is an HP-UX 10.20,
> it already has got mkdir -p.
>

Ok. I'll rewrite that stuff then. We'll probably never hit those fringe
cases, but these are really trivial things to catch now.

> > Maximal portability is not a concern though unless we decide to stick
> > with the avr/ tree generator script permanently. I'd rather use python
> > for this script, but I don't want to force that requirement on too many
> > people.
>
> As long as the script remains that simple, I'd stick with plain Bourne
> shell syntax for it.  Btw., I'm perfectly happy with creating the
> compilation dir hierarchy using a script (as opposed to maintaining it
> completely in CVS).

I think the scripted method will be easier to maintain in the long run
since global changes to the build dir will be centralized instead of
spread across more than 35 directories.

>
> > I haven't tried it myself, but things might be a bit faster by disabling
> > dependancy tracking (it should be configure options).
>
> Only marginally, it dropped compilation time by 10 secons on my Athlon
> 900.  Not worth mentioning.

Definitely not worth it.

>
> I'm a bit surprised that parallel builds seem to scale rather poorly,
> both on your dual Xeon, as well as on the 4x UltraSPARC here.

We're probably IO bound since we have so many small files to compile.
One then we can try is forcing make to compile each device dir as a unit
and then do the units in parallel.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden