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

[Joerg Wunsch]

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.

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'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.

> 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 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.

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.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/