- Libraries - Haskell.org

RE: cabal release (was: cabal experiences)
by Simon Marlow 13 Dec '05

13 Dec '05

On 13 December 2005 02:33, John Meacham wrote: > On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote: >> On Mon, 2005-12-12 at 14:46 +0000, Simon Peyton-Jones wrote: >>> If the reason you want 6.6 is to get a new Cabal, why not download a >>> new Cabal package? Or is there another reason you want 6.6? >> >> That is exactly the problem. All non-trivial packages need a later >> version of Cabal since there are many many minor bug fixes and little >> feature additions in later versions of Cabal. > > This is a large part of the reason I'd like to see cabal as a > completly separate package from any compiler with a programatic > interface rather than a library one. things will get very complicated > when there are multiple major compilers and you have to tell users > things like 'run runhaskell Setup.lhs, unless your runhaskell points > to jhc, in which case do runghc Setup.lhs, oh, create a link from > runhaskell to your proper compiler'. > > We can do so without losing any flexability at all. just add a new > line to the cabal file > > build-style: (makelike|simple|custom) > > where makelike and simple just call the current cabal library routines > and custom lets you specify a command that should be run and arguments > passsed to it. (which can be something like 'runhaskell Setup.lhs') One usage of Setup.lhs that is becoming more common is to extend the simple build system in small ways using hooks. How do you envisage that working with your scheme? It looks like we would need to use "custom", but we're back to needing a to provide the build system as a library, otherwise every package needs to supply its own complete build system. I don't immediately see how this solves the problem, but perhaps I'm missing something. I'm not against eliminating Setup.lhs in the (common) case when it is just boilerplate. But we need to retain the ability to customise the simple build system, because it's both powerful and necessary. Cheers, Simon

1 0

Bugs in Graphics.HGL.Window and its documentation
by Kevin Van Horn 13 Dec '05

13 Dec '05

The function openWindowEx seems to ignore its second argument (optional initial position of window). Here is the test program to illustrate this, which I ran on Mac OS X (Tiger), using hugs: --- begin program --- import Graphics.HGL main = runGraphics $ do win <- openWindowEx "Test" (Just (200, 300)) (300, 300) Unbuffered Nothing ((x,y), (w,h)) <- getWindowRect win setGraphic win (text (100,100) (show (x,y) ++ " " ++ show (w,h))) getKey win closeWindow win --- end program --- Also, the documentation for the type RedrawMode (http:// www.haskell.org/ghc/docs/latest/html/libraries/HGL/Graphics-HGL- Window.html) seems to have the constructors Buffered and Unbuffered reversed.

3 2

RE: cabal release (was: cabal experiences)
by Simon Peyton-Jones 12 Dec '05

12 Dec '05

Why is it easier to get users to upgrade from GHC 6.4.1 to GHC 6.6 than it is to upgrade from Cabal 1.0 to Cabal 1.7 (say)? I must be missing something. S | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Duncan | Coutts | Sent: 12 December 2005 15:14 | To: Simon Peyton-Jones | Cc: libraries(a)haskell.org; Isaac Jones | Subject: RE: cabal release (was: cabal experiences) | | On Mon, 2005-12-12 at 14:46 +0000, Simon Peyton-Jones wrote: | > If the reason you want 6.6 is to get a new Cabal, why not download a | > new Cabal package? Or is there another reason you want 6.6? | | That is exactly the problem. All non-trivial packages need a later | version of Cabal since there are many many minor bug fixes and little | feature additions in later versions of Cabal. | | So it's fine for package developers to download a later Cabal version | but the sense some people have is that they can't ask their users to | upgrade their Cabal installation from the one that comes with GHC. | | > Bug-fixes to 6.4 are a much smaller deal. | | The improvements are a mixture of bug fixes and feature additions and | some api changes. So because of the policy for minor versions of GHC is | to not change any apis including those of Cabal, GHC 6.4.1 came with a | version of Cabal that is widely acknowledged to be buggy and unsuitable | for many packages and distributors. We can sometimes persuade users to | upgrade their Cabal package separately from their GHC installation, but | not always. | | In Gentoo we made a decision to ship Cabal-1.1.3 with GHC 6.4.1. That is | after installing GHC 6.4.1 we unregister Cabal-1.0 and install | Cabal-1.1.3. We do not allow any choice in that. This was necessary | because our build/distribution infrastructure could not work around the | bugs in Cabal-1.0 and besides many packages that we want to distribute | require later versions of Cabal. So Gentoo users are ok, but other users | are not. | | So this is why there is pressure in some quarters for a major release, | (6.6) rather than another minor release (6.4.2) since the former would | allow package authors to support a released version of GHC because it | would come with a usable version of Cabal. A minor release with the same | Cabal-1.0 would leave people in the same situation as now. | | I appreciate that we do not want to rush the next major release because | there are new features that need to be got right. Perhaps we should | think again about which Cabal version to include in the next GHC minor | version, or perhaps to advise users in the release notes for GHC 6.4.2 | that it is highly recommended to upgrade to Cabal version x.y. | | Perhaps another compromise would be for GHC 6.4.2 to ship more than one | version of Cabal. It could ship version 1.0 and have that exposed by | default so that GHC's api stability guarantees could be met and it could | also ship a more recent version that we can agree upon so that it would | be much less difficult for the average user to build packages that | require more recent Cabal versions. | | Duncan | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

2 1

RE: Shipments in Cabal
by Simon Marlow 12 Dec '05

12 Dec '05

On 09 December 2005 19:50, Isaac Jones wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> I just made some changes to my proposal: >> >> http://haskell.org/hawiki/Cabal_2fAggregatePackages >> >> Mainly I made it so that the sub-packages don't have to be in a >> subdirectory, this means it will be easier to tar up the aggregate >> package. > > Can you clarify the terminology a bit? A distro package is an OS > package? Like RPM? Yes. > And a distributable is a kind of meta-package > that does nothing but depend on other packages? (If so, let's call it > a meta-package or something). No, by "distrutable" I meant a source distribution, i.e. whatever it is you grab from Hackage. > I like the idea of having a meta package that can be only > dependencies, but I don't think I really like the --local idea. I > don't really like the idea of one cabal package going to build another > package, invoking another setup script. I think that should be left > for layered tools. That's a shame, I thought it was quite cool :-( But I see your point. It seems slightly strange to be able to build *one* package using Setup.lhs, but as soon as I need to split my package into two I have to use some other tool to work on it. Not a big deal though. > Although I'm all for adding flags to cabal to allow packages to be > used in-place more effectively, I'd rather have a tool where I can > say: > > cabal-install: metapackage/metapackage.cabal --searchpath=. > > and maybe > > cabal-sdist metapackage/metapackage.cabal --searchpath=. > > will go and build .tar.gz files for everything it can find. That way > hackage won't have to change, it still works on the cabal-package > level. Ok, but remember we're only solving a problem that occurs for developers here. Users don't need to know about search paths - they just need to install a package and its dependencies. A developer, on the other hand, needs to be able to rebuild a set of packages in dependency order, without building everything each time. That is, the tool needs a way to ask for a rebuild, not just a full configure/build/install. And specifying the .cabal file for the metapackage isn't really enough: you should really go through the Setup.lhs script (it might have some optional dependencies, for example). > Incidentally, we would need to separate the concept of depends and > build-depends again, I guess. Remember that all build-depends cause > -package flags to be added to the command line of GHC. If these > dependencies are executables, then that's bad. Ok, I'm agnostic about depends. > Krasimir, would meta-packages and cabal-install solve the problems w/ > visual studio? We could add flags to cabal to improve in-place usage, > and to do something w/ a particular packageDB (though I want to figure > out a way to solve this for Hugs too). In-place usage is the main thing. If we can agree on --packagedb that's a step forward (simulating it with symlinks for Hugs?). This is the level that VS will hook into. Then as long as we have a way to build a set of packages in dependency order, without rebuilding everything each time, installing to a temporary location, I think the non-VS developer's needs will be met too. [snip] Cheers, Simon

1 0

RE: About cabal and compatibility
by Simon Marlow 12 Dec '05

12 Dec '05

On 11 December 2005 01:46, Isaac Jones wrote: > Robert Dockins <robdockins(a)fastmail.fm> writes: >> createVersionModule :: Version -> IO () >> createVersionModule version = do >> h <- openFile "src/Version.hs" WriteMode >> hPutStr h "module Version where\n" >> hPutStr h ("version = \""++(showVersion version)++"\"") >> hClose h > > That's interesting. I was recently thinking of generating something > like CabalInfo.hs which has information like the PackageDescription > and the LocalBuildInfo. You would turn on this feature w/ the .cabal > file. I'm not sure if any of the information is useful except for the > version number, though. This isn't necessary: you can get the version number from Paths_<pkg> (it's an undocumented feature :-). See the Cabalised Happy for an example. I should probably document it. Cheers, Simon

1 0

RE: About cabal and compatibility
by Simon Marlow 12 Dec '05

12 Dec '05

On 11 December 2005 00:38, Robert Dockins wrote: > The thing that got me thinking about it was Happy. Its recently been > put in a darcs, and Simon Marlow mentioned to me that they are > looking at moving to Cabal for the build system. > > The Happy build system now does two things that aren't your standard > build actions: > > 1) It creates module which contains the version string before > compilation 2) After compilation it runs CPP on a number of template > files with various different "-D" options to genreate the parser > templates. BTW, I recently Cabalised Happy. Get it from the darcs repo: darcs get http://darcs.haskell.org/happy Sorry you duplicated this work, I should have announced something, but I was holding off because it needed a very recent version of Cabal. Cheers, Simon

1 0

RE: About cabal and compatibility [Was: simplifying user hooks(non-backward-compatible)]
by Simon Marlow 12 Dec '05

12 Dec '05

On 10 December 2005 23:27, Robert Dockins wrote: > I just want to mention that these kind of changes represent represent > a VERY big problem. I agree, this is indeed a big problem. I've mentioned it before, albeit only briefly, and we didn't reach a conclusion. As you say, Cabal solves (for some value of solve) the versioning problem for everything except the Setup.lhs script itself. In the Setup.lhs script we have absolutely no way to request a particular version of the Cabal library, and even if you have the right version installed, it might not be the one used by default, so you're screwed ("runghc -package Cabal-1.0 Setup.lhs" doesn't work, and even if it did this would be a poor solution). The cabal-version field is only a partial solution - it doesn't help if the Cabal API changes such that your Setup.lhs script breaks. I support doing some explicit interface versioning along the lines of EternalCompatibiliyInTheory, but only for Cabal. It's extra work, but it's necessary if we want to be taken seriously. Cheers, Simon

1 0

cabal experiences
by Ian Lynagh 11 Dec '05

11 Dec '05

Hi all, Here are the issues I ran into while cabalising some stuff recently. It's possible that some of the problems are just me failing to find the right option. * No way to get extra files into the source tarball. * No way to specify extra clean files. * No way to specify extra object files to be put into a library. * With "defaultMainWithHooks defaultUserHooks" clean is not removing config.log, config.status. Hmm, the dist/ directory doesn't seem to be being removed either. * Again with "defaultMainWithHooks defaultUserHooks", sdist doesn't copy configure, * "runghc6 Setup.hs sdist" without configuring tells me to run "setup configure", but wouldn't that restrict me to a particular compiler? (the same applies to clean, although it's not as critical there). * I'm not sure why all cc-options can't be passed to hsc2hs with -C-optc (and likewise ld-options and -L-optl). * I think -threaded should be an extension. Thanks Ian

4 6

RE: Shipments in Cabal
by Simon Marlow 09 Dec '05

09 Dec '05

I just made some changes to my proposal: http://haskell.org/hawiki/Cabal_2fAggregatePackages Mainly I made it so that the sub-packages don't have to be in a subdirectory, this means it will be easier to tar up the aggregate package. On 09 December 2005 14:19, Krasimir Angelov wrote: > For the end user the presence of shipment isn't important. [snip] > The shipment is more important for the developer. yes, exactly what I said! [snip] > I will be lucky with Simon's proposal too. It will allow to build > automatically all packages but I think that it is more complicated. At > least everything that have to be added to Cabal for this proposal will > be required in my proposal too. The aggregate package description is > in fact just a replacement for the shipment description which Isaac > proposed. the point is that an aggregate package is just a package; we don't need a separate concept for it. > I don't think that it is required to have a separate description. The problem with putting all the .cabal files in a single place is that you then have to distribute the whole set of packages together; and it becomes some kind of larger entity for which we need a name ("shipment"). Shipments will be visible at the Hackage level, because Hackage will have to know the set of packages contained in a shipment. I don't think we need to do this. All that is needed is an empty package that depends on all the others. Hackage doesn't need to learn anything new, neither do the other tools. > I have to write an another aggregate package. Will it be distributed > separatelly in Hackage? Yes - but that's exactly how other package systems work. It's flexible and simple. Cheers, Simon

2 1

RE: Shipments in Cabal
by Simon Marlow 09 Dec '05

09 Dec '05

This message got garbled a bit by my mailer. It's easier to read on the wiki: http://haskell.org/hawiki/Cabal_2fAggregatePackages Cheers, Simon On 09 December 2005 11:07, Simon Marlow wrote: > I've read the thread, and I must admit I've been thinking along the > same lines as Duncan. We don't need shipments. The problem is > purely with developing aggregate packages, which we can solve with > either tools or small additions to Cabal. (sorry, I intended this to > be a short message, but it's turned out rather long :-/) > > I don't propose to change much, in fact I want to make the situation > simpler: > > Cabal package > == one library or one executable > == one distro package > == one distributable > > To aggregate packages, just create another package which contains only > dependencies. This is how many distro packaging systems aggregate eg. > all the KDE components into a single KDE package. > > 1. End users: they are served by this just fine. They just > cabal-install > the top-level package, and all the dependencies are magically > downloaded and installed. Or they use their distro's packaging > system > to do the same thing. Dependencies between libraries are > maintained correctly. > > 2. Developers. A developer working on an aggregate package needs to > be able to edit & rebuild an aggregate package without rebuilding > everything every time. This is the scenario I believe we should > solve > with a few small additions to Cabal (see below). > > 3. Visual studio. VS has solutions, which are containers for multiple > packages, but the problem is that it doesn't want to *install* each > package as it builds, but it somehow needs to make each package > available to the others when building a chain of dependencies. > Again, > this is solved by the same small additions to Cabal. > > > As a developer, here is how I'd like to work on an aggregate package. > Suppose I have three packages mylib, myexe1, myexe2. I aggregate > these using a package bigpkg. I then arrange my tree like this: > > .../bigpkg/ > Setup.lhs > bigpkg.cabal -- build-depends: mylib, myexe1, myexe2 > mylib/ > Setup.lhs > mylib.cabal > src/ > myexe1/ > Setup.lhs > myexe1.cabal -- build-depends: mylib > src/ > myexe2/ > Setup.lhs > myexe2.cabal -- build-depends: mylib > src/ > > and I want to work on the whole blob like this: > > $ cd .../bigpkg > $ runghc Setup.lhs configure --local > $ runghc Setup.lhs build > > what does --local do? (we can choose a better name, incedentally): > > - it implies > --local-deps > --prefix=`pwd`/install > --packagedb=`pwd`/install/package.conf > > what does --local-deps do? > > - "configure" looks for dependencies in subdirectories of `pwd` > > - "configure" configures recursively. It passes > --prefix and other settings to each subdir > > - "build" command recursively builds dependencies that > are found in subdirectories, in dependency order. After building > each library dependency, it runs "setup install" in that subdir. > > - other commands just operate recursively. > > what does --packagedb do? > > - specifies a package database into which packages are registered > by "setup register" and "setup install" > > - you probably want to set GHC_PACKAGE_PATH too > > > -=-=- Summary -=-=- > > - Add --packagedb flag to Cabal. This just adds a -package-conf > to each invocation of GHC and ghc-pkg. > > - Add --local-deps flag to "setup configure" in the simple build > sysetm, which looks for dependencies in subdirectories, and causes > other setup commands to recurse into dependencies in the right > order. > > - Add --local flag which is just a macro > > > Pretty simple to implement, and does everything we want, I think. > > Visual Studio would do things slightly differently, but I believe > these facilities provide everything VS needs from Cabal. > > Incedentally, I want --local for converting GHC's libraries to Cabal. > We need to build & use directly from the build tree, which is what > --local does. > > Cheers, > Simon > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

2 1