Coleman Kane wrote:
On Thu, 2008-05-08 at 01:19 +0200, Kris Kennaway wrote:
Alfred Perlstein wrote:
* John Baldwin <[EMAIL PROTECTED]> [080507 10:28] wrote:
On Wednesday 07 May 2008 02:40:13 am Alfred Perlstein wrote:
* John Baldwin <[EMAIL PROTECTED]> [080505 13:47] wrote:
On Monday 05 May 2008 03:24:17 pm Peter Jeremy wrote:
On Mon, May 05, 2008 at 02:59:28PM -0400, John Baldwin wrote:
On Monday 05 May 2008 02:40:03 pm Alfred Perlstein wrote:
I'm _not_ objecting, just interested in why.
Any references to discussions on this? Are we now safe for
future compat or something?
Having FILE be opaque broke just about every 'configure' script on the
planet. :(
Either autoconf and friends are _intended_ as impediments to
portability or they are completely broken by design.
It appears that autoconf only believes a type is real if you can typedef
it to
another type, cast 0 to a valid pointer to the new typedef'd type, and do
a
sizeof() of the typdef'd type. The last is where having an opaque type
breaks down for scripts that want to make sure FILE is a real type.
Oh c'mon! we're going to revert this needed fix just because of
autoconf?
Pretty much. It appears that FILE has been public for so long that there is a
lot of code that assumes it can use it.
I don't think that's really fair, stdio has had adequate accessors
for a long time, if AN(*) application does the wrong thing for long enough
it does not make it right.
(*) Important note: when considering autoconf scripts, most of the
scripts test's come from a repository of scripts or are carbon
copied from each other. Saying that "all ports are broken" is not
true, it is a single suite of configuration scripts that are broken
and need fixing, then we will be OK.
We have precident here of hacked autoconf and ports build logic
that automatically "seds" various things in scripts. I think
a few knobs can fix this for us.
The offer was a serious one. If you're interested in evaluating the
impact of this change on ports then just say the word.
Kris
What if we fix this breakage through a patch in our autoconf/automake
and then put a toggle in the ports system that could be told to re-run
autogen on the offending ports before the configure script is run
(hopefully replacing the broken "configure" with one that works)?
If it was just the broken autofools then this might work, except
1) It's not just autofools that are broken (the fact that several parts
of the base tree were already broken gives some estimation of the rate
of other code breakage that should be expected)
2) There are lots of ports that tweak the autoconf output, either
upstream in the vendor or in the port. Fixing them to work properly
again will be an exercise in patience, subtlety and irritation.
Anyway -- again -- we won't know the precise impact until we run a full
build with a group of volunteers to study the results.
Kris
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
