RE: Cabal and installing packages.
On 07 December 2004 09:57, Keean Schupke wrote:
Also a section like gentoo's make.conf (for ebuilds) where local options can be set in a file (for things like optimisation flags etc)...
I might be on my own here, but I happen to think that the way Gentoo encourages you to have local optimisation flag settings is complete madness. Probably the only good thing that can be said for it is that it's given the gcc developers a lot of good testing. I don't think we want to do this for Haskell, it introduces one more way for things to go wrong, and one more thing to forget in a bug report. Cheers, Simon
Simon Marlow wrote:
I might be on my own here, but I happen to think that the way Gentoo encourages you to have local optimisation flag settings is complete madness. Probably the only good thing that can be said for it is that it's given the gcc developers a lot of good testing.
I don't think we want to do this for Haskell, it introduces one more way for things to go wrong, and one more thing to forget in a bug report.
Cheers, Simon
I think you dont want to make advanced features too easy to use... (on the other hand automatic error reporting can gather all the relavent system info into an email - and you can have a safe compile mode that ignores local settings). I was thinking it may be nice to have a standard way for installers to store installer specific data with each Cabal package... maybe a window style init file, that can be used for example to disable certain features... [gentoo] EXCLUDE_FLAGS=-O2 DEBUG_EMAIL=developer@haskell.org Keean.
On Tue, 2004-12-07 at 10:15 +0000, Simon Marlow wrote:
On 07 December 2004 09:57, Keean Schupke wrote:
Also a section like gentoo's make.conf (for ebuilds) where local options can be set in a file (for things like optimisation flags etc)...
I might be on my own here, but I happen to think that the way Gentoo encourages you to have local optimisation flag settings is complete madness. Probably the only good thing that can be said for it is that it's given the gcc developers a lot of good testing.
I don't think we want to do this for Haskell, it introduces one more way for things to go wrong, and one more thing to forget in a bug report.
Yes, it's been common in gentoo land in recent years for ebuilds to ignore the user supplied CFLAGS entirely or strip out certain flags to stop people from shooting themselves in the foot. Unlike for C, for Haskell compilers there are fewer interesting optimisation or platform specific flags (think -O?, -march=???, -fbe-really-sloppy-with-floating-point etc etc). This is a good thing since there is less desire to fiddle. I agree, for our various Haskell ebuilds we do not provide any easy way for users to override HCFLAGS. Duncan
Duncan Coutts wrote:
Yes, it's been common in gentoo land in recent years for ebuilds toignore the user supplied CFLAGS entirely or strip out certain flags to
stop people from shooting themselves in the foot.
Unlike for C, for Haskell compilers there are fewer interesting optimisation or platform specific flags (think -O?, -march=???, -fbe-really-sloppy-with-floating-point etc etc). This is a good thing since there is less desire to fiddle.
I agree, for our various Haskell ebuilds we do not provide any easy way for users to override HCFLAGS.
As someone who nearly always uses -fvia-C, I find there are just as many nifty performance enhancing flags usable for example: -O2 -fvia-C -ffast-math -mfpmath=sse,387 -fomit-frame-pointer -fexpensive-optimizations Keean.
participants (3)
-
Duncan Coutts -
Keean Schupke -
Simon Marlow