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

[Theodore A. Roth]

On Fri, 30 Apr 2004, Joerg Wunsch wrote:

> As Theodore A. Roth wrote:
>
> > > ./bootstrap: ./devtools/gen-avr-lib-tree.sh: not found
> >
> > If updated and existing tree to the autoconf branch you might need to
> > use the -dP option to cvs update. It's probably best to just do a clean
> > checkout of the branch though.
>
> Sure, that's hardwired into my fingers. ;-)

Be careful. Sometimes using -dP is not the best way. With gdb/gcc/etc,
you would end up getting more than you wanted. What I now do for
gdb/gcc/etc is create a directory, for example gcc-3.4-cvs/, and in that
directory is an update.sh which checks out the tree. If the tree already
exists, you end up just getting an update. This is basically what the
gdb folks recommend doing to update the gdb sources since 'cvs up -dP'
does not do the right thing and without -dP, the update won't pull in
any newly created subdirs. If also started checking things out with -P
to prune empty directories.

For avr-libc, -dP should be fine for now.

>
> > The devtools/gen-avr-lib-tree.sh script is definitely in cvs though.
>
> Yep, I should have looked closer.  I've been fooled by the above
> message...  You've got #!/bin/bash there -- which does not exist.
> It's part of the way how execve(2) works that it just reports ENOENT
> in that case, even though the script itself /does/ exist, yet the
> interpreter doesn't.
>
> Would you mind changing that to the generic #!/bin/sh?  As far as I
> can tell, there are not even Posix-shell-dependant features in that
> script, let alone bash-dependent ones (IOW, everything is compatible
> to the plain old UNIX V7 Bourne shell :).

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've committed a fix.

The only questionable feature I've used in the <<-EOF to allow
pretty-ing up the code with indentation.

Hmmm, 'mkdir -p' might be a portability issue too.

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. Users of the dist-tarballs may never even need to see the
gen-*.sh script.

>
> > To build a cross-compiler with the configure generated by the newer
> > autoconf/automake tools, you have to specify --build and --host and
> > they must be different. I tried really hard to have it automagically
> > set in configure.ac, but they've changed the internals making it
> > difficult if not impossible to do.
>
> I don't mind that much.  When building the FreeBSD ports, that can
> easily be wired into their Makefile infrastructure.
>
> The build times I'm getting are:
>
> . 1x AthlonXP 1100 workstation         4:30
> . 1x Athlon 900 workstation            5:00
> . 4x UltraSPARC 296 server (make -j4) 11:00

I haven't tried it myself, but things might be a bit faster by disabling
dependancy tracking (it should be configure options). I think that deps
are a good thing. There is not currently dep tracking for anything
compiled from asm source. I have not dug into exactly why, put I think
it might just be a deficiency in gcc -M. (???)

>
> That seems to be without docs still?

Correct, no docs yet. I want to focus on getting the libs built properly
first. Next on the todo list is to set the right compile/assemble/link
flags for each device. There's provisions for that already in the
gen-*.sh script.

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