RE: library infrastructure roundup
There is also a sense that it might be useful for Haskell implementations to provide a gtk-config type tool for letting a build system know where it wants to keep stuff...
Actually I think this is not the right way to go. It should be the package manager on the host system that tells the build system where it wants to keep stuff. Certainly the library needs to inform the Haskell implementation where it lives: that's what gtk-config does in essence, and what the GHC package system does in a more general way. But I don't see a need for the Haskell implementation to tell the library where it should place its files; indeed this is likely to conflict with OS package managers that like to keep control of where files are installed. Cheers, Simon
On Tuesday 17 June 2003 12:43 pm, Simon Marlow wrote:
Actually I think this is not the right way to go. It should be the package manager on the host system that tells the build system where it wants to keep stuff.
And then ghc (or whatever compiler) asks the package manager where stuff is installed? [Seems like a fine distinction but I can just about see it.] Actually, I think the right thing is to invoke ghc-pkg via the ghc driver. This would solve the recent problem (cvs commit by SimonPJ I think) about how specifying a particular ghc when invoking configure could leave you using an incompatible ghc and ghc-pkg. Similarily, I think the best way to add gtk-config-like functionality is for ghc (hugs, nhc, etc.) to provide something like $ ghc --print-config=libdir /usr/lib/ghc-5.04.2 rather than having a separate tool provide information about a potentially different installation of ghc. Please note that all I'm saying is that the frontend driver for the compiler should invoke the gtk-config-like program for you - the values that program produces may well be generated by package maintainers/ platform/ etc. -- Alastair
random question, I have not been paying too much attention to the conversation, but in the proposed schemes, are there ways to install libraries local to a user? I don't always have root access on machines which I need to compile programs. Just a thought. Also, one might want to look at the design of pkg-config, which is a generalization of the whole (gtk|foo|bar)_config concept. i believe there is info on freedesktop.org and probably pkg-config(1) on recent linux boxen. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
On Tuesday 17 June 2003 10:09 pm, John Meacham wrote:
random question, I have not been paying too much attention to the conversation, but in the proposed schemes, are there ways to install libraries local to a user? I don't always have root access on machines which I need to compile programs. Just a thought.
Yes! That has been a signifcant thread in our offline discussion. Section 3.2.2 and 3.2.3 of http://haskell.org/hawiki/LibraryInfrastructure talks about this. Please feel free to edit the wiki. btw I currently 'solve' this in my Makefiles by making up my own package.conf file which I put in: $(libdir)/package.conf (where libdir is the value generated by running configure). I then use: HC_OPTS += -package-conf $(libdir)/package.conf to make sure that GHC knows to use it. Sadly, I also have to write: boot :: test -f $(libdir)/package.conf \ || (install -m0755 -d $(libdir) ; echo "[]" > $(libdir)/package.conf) because 'ghc-pkg --update' objects if the package.conf file doesn't exist. This approach seems like a plausible workaround for any one author to use for their libraries. Of course, it doesn't work so well if you want to use libraries written by me and libraries written by someone else since we're unlikely to hit on the same filename - which is why I want packagers to agree on a standard location for each platform and for compiler folk to provide a way that packagers can bake that location into the compiler frontend as they build the compiler package.
[...] pkg-config [...]
Section 3.3 of the same page talks about these foo-config programs but I don;t think any of us have heard of pkg-config. Can you edit the wiki with some info/pointers please? (Also worth copying it to this list since mail works better than wiki for some purposes.) -- Alastair Reid
On Tuesday 17 June 2003 12:43 pm, Simon Marlow wrote:
Actually I think this is not the right way to go. It should be the package manager on the host system that tells the build system where it wants to keep stuff.
[Rereading this, I see I misunderstood 'package manager'. I read it as 'ghc-pkg' and friends when you meant the debian/ redhat/ windows package manager that is used for installing all software on the machine.] I agree that the decision lies with the people who package libraries and must conform with guidelines for the individual platform. But I think that compiler writers can help implement whatever decision those people make. An easy way of doing this is for compilers to always consult a configuration file which says where globally and locally installed libraries are located. A ghc distribution might come with certain default locations baked into it but those would be overridden if the configuration file is found. This is easy for people packaging ghc to deal with because all they have to do is provide a config file which contains the platform preferences. Suppose we do this and you go to install a library. Where should the library be installed? Obviously, it should go in the place that the platform maintainers prefer. How can you find where that is? By consulting the configuration file. Does this mean you're asking ghc where to put files? No, what you're doing is asking the ghc package (which includes config files that the ghc hackers did not write) where to install the library. Even if the way you read the config file is by calling some ghc-config or ghc --print-config=libdir, it doesn't change the fact that the ghc hackers aren't making the choice of where libraries are installed - they're merely making it easy for the package maintainers to express their choice. -- Alastair Reid
participants (3)
-
Alastair Reid -
John Meacham -
Simon Marlow