http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip

[Judah Jacobson]

On Jan 5, 2008 10:29 AM, Thorkil Naur <naur at post11.tele.dk> wrote:
> On Friday 04 January 2008 12:03, Christian Maeder wrote:
>
> I understand that there are problems in this area, but I am not convinced that
> they could not be solved without the renamed and/or modified readline
> library. I am sorry if you have done that already elsewhere, but I don't
> recall having seen any details about your difficulties. Would you be kind
> enough to supply some details? Thanks a lot.
>
> > The alternative is to use static linking of gmp (as suggested by chak)
> > _and_ readline (version 5), so that user programs are also statically
> > linked with these libs.
>
> Again, I am not convinced that this is the only alternative.

There is another alternative (which I think we talked about before):

Have ghc manually search for frameworks in the standard folders
(rather than letting gcc do it automatically).  Then if we found e.g.
/Library/Frameworks/GNUreadline.framework, we would pass the following
flag:
-I/Library/Frameworks/GNUreadline.framework/Versions/A/Headers
In that case, we would not need modified readline headers.

However, I really don't like the above, since we're reimplenting
something gcc gives us for free.  And if we *do* rely on gcc's
standard searching (as is the case now), then I agree with Christian
that modified headers are necessary for GNUreadline to work as a
framework.

Also, the script that builds GNUreadline.framework modifies the header
files automatically.  So I don't think it's any worse than, say,
pre-processing a library as part of a MacPorts distribution.

> > ...
> > Regarding this actual GNUreadline-framework.zip replacement, this is
> > harmless and seems to matter only for those who build ghc with
> > frameworks (as only the inclusion of header files changed)
>
> It is perhaps without any practical consequences, but I have seen many cases
> where circumstances managed to create the most glorious confusion out of the
> most innocently looking changes. So I would maintain that replacing something
> that you have published with something different is not a good idea.

I looked into this, and frameworks do already support versioning:
http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html

In particular, one framework can contain multiple versions.  So
currently GNUreadline.framework contains:

  Versions/A/GNUreadline (object code file)
  Versions/A/Headers (a folder containing header files)
  GNUreadline (symlink to `Versions/A/GNUreadline`)
  Headers (symlink to `Versions/A/Headers`)

And we could distribute instead a GNUreadline.framework which contains:

  Versions/A/GNUreadline (object code file)
  Versions/B/GNUreadline (symlink to the above)
  GNUreadline (symlink to Versions/A/GNUreadline)
  Versions/A/Headers (a folder containing unmodified headers)
  Versions/B/Headers (a folder containing modified headers)
  Headers (symlink to Versions/B/Headers)

The above makes version B the default, but version A is still
available if you want it.  We could do something similar when
upgrading to readline 6.0 if it ever comes out.

Finally, we could also change the name of the .zip file to reflect the
version of the framework, so that users don't confuse the two
downloads.

Would the above make the modified GNUreadline feel like less of a hack?

Best,
-Judah