Hi
Nice theory, but this doesn't work at all in practice: The majority of the
packages mentioned so far are not purely Haskell, so one needs tons of
development tools and C libraries, headers, etc. (all in a consistent state,
of course) to compile those packages, which is a bit tricky on *nices
Am Mittwoch, 23. August 2006 15:23 schrieb Bulat Ziganshin:
> [...]
> i think that better way is to supply non-core libs in source form and
> just recompile them in this case. so, [...]
Nice theory, but this doesn't work at all in practice: The majority of the
packages mentioned so far are not pu
Hello Neil,
Tuesday, August 22, 2006, 5:04:58 PM, you wrote:
> Just for reference, I did this with WinHugs, I created WinHugs and
> MinHugs - with the explicit goal that a student at a uni should be
> able to install MinHugs on their disk space without blowing their
> quota. The difference was ab
Hello Krasimir,
Friday, August 25, 2006, 10:49:50 AM, you wrote:
> The usage of something else than cabarc isn't supported directly and
> will require extra work. Is the lzma algorithm better than bz2? If I
for compression of binary data (and most of windows distribution is
executable), lzma is
The usage of something else than cabarc isn't supported directly and
will require extra work. Is the lzma algorithm better than bz2? If I
have to use something better than cabarc I would prefer more popular
compression algorithm. For Visual Haskell the Nullsoft installer isn't
an option because it
Currently the tool is general enough to be used with Hugs or any other
project. You just need to have a prepared (template) MSI database and
the tool will add your files to it. What I tend to add is a special
mode where the tool will read your .cabal file and will automatically
detect which files
Hello Krasimir,
Thursday, August 24, 2006, 6:15:17 PM, you wrote:
> I wrote simple tool that I am using to build MSI installer for Visual
> Haskell. It will not be so hard to extend it to support Cabal. After
> that it will be easy to prepare an installer for GHC with optional
> libraries. Don't
Hi Karsmir,
I wrote simple tool that I am using to build MSI installer for Visual
Haskell. It will not be so hard to extend it to support Cabal. After
that it will be easy to prepare an installer for GHC with optional
libraries. Don't expect it to be ready for 6.6 release!
Would it be possible
I wrote simple tool that I am using to build MSI installer for Visual
Haskell. It will not be so hard to extend it to support Cabal. After
that it will be easy to prepare an installer for GHC with optional
libraries. Don't expect it to be ready for 6.6 release!
Cheers,
Krasimir
On 8/22/06, Jas
On Thu, Aug 24, 2006 at 12:22:05PM +0100, Simon Marlow wrote:
> Bulat Ziganshin wrote:
> >at least we can start by removing from ghc distribution large
> >graphics/sound libraries that was already cabalized. are there such
> >beasts?
>
> All those packages are already Cabalized. Hugs uses Cabal t
Bulat Ziganshin wrote:
Hello Simon,
Thursday, August 24, 2006, 2:40:55 PM, you wrote:
This means that making a minimal distribution in a build tree that has
everything is not just a matter of removing stuff, also the Haddock
index must be rebuilt, and the package database needs to have the ex
Hello Simon,
Thursday, August 24, 2006, 2:40:55 PM, you wrote:
> This means that making a minimal distribution in a build tree that has
> everything is not just a matter of removing stuff, also the Haddock
> index must be rebuilt, and the package database needs to have the extra
> packages remove
On 24 August 2006 11:20, Henning Thielemann wrote:
> On Tue, 22 Aug 2006, Simon Marlow wrote:
>
>> - A source tree can optionally be populated with more packages,
>>which will be included in the build as normal. At the moment,
>>the only packages you can add in this way are:
>>
>>
Simon Marlow wrote:
On 23 August 2006 14:27, Chris Kuklewicz wrote:
I need to add some build system stuff for GHC: Makefile,
package.conf.in, and possibly configure.ac. Instead of the fps
dependency, there will be a base>=2.0 dependency (ideally we would
have conditional dependencies, but Caba
On 23 August 2006 14:27, Chris Kuklewicz wrote:
>> I need to add some build system stuff for GHC: Makefile,
>> package.conf.in, and possibly configure.ac. Instead of the fps
>> dependency, there will be a base>=2.0 dependency (ideally we would
>> have conditional dependencies, but Cabal support f
Hi Bulat,
sorry, but you miscitated me and seems to misinterpret whole idea:
Sorry about that. I put the emphasis on your mention of
"fundamental," almost to the exclusion of compiler-builds. My point
was that there are two design considerations when you are designing a
compiler system
Hello Simon,
Wednesday, August 23, 2006, 2:26:56 PM, you wrote:
> Just replacing GHC without upgrading libraries (or RTS) should be possible
imho this is not very useful. typically, bug fixes are spread over
compiler, rts and libraries, so upgrading only compiler seems very
strange idea and upgr
I need to add some build system stuff for GHC: Makefile,
package.conf.in, and possibly configure.ac. Instead of the fps
dependency, there will be a base>=2.0 dependency (ideally we would have
conditional dependencies, but Cabal support for that isn't ready yet).
I don't have GHC past 6.4.
Simon Marlow wrote:
If the base package is upgraded without also replacing the other
libraries... this is where it gets really tricky. Binary
dependencies between library code tend to be very deep due to
cross-module inlining and optimisations, so right now the chances of
upgrading base without
Chris Kuklewicz wrote:
Simon Marlow wrote:
Chris Kuklewicz wrote:
Simon Marlow wrote:
> Here is what I propose to do regarding the libraries we ship with GHC
> 6.6. Comments are appreciated, since we need to finalise this story
> before the release candidate at the end of this week.
>
Simon Marlow wrote:
Chris Kuklewicz wrote:
Simon Marlow wrote:
> Here is what I propose to do regarding the libraries we ship with GHC
> 6.6. Comments are appreciated, since we need to finalise this story
> before the release candidate at the end of this week.
>
I have a small comment...
Chris Kuklewicz wrote:
Simon Marlow wrote:
> Here is what I propose to do regarding the libraries we ship with GHC
> 6.6. Comments are appreciated, since we need to finalise this story
> before the release candidate at the end of this week.
>
I have a small comment...
> So here's what I
Bulat Ziganshin wrote:
on the other side, when we upgrade ghc itself, it should
be possible to leave versions of these libraries that are already
installed
Now *that* is the tricky part. It's something I believe is important and I'd
like to see GHC support this in the future.
Just replacin
Bulat Ziganshin wrote:
one interesting question you not mentioned - whether it will be
possible to include in GHC bundles non-BSD licensed libs and tools.
although it seems more on behalf of packagers, it's still interesting
to discuss here. one thing that i definitely will be glad to see is
Mis
Bulat Ziganshin <[EMAIL PROTECTED]> writes:
> 1. Simon suggests that there is a core GHC distribution. it should be
> GHC _compiler_ itself and contains only libraries whose implementation
> are closely tied to compiler version [...]
> 2. For windows-like OSes where users prefer to see larger mon
Hello Peter,
Wednesday, August 23, 2006, 10:00:00 AM, you wrote:
>>>... At the moment,
>>>the only packages you can add in this way are:
>>>
>>> ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi,
>>> fgl, haskell-src, html, mtl, network, parsec, time, xhtml
>>
>> ... inste
Simon,
... At the moment,
the only packages you can add in this way are:
ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi,
fgl, haskell-src, html, mtl, network, parsec, time, xhtml
... instead include smaller and more "fundamental"
packages: ByteString, regexps, Collect
Hello Simon,
one interesting question you not mentioned - whether it will be
possible to include in GHC bundles non-BSD licensed libs and tools.
although it seems more on behalf of packagers, it's still interesting
to discuss here. one thing that i definitely will be glad to see is
MissingH librar
Simon Marlow wrote:
> Here is what I propose to do regarding the libraries we ship with GHC
> 6.6. Comments are appreciated, since we need to finalise this story
> before the release candidate at the end of this week.
>
I have a small comment...
> So here's what I propose:
>
> - A "GHC source
Hello Brian,
Tuesday, August 22, 2006, 6:26:02 PM, you wrote:
>> the idea is not "what we all use", but "what a required to build ghc
>> itself, or closely depend on ghc version". i instead may propose to
>> remove unix/win32 here - i guess that these packages are rather
>> independent on GHC ver
Bulat Ziganshin wrote:
Hello Brian,
Tuesday, August 22, 2006, 5:52:29 PM, you wrote:
"sh darcs-all get" in a darcs repo. The core packages are:
base, haskell98, template-haskell, readline, stm,
Cabal, unix, Win32
Should mtl not also be included here too as it is a relative
Hello Brian,
Tuesday, August 22, 2006, 5:52:29 PM, you wrote:
>>"sh darcs-all get" in a darcs repo. The core packages are:
>>
>> base, haskell98, template-haskell, readline, stm,
>> Cabal, unix, Win32
>>
> Should mtl not also be included here too as it is a relatively small pack
Simon Marlow wrote:
So here's what I propose:
- A "GHC source tree" will contain a core set of packages. This is
what you will get if you download ghc-6.6-src.tar.bz2, or do
"sh darcs-all get" in a darcs repo. The core packages are:
base, haskell98, template-haskell, readline, st
Hi
i think that inclusion of large packages in installer - independent of
how great they are - is a wrong decision.
Just for reference, I did this with WinHugs, I created WinHugs and
MinHugs - with the explicit goal that a student at a uni should be
able to install MinHugs on their disk space
Hello Simon,
Tuesday, August 22, 2006, 2:11:46 PM, you wrote:
> - A source tree can optionally be populated with more packages,
>which will be included in the build as normal. At the moment,
>the only packages you can add in this way are:
>
> ALUT, HGL, HUnit, OpenAL, OpenGL, Qu
Here is what I propose to do regarding the libraries we ship with GHC
6.6. Comments are appreciated, since we need to finalise this story
before the release candidate at the end of this week.
For a while we have had the goal of devolving as many of the libraries
that ship with GHC as possible. W
36 matches
Mail list logo
