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)? On an embedded Linux system I am working with, I've been using this approach to fix some "host machine arch not found" errors. I would be able to live with ports being broken for a bit if it means we can get the change in... I'd even put in some time that I can to help fix the ones that I depend upon. -- Coleman Kane
signature.asc
Description: This is a digitally signed message part
