ANNOUNCE: GHC version 6.8.2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
72 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: ANNOUNCE: GHC version 6.8.2

sethk
On Sun, 16 Dec 2007 16:43:53 +0100
"Juanma Barranquero" <[hidden email]> wrote:

> On Dec 16, 2007 3:38 PM, Yitzchak Gale <[hidden email]> wrote:
>
> > As long as GHC has a built-in notion of "home directory",
> > which doesn't exist on Windows, there needs to be
> > a user-configurable way to specify what to do instead,
> > as there always was until now. It depends on a lot
> > of factors - exactly how are you using this
> > "home directory", how does it interact with other
> > apps, details about the platform, etc..
> >
> > If nothing is specified, then, as a last resort, there is no
> > choice but to use the Profile folder as the default.
>
> FWIW, I agree 100% with this.
>
>              Juanma

Indeed, what's the alternative?

Also, in general deployed programs are compiled and linked.  Behavior related to ghci initialization is not going to break deployed software.  Changes to the behavior of a development tool are in a different class than changes that may impact deployed programs.

Seth

> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>


--
Seth Kurtzberg <[hidden email]>
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: ANNOUNCE: GHC version 6.8.2

Felix Martini
In reply to this post by Yitzchak Gale
On Dec 16, 2007 3:38 PM, Yitzchak Gale wrote:
> No, the two are not the same. It is the User Profile folder.
> It is not a Unix-style home directory - there is no such concept
> on Windows. The two are used very differently.

I guess we disagree about that. I believe what Micosoft calls the user
profile folder is equivalent to what is called the user home folder in
Unix. This is especially obvious in Vista, most folder names are the
same as in OSX, e.g. C:\Users\Felix\Music and /Users/Felix/Music.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Isaac Dupree
Felix Martini wrote:
> On Dec 16, 2007 3:38 PM, Yitzchak Gale wrote:
>> No, the two are not the same. It is the User Profile folder.
>> It is not a Unix-style home directory - there is no such concept
>> on Windows. The two are used very differently.
>
> I guess we disagree about that. I believe what Micosoft calls the user
> profile folder is equivalent to what is called the user home folder in
> Unix. This is especially obvious in Vista, most folder names are the
> same as in OSX, e.g. C:\Users\Felix\Music and /Users/Felix/Music.

FWIW, here on Linux I didn't like all my automatically
generated-in-$HOME stuff being spewed all over my own organization, so

]echo $HOME
/Users/me/HOME
(I'm in GoboLinux which uses "/Users" rather than "/home", which isn't
important to this)

and my .zshrc has
cd; cd ..
(a.k.a. cd /Users/me)
to take me to my personal home directory in the non-Unix sense.  It's a
bit of a nuisance sometimes, but worth it for me; the worst that happens
is sometimes I have to go up a level first in file-chooser dialogs or
"~/../" paths.

Isaac

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

sethk
Isaac makes an important point (although I'm not sure it's the point he intended to make  :)   ), there is really nothing in the definition of UNIX itself that specifies or requires a home directory.  It's a convention followed by shells, primarily.

Seth

On Sun, 16 Dec 2007 14:36:55 -0500
Isaac Dupree <[hidden email]> wrote:

> Felix Martini wrote:
> > On Dec 16, 2007 3:38 PM, Yitzchak Gale wrote:
> >> No, the two are not the same. It is the User Profile folder.
> >> It is not a Unix-style home directory - there is no such concept
> >> on Windows. The two are used very differently.
> >
> > I guess we disagree about that. I believe what Micosoft calls the user
> > profile folder is equivalent to what is called the user home folder in
> > Unix. This is especially obvious in Vista, most folder names are the
> > same as in OSX, e.g. C:\Users\Felix\Music and /Users/Felix/Music.
>
> FWIW, here on Linux I didn't like all my automatically
> generated-in-$HOME stuff being spewed all over my own organization, so
>
> ]echo $HOME
> /Users/me/HOME
> (I'm in GoboLinux which uses "/Users" rather than "/home", which isn't
> important to this)
>
> and my .zshrc has
> cd; cd ..
> (a.k.a. cd /Users/me)
> to take me to my personal home directory in the non-Unix sense.  It's a
> bit of a nuisance sometimes, but worth it for me; the worst that happens
> is sometimes I have to go up a level first in file-chooser dialogs or
> "~/../" paths.
>
> Isaac
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Manuel M T Chakravarty
In reply to this post by Ian Lynagh
Ian Lynagh:

> On Fri, Dec 14, 2007 at 12:11:17PM +1100, Manuel M T Chakravarty  
> wrote:
>>>
>>> otool -L compiler/stage2/ghc-6.8.2
>>>      /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0,
>>> current version 8.1.0)
>>
>> Yes, it does.  That's very strange for the *stage2* compiler.  I ran
>> otool on pwd and ghc-pkg (which were the problem in 6.8.1 and those
>> binaries don't depend on "gmp").
>>
>> Ian, why would a stage2 compiler depend on an external gmp?  I  
>> thought
>> it would always use the one bundled with ghc.
>
> Do you mean the one in gmp/ in the ghc repo? That's only used if there
> isn't an external GMP on the system; it's basically only there because
> we don't want to require that Windows users install GMP.

It seems to be a matter of the precise ld call parameters whether the  
gmp/ in the ghc repo is used or the external one.  In using the stage1  
compiler to link the stage2 compiler, the external one wins, but in  
linking other programs with the stage1 compiler, the internal gmp wins.

Actually, I think, we should use the gmp/ in the ghc repo by default  
(at least on non-Linux).  Why?  I don't think it is nice to build  
binaries by default that I can't copy to and run on another computer  
running the same OS without having to install extra fancy stuff like  
gmp.  In other words, your average Mac doesn't have gmp installed.  
Just because I happen to have gmp on my Mac, I don't want to build a  
dependency into all binaries generated by ghc that prevent me from  
using these binaries on other Macs.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Simon Marlow-5
In reply to this post by Yitzchak Gale
Yitzchak Gale wrote:
> Removing support for %HOME% has suddenly broken many
> programs. If people don't like it, we can consider
> deprecating it in some future version of GHC, but for now
> it should put back.

Only GHCi has changed here.  Perhaps you're under the impression that we
recently changed the behaviour of getHomeDirectory?  In fact, it was
introduced in GHC 6.4 and has always had the same behaviour, calling
SHGetFolderPath on Windows.

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Christian Maeder-2
In reply to this post by Manuel M T Chakravarty
Manuel M T Chakravarty wrote:
> Actually, I think, we should use the gmp/ in the ghc repo by default (at
> least on non-Linux).  Why?  I don't think it is nice to build binaries
> by default that I can't copy to and run on another computer running the
> same OS without having to install extra fancy stuff like gmp.  In other
> words, your average Mac doesn't have gmp installed.  Just because I
> happen to have gmp on my Mac, I don't want to build a dependency into
> all binaries generated by ghc that prevent me from using these binaries
> on other Macs.

Right, the (hets) binaries that we create also depend on readline-5 that
is not installed on average Macs. Therefore we've invented this
GNUreadline framework, which can be at least copied into one's home
directory (without too much effort).

Do you think ghc should provide readline-5 as internal library, too? I
wouldn't mind giving up this dylib and framework confusion, but wasn't
there a license problem (maybe for our GNUreadline framework, too)?

Christian
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Ian Lynagh
In reply to this post by Manuel M T Chakravarty
On Mon, Dec 17, 2007 at 12:53:32PM +1100, Manuel M T Chakravarty wrote:
>
> It seems to be a matter of the precise ld call parameters whether the  
> gmp/ in the ghc repo is used or the external one.  In using the stage1  
> compiler to link the stage2 compiler, the external one wins, but in  
> linking other programs with the stage1 compiler, the internal gmp wins.

Hmm, that's interesting. The internal GMP should only be built if
HaveLibGmp != YES and HaveFrameworkGMP != YES, in which case it should
always use the internal one, and there shouldn't be an external one to
use anyway.

> Actually, I think, we should use the gmp/ in the ghc repo by default  

If you want to use it when building a bindist that might be used on
other computers you shold be able to set
    HaveLibGmp = NO
    HaveFrameworkGMP = NO
in mk/build.mk, although I'm not sure I've ever tried it.

The disadvantages of using it are it might be out of date (we had some
Windows segfaults a while ago that were fixed by updating the in-tree
gmp) and wasted space.


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Yitzchak Gale
In reply to this post by Simon Marlow-5
I wrote:
>> Removing support for %HOME% has suddenly broken many
>> programs. If people don't like it, we can consider
>> deprecating it in some future version of GHC, but for now
>> it should put back.

Simon Marlow wrote:
> Only GHCi has changed here.  Perhaps you're under the impression that we
> recently changed the behaviour of getHomeDirectory?  In fact, it was
> introduced in GHC 6.4 and has always had the same behaviour, calling
> SHGetFolderPath on Windows.

Thanks, Simon. Yes, I was originally under that
mistaken impression, but Duncan set me straight.
I am glad that %HOMEPATH% is not being used,
though ShGetFolderPath sometimes gives the
wrong answer on Vista.

So having a customizable notion of home directory
on Windows would be a new feature for getHomeDirectory.
For GHCi it would be rescuing a recently removed one.

-Yitz
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Alex Jacobson
In reply to this post by Christian Maeder-2
I just built from source on Tiger fine.

-Alex-

Christian Maeder wrote:

> Manuel M T Chakravarty wrote:
>> Alex Jacobson:
>>> Will this also work with Tiger or do I have to upgrade?
>
> it will not work on Tiger
>
>> I don't know.  I have no box with Tiger to test.  Give it a try.  The
>> worst that can happen is that it is going to complain about some missing
>> libraries or similar.
>
> configure will crash already, because utils/pwd/pwd has been built with
> newer libs.
>
> C.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Isaac Dupree
In reply to this post by sethk
Seth Kurtzberg wrote:
> Isaac makes an important point (although I'm not sure it's
 > the point he intended to make  :)   ), there is really
 > nothing in the definition of UNIX itself that specifies
 > or requires a home directory.  It's a convention followed
 > by shells, primarily.

$HOME is a convention too prevalent to not have one in a running system,
unless you try really hard.

But I've only seen it used for two things that I remember:
- dot-files (and sometimes non-dot ones for IMHO ill-behaved programs)
as a per-user search and automatic generation location
- default location for shells (graphical file search as well as
command-line) - which IMO should be controllable by a different variable
- and '~' as a sort of synonym, I guess, even in some contexts that
don't allow arbitrary environment variable substitution?

any others?

Isaac

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: ANNOUNCE: GHC version 6.8.2

Felix Martini
In reply to this post by Duncan Coutts
On Dec 16, 2007 10:56 AM, Duncan Coutts wrote:
> Note that for data files like the .ghci file it's probably better to use
> getAppUserDataDirectory "ghci" which will return $HOME/.ghci on unix
> systems and "C:/Documents And Settings/user/Application Data/ghci" on
> Windows.

I've added a proposal and a patch to Trac
(http://hackage.haskell.org/trac/ghc/ticket/1987).

-Felix
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Manuel M T Chakravarty
In reply to this post by Manuel M T Chakravarty
I wrote,

> Ian Lynagh wrote:
>>  =============================================================
>>   The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
>>  =============================================================
>>
>> The GHC Team is pleased to announce a new patchlevel release of GHC.
>> This release contains a number of bugfixes relative to 6.8.1,  
>> including
>> some significant performance fixes, so we recommend upgrading.
>
> A binary distribution for Mac OS X 10.5 (Leopard) is available from
>
>  http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2
>
> To use this binary distribution, you need to have "readline" from  
> MacPorts installed.
>
> Manuel
>
> PS: This time around, there should be no dependency on MacPorts'  
> "gmp", but this is hard for me to test locally.

I just updated the binary distribution at

   http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2

It *definitely* does not require any version of GMP to be pre-
installed anymore.  All that is needed it MacPort's readline.

Ian, can you please update the binary on the download page?

Manuel

PS: Moreover, binaries produced by the above compiler will run on any  
Leopard box.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Manuel M T Chakravarty
In reply to this post by Ian Lynagh
Ian Lynagh:

> On Mon, Dec 17, 2007 at 12:53:32PM +1100, Manuel M T Chakravarty  
> wrote:
>>
>> It seems to be a matter of the precise ld call parameters whether the
>> gmp/ in the ghc repo is used or the external one.  In using the  
>> stage1
>> compiler to link the stage2 compiler, the external one wins, but in
>> linking other programs with the stage1 compiler, the internal gmp  
>> wins.
>
> Hmm, that's interesting. The internal GMP should only be built if
> HaveLibGmp != YES and HaveFrameworkGMP != YES, in which case it should
> always use the internal one, and there shouldn't be an external one to
> use anyway.

At least on Mac OS (and also on Windows) and probably any other  
platform, except Linux, this is IMHO the wrong policy.

FWIW, the current build system uses the internal GMP even if another  
one is installed (at least a non-framework one).  However, the  
behaviour is a bit flacky (eg, if package readline is also used, it  
uses the external GMP due to some difference between the Darwin linker  
and other Unix linkers).  It also needs to recompile installPackage  
and ifBuildable with the stage1 compiler (like the stuff below utils/)  
as both go into a binary distribution.  I have fixed this all and am  
currently validating a patch.

>> Actually, I think, we should use the gmp/ in the ghc repo by default
>
> If you want to use it when building a bindist that might be used on
> other computers you shold be able to set
>    HaveLibGmp = NO
>    HaveFrameworkGMP = NO
> in mk/build.mk, although I'm not sure I've ever tried it.
>
> The disadvantages of using it are it might be out of date (we had some
> Windows segfaults a while ago that were fixed by updating the in-tree
> gmp) and wasted space.

Sure we waste some space, but the alternative is worse.  Programs  
compiled with GHC will essentially not run on any computer, but the  
one where they were compiled.  For example, the number of Macs with  
gmp installed is minuscule.  The default should be to build programs  
that run everywhere with minimal hassle (not programs that save some  
space, but are unusable on most computers).

Manuel

PS: Readline is a different matter.  It is used by ghci, so needs to  
be installed with ghc, but this dependency does not propagate into  
compiled programs, unless a program explicitly uses package readline  
(at which point I believe it is on this program's developer to make  
sure their users have readline available).
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Judah Jacobson
In reply to this post by Christian Maeder-2
On Dec 14, 2007 1:30 AM, Christian Maeder <[hidden email]> wrote:

> Ian Lynagh wrote:
>
> > Incidentally, I suspect the otool output actually means it depends on
> > /some/ libgmp.3.dylib, and it is using one that it found in
> > /opt/local/lib/libgmp.3.dylib, but I could be wrong.
>
> The full path /opt/local/lib/libgmp.3.dylib is (somehow) stored in the
> binary, but libgmp.3.dylib will be found in any other path, too.
> Possibly the DYLD_LIBRARY_PATH has to be set for uncommon paths.
>

Today I did some digging around the source of dyld (the dynamic
loader) to understand its behavior when loading frameworks, and ended
up learning about how it loads ordinary libraries as well.  In
particular, if otool -L lists a dependency on
/opt/local/lib/libgmp.3.dylib, then the loader will look for all of
the following:

- [[dir]]/opt/local/lib/libgmp.3.dylib where [[dir]] is any entry from
the colon-separated variable $DYLD_ROOT_PATH
- /opt/local/lib/libgmp.3.dylib
- [[dir]]/libgmp.3.dylib, where [[dir]] is any entry from the
following colon-separated variables:
  - LD_LIBRARY_PATH
  - DYLD_LIBRARY_PATH
  - DYLD_FALLBACK_LIBRARY_PATH

If DYLD_FALLBACK_LIBRARY_PATH is not set in the environment, it defaults to:
"$HOME/lib:/usr/local/lib:/usr/lib"
The rest of the variables listed above default to empty.

So in conclusion, there should be no harm with linking OS X binaries
against absolute paths like /opt/local.  In fact, it might be
preferable, since it lets us support both users of MacPorts and users
who have GMP stored in a standard location.  (Of course, this doesn't
address the question of whether dynamically linking against GMP is
good to begin with.)

Best,
-Judah
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Judah Jacobson
In reply to this post by Manuel M T Chakravarty
On Dec 17, 2007 5:58 PM, Manuel M T Chakravarty <[hidden email]> wrote:

> Ian Lynagh:
> > On Mon, Dec 17, 2007 at 12:53:32PM +1100, Manuel M T Chakravarty
> > wrote:
> >
> >> Actually, I think, we should use the gmp/ in the ghc repo by default
> >
> > If you want to use it when building a bindist that might be used on
> > other computers you shold be able to set
> >    HaveLibGmp = NO
> >    HaveFrameworkGMP = NO
> > in mk/build.mk, although I'm not sure I've ever tried it.
> >
> > The disadvantages of using it are it might be out of date (we had some
> > Windows segfaults a while ago that were fixed by updating the in-tree
> > gmp) and wasted space.
>
> Sure we waste some space, but the alternative is worse.  Programs
> compiled with GHC will essentially not run on any computer, but the
> one where they were compiled.  For example, the number of Macs with
> gmp installed is minuscule.  The default should be to build programs
> that run everywhere with minimal hassle (not programs that save some
> space, but are unusable on most computers).

My understanding was that one major reason to dynamically link against
GMP is to satisfy the LGPL, not just to save disk space.  I found a
couple old but relevant posts by Wolfgang Thaller, who originally
created HaskellSupport.framework (now GMP.framework):

http://www.haskell.org/pipermail/glasgow-haskell-users/2002-June/003494.html
http://www.haskell.org/pipermail/cvs-ghc/2005-March/023769.html

The gist of those posts is the following:
- Statically linking against GMP puts extra license requirements on
any ghc-compiled program; thus, dynamic linking is preferable.
- On OS X, installing new frameworks is very easy (just drag-and-drop
the framework into ~/Library/Frameworks or /Library/Frameworks; the
former doesn't even need admin privileges).  This doesn't seem like
much to ask of users.

Best,
-Judah
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Christian Maeder-2
In reply to this post by Ian Lynagh
Ian Lynagh wrote:
> If you want to use it when building a bindist that might be used on
> other computers you shold be able to set
>     HaveLibGmp = NO
>     HaveFrameworkGMP = NO
> in mk/build.mk, although I'm not sure I've ever tried it.

I've tried it, but still all binaries had dependencies on GMP.framework.

(As non-root I don't get rid of /Library/Frameworks/GMP.framework and
maybe that's not even desirable for old binaries.)

Christian
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Simon Marlow-5
In reply to this post by Felix Martini
Felix Martini wrote:
> On Dec 16, 2007 10:56 AM, Duncan Coutts wrote:
>> Note that for data files like the .ghci file it's probably better to use
>> getAppUserDataDirectory "ghci" which will return $HOME/.ghci on unix
>> systems and "C:/Documents And Settings/user/Application Data/ghci" on
>> Windows.
>
> I've added a proposal and a patch to Trac
> (http://hackage.haskell.org/trac/ghc/ticket/1987).

I'd like to suggest a slight change to this.  Currently we put the user
package database in

   <appdata>\ghc\<arch>-<os>-<ghcversion>\package.conf

so perhaps the GHCi startup file should be

   <appdata>\ghc\ghci.cfg

To keep all the GHC-related settings together in <appdata>\ghc.

Additionally, I propose we make no changes to what happens on Unix, and no
changes to getHomeDirectory.

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Juanma Barranquero
On Dec 18, 2007 11:18 AM, Simon Marlow <[hidden email]> wrote:

> I'd like to suggest a slight change to this.  Currently we put the user
> package database in
>
>    <appdata>\ghc\<arch>-<os>-<ghcversion>\package.conf
>
> so perhaps the GHCi startup file should be
>
>    <appdata>\ghc\ghci.cfg
>
> To keep all the GHC-related settings together in <appdata>\ghc.
>
> Additionally, I propose we make no changes to what happens on Unix, and no
> changes to getHomeDirectory.

That's orthogonal to allowing %HOME to override <appdata>.

             Juanma
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC version 6.8.2

Manuel M T Chakravarty
In reply to this post by Judah Jacobson
Judah Jacobson:

> On Dec 17, 2007 5:58 PM, Manuel M T Chakravarty  
> <[hidden email]> wrote:
>> Ian Lynagh:
>>> On Mon, Dec 17, 2007 at 12:53:32PM +1100, Manuel M T Chakravarty
>>> wrote:
>>>
>>>> Actually, I think, we should use the gmp/ in the ghc repo by  
>>>> default
>>>
>>> If you want to use it when building a bindist that might be used on
>>> other computers you shold be able to set
>>>   HaveLibGmp = NO
>>>   HaveFrameworkGMP = NO
>>> in mk/build.mk, although I'm not sure I've ever tried it.
>>>
>>> The disadvantages of using it are it might be out of date (we had  
>>> some
>>> Windows segfaults a while ago that were fixed by updating the in-
>>> tree
>>> gmp) and wasted space.
>>
>> Sure we waste some space, but the alternative is worse.  Programs
>> compiled with GHC will essentially not run on any computer, but the
>> one where they were compiled.  For example, the number of Macs with
>> gmp installed is minuscule.  The default should be to build programs
>> that run everywhere with minimal hassle (not programs that save some
>> space, but are unusable on most computers).
>
> My understanding was that one major reason to dynamically link against
> GMP is to satisfy the LGPL, not just to save disk space.  I found a
> couple old but relevant posts by Wolfgang Thaller, who originally
> created HaskellSupport.framework (now GMP.framework):
>
> http://www.haskell.org/pipermail/glasgow-haskell-users/2002-June/003494.html
> http://www.haskell.org/pipermail/cvs-ghc/2005-March/023769.html
>
> The gist of those posts is the following:
> - Statically linking against GMP puts extra license requirements on
> any ghc-compiled program; thus, dynamic linking is preferable.

Dynamic linking is preferable, because it is the simplest way to  
comply with the LGLP (specifically, Section 4(d)) in a closed-source  
program.  However, it is incorrect to say that static linking leads to  
extra license requirements.  All that is required is to enable users  
to use the program with a modified version of the GMP.  There are two  
simple ways of doing that: (a) provide access to the .o files of your  
program so that they can statically link with a different version of  
the GMP or (b) to provide a version of the program linking GMP  
dynamically alongside the statically linked version.

In any case, no change of the closed-source program's licence is  
required.

Besides, it is far from clear whether the distinction between static  
and dynamic linking is legally sound: http://www.oslawblog.com/2005/01/static-linking-gpl-and-lgpl.html
>
> - On OS X, installing new frameworks is very easy (just drag-and-drop
> the framework into ~/Library/Frameworks or /Library/Frameworks; the
> former doesn't even need admin privileges).  This doesn't seem like
> much to ask of users.

I think it is.  It means, Haskell programs are more hassle to install  
than, say, C programs.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
1234