"Jeremy Shaw"
At Thu, 13 Jul 2006 12:26:22 +0100, Simon Marlow wrote:
Jeremy Shaw wrote:
(1) Flag sanity checking
Not all combinations of flags are sensible. For example, we can already specify:
There's another restriction I know of: if the code uses Template Haskell, then --enable-library-vanilla will always be required. Since the extensions used are all listed in the .cabal file, checking this will be easy.
Hrm, that puts me back in the same situation I am in now -- not having a good way to split the profiling libraries into a separate package.
I have written up some of my thoughts below. I would love to hear opinions from any interested parties, such as compiler writers, package maintainers, end users, etc.
Goals =====
Overall Goal ------------
My overall goal is to add some flags to Cabal that will make it easier for package maintainers to provide several variations of the same library in separate packages. For example, separate packages for the library compiled: vanilla, profiling, smp, bytecode, etc. If a package (such as the profiling) needs files that are already in another package (such as vanilla), it will simply depend on the other package. (i.e. it will *not* contain a second copy of the files)
I like the overall goal, and totally understand the need for it. (snip)
Cabal is nice because it hides all the nasty compiler and platform specific build issues from the user. The user puts *what* they want in the .cabal file, and they let Cabal take care of the *how*.
I think it is very desirable to retain this abstraction in the configure flags as much as possible. To me, this means that the flags:
--disable-library-vanilla --enable-library-profiling
Maybe we should think about having a concept of 'ways' instead of these more one-off flags. --ways=prof,novanilla etc? (snip)
Difficulties ------------
It is difficult to make a specification that all compilers can meet. For example, most compilers do not support profiling, so they can not support the --enable-*-profiling flag at the moment. In this case, we could just extend the spec to say that it is an error to enable profiling for a compiler that does not support profiling.
Building a concept of 'ways' can let the compiler authors say "We support the profiling 'way' but not the bytecode 'way'." Instead of "we support flags xyz".
On the other hand, someone might make a compiler that does not allow you to install the vanilla and profiling libraries at the same time. Now you have the problem that you do want to have a -prof .deb, but it is going to work different from the 'standard'.
Of course, the specifications are supposedly reasonable specifications that are dictated by the actual needs of the users and the package maintainers. So, I think in most cases, having a specification to meet will make it easier for compiler writers, since they will not have to learn the hard way that certain features are important.
Can you document the requirements and assumptions that we make of the compilers? For instance, as cabal hackers who have actually spent time thinking about this, we can tell the yhc and ghc people, "it would be way better if you please do things this way" and they can conform. That is, we can ask the yhc authors to please make sure that when they implement profiling, they make sure that profiling libraries can be installed alongside non-prof libraries. While cabal does its best to change its behavior based on implementations, there's a lot of give-and-take. For instance, GHC added the --hide-all-packages flag for us. So I'm agreeing with you ;) (snip)
How It Would Work In Cabal --------------------------
The spec for the flags:
--maintainer --disable-library-vanilla --enable-library-profiling
is something like,
+ build the libraries with profiling enabled
+ copy out just the files needed add profiling support to a system that already has the vanilla libraries available
+ this assumes that the profiling and vanilla libraries can co-exist (i.e. do not have conflicting files, etc)
Here is how the Cabal code for GHC would meet that spec:
(1) In the 'build' phase:
(i) if ghc requires you to explicitly build the vanilla libraries before building the profiling libraries, then do that.
(ii) build the profiling libraries
(2) In the 'install/copy' phase, *only* copy the profiling libraries out.
(NOTE: This is actually quite easy -- I have already implemented it in Cabal).
This makes sense, but what does the 'maintainer' flag do in this case?
Downside Of This Solution -------------------------
The downside of the above implementation is that the vanilla libraries will be built twice. Once for installation in the -vanilla package, and a second time when trying to create the -prof package.
Couldn't cabal notice that they're already built?
Your Comments Here ==================
This is very good and thoughtful work! Thanks for hacking on this and working to gather input. Folks like you & Duncan, who package Haskell libraries, are indispensable to the Cabal effort. peace, isaac