Re: [avr-libc-dev] reconf

[Joerg Wunsch]

As Paul Schlie wrote:

> Nope, there's no reason for the current ./configure script not to be
> in the cvs archive, just as typically included in most such cvs
> archives.

Except it ``poisons'' the CVS repository, in that it can produce
arbitrary large diffs between versions (and thus bloats the CVS
repo).

The common policy is to not put generated files into CVS.  For
SourceForge, you can even read that in their guidelines. ;-)

I don't care too much about whether configure is in CVS or not though.
This seems to become a bikeshed discussion to me now (*).  So far, I
cannot remember of anyone who was going to build straight from CVS
that (s)he ever complained to run into troubles with running the
bootstrap script.  There are probably only few people who build it
right out of CVS, and those few who do know that they need the auto*
tools in order to get things done.

(*) 
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/bikeshed.html

Anyone running a released version doesn't need to care at all.  At
least, that's the theory.  I've seen one person in a German Web forum
who could not build it, as the pre-autoconf/make'ed release version
insisted on re-running automake in his setup, for whatever reason,
even when he plainly did nothing else but "./doconf; ./domake" (which
is the very same thing I do here, too).  That's the part I don't
really like with the auto* tools: they have a tendency where the egg
wants to be smarter than the hen.  (The generated Makefile tries to
re-run automake, even though I as the developer know better that
nothing has been done that would justify this step.)  The only remedy
to that guy was to temporarily remove his installed automake, so the
configure script couldn't find it, and thus could not work out
dependencies for automake into the generated Makefile hierarchy.

I'd say: EOD for now.  Eric promised to recreate a "bootstrap" script,
and if someone comes up with an updated infrastructure that can cope
with the recent versions of automake and autoconf, we'll gladly accept
that.  Until then, there is more important fish to fry than burning
our valuable time in unimportant infrastructure details.  If anyone
wants to beat me on finding why 0/0 doesn't produce a NaN: please go
ahead.  If anyone wants to tell me how to handle longjmps correctly:
please do.  Oh, and if anyone feels like contributing a 64-bit IEEE
floating point library: c'mon!  (As we're already settled on 32-bit
double types, this one might use long doubles, for example.)  This
would make us the second C compiler/library for the AVR that could
handle it, after the (very expensive) IAR one.

If anyone has still time to burn, just tell me, and be assured I'll
find a useful item to think about. :-)

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)