Re: Volunteer available

[Paul D. Smith]

%% "Eray Ozkural (exa)" <address@hidden> 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 <address@hidden>          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