%% "Eray Ozkural (exa)" <[EMAIL PROTECTED]> writes:
eo> However, my makefiles have been lying around for more than 2 _months_
eo> since my _rejected_ patch.
There's no reason for you to feel this frustration. That's what open
source is all about; you have the source, you have your patch, it works
for you; sounds like you're golden, where's the problem?
Use what you have, and when the new version is available you can switch
to that. It sounds like what you have done is largely user-compatible
what I'm doing.
eo> I'd like to go ahead and code it if Paul gives me an ok. My idea
eo> is that fmemopen is not such a bad idea if portability switches
eo> are put around it:
eo> * for glibc we use fmemopen and my patch, which is minimal
eo> and unobstrusive IMO.
eo> * in all other platforms other than the recent glibc, fmemopen
eo> is substituted with an internal implementation. I need to see
eo> if this is feasible, but as design it would seem nice.
Please be aware that "all other platforms other than recent glibc" means
every single computer platform in existence _except_ for unstable Linux
distros (AFAIK there are no released distros including GLIBC 2.2 yet),
plus Hurd.
That is _far_ too restrictive a subset to even be considered for GNU make.
As for an internal implementation, I think this is essentially
impossible. It would require that you understand the internal format of
FILE* on every single platform, which is basically impossible in any way
that approaches portability, and even if that were possible all the
functions that use FILE* would have to be compatible with a memory
stream implementation, which seems just as unlikely.
eo> Alternatively, read.c might be rewritten to abstract all buffer/stream
eo> ops. I've written some compilers before, so I guess I might do that
eo> too ;) But I don't know if it would be smaller than the first solution.
eo> I'd say smaller is better.
Smaller is better, all things being equal. But portable is far and away
more important than smaller. They're not even in the same ballpark.
Thx!
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://www.paulandlesley.org/gmake/
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
