[Haskell-cafe] Cabal, lib and exe in one

[R Hayes]

I think Simon is right, and not just from a Haskell point of view.   
Allowing a package to contain a both a library and an executable  
makes the behavior of the package system less obvious.  That's not to  
say that it can't behave "correctly", but that it can't behave both  
"correctly" and in a way that is easy to understand.  Yes, it makes  
installation of an executable package more complicated if you have to  
install its library package as well.  But making this simple should  
be handled by a layer above the cabal package files (Hackage?).

In my experience, the best packaging systems  distinguish between  
dependency assurance and dependency satisfaction.  For example, the  
Debian packaging system has two layers.  dpkg deals with package  
files, installing a single package, and assuring that dependencies  
are met prior to installation.  apt-get retrieves packages from  
repositories with their pre-reqs (based on the dependency) and  
invokes dpkg on the retrieved packages.  I know the problem is not  
identical to the one cabal is trying to solve, but I think there is a  
great deal to be learned by looking at the Debian packaging system  
and its conventions.

In any event, solid naming conventions could go a long way to making  
this obvious.  If foo has a useful exposed library, but primarily  
consists of an executable, dividing it into foo-bin and foo-lib could  
serve to clarify.  I would propose that, since the bulk of existing  
packages seem to be libraries, we use a naming convention to  
distinguish packages that build executables and leave the names of  
library packages unannotated.

-r

On May 2, 2007, at 2:08 AM, Simon Marlow wrote:

> Duncan Coutts wrote:
>> On Tue, 2007-05-01 at 22:29 +0100, Magnus Therning wrote:
>>>> So if foo.hs is in test-src and Foo/Bar.hs is in src then I  
>>>> think you
>>>> just need:
>>>>
>>>> hs-source-dirs: test-src, src
>>> No, that's not enough, I also have to add the following lines to  
>>> make
>>> the executable compile and link:
>>>
>>>   extensions: ForeignFunctionInterface
>>>   c-sources: csrc/ptrace.c
>>>
>>> That is, I end up compiling the library a second time!  Can't I  
>>> get the
>>> executable to link against the library that was just created?
>>> I was just expecting to not have to repeat myself in the cabal file.
>>> Not such a strange thing to expect from a build system, I think :-)
>> Yes this is an interesting question about what it means to have  
>> programs
>> in the same cabal package as an executable.
>> Currently having a executable and a library inside a cabal package is
>> not the same thing as having a library package and separate  
>> package that
>> contains only that executable. The difference is that when the
>> executable is in the same cabal package it merely has access to  
>> the same
>> modules, it doesn't 'depend' on that library package exactly. So for
>> example it can access modules which are not exposed by the library  
>> and
>> indeed it can compile those same modules with completely different  
>> build
>> flags. So currently those modules will be built twice.
>> It's not clear to me that this is the right meaning, or indeed  
>> that we
>> should allow multiple entries in a single .cabal file. I think it  
>> might
>> be better to just have multiple .cabal files (possibly in the same
>> directory). Then we could be explicit and state that an executable
>> depends on the library or if we want to use different build flags, or
>> use modules that are not exposed by the lib then we can do that  
>> and only
>> in that case do we build those modules twice.
>
> Right at the front of the Cabal docs it says:
>
> "However having both a library and executables in a package does  
> not work very well; if the executables depend on the library, they  
> must explicitly list all the modules they directly or indirectly  
> import from that library."
>
> IMO we shouldn't allow both a library and an exe in the same  
> package.  I think I argued against this originally, and my  
> understanding is that doing this is deprecated, although perhaps  
> not visibly enough.  Whenever the question of what to do about lib 
> +exe packages arises, the discussion tends to spiral out of control  
> into what we should do about collections of packages in general.
>
> For now, the simple story is that each package should have either a  
> single library or a single executable (even multiple executables in  
> a package is questionable; if they share some code it shoud be in a  
> package).
>
> Cheers,
> 	Simon
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe