On 09 December 2005 19:50, Isaac Jones wrote:

"Simon Marlow" 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