Maurí­cio CA | 12 Nov 21:32
Picon

Weird dependency failure log

Hi, all,

Hackage shows a log failure for 'bindings-gsl':

     Configuring bindings-gsl-0.1.1...
     cabal-setup: At least the following dependencies are missing:
     bindings-DSL ==1.0.*

But here is, at version 1.0.1, no building problems:

     http://hackage.haskell.org/package/bindings-DSL

There's one thing special about bindings-DSL. It's
a package with a set of macros for hsc2hs, and contains
no Haskell code. Maybe this revealed some hidden error
in package dependency checking.

Thanks,
Maurício
Ross Paterson | 13 Nov 13:48
Picon
Favicon

Re: Weird dependency failure log


On Thu, Nov 12, 2009 at 06:32:48PM -0200, Maurí­cio CA wrote: > There's one thing special about bindings-DSL. It's > a package with a set of macros for hsc2hs, and contains > no Haskell code. Maybe this revealed some hidden error > in package dependency checking.
This is a package with no library and no executables. That's not supposed to work.
Maurí­cio CA | 13 Nov 15:08
Picon

Re: Weird dependency failure log


>> There's one thing special about bindings-DSL. It's >> a package with a set of macros for hsc2hs, and contains >> no Haskell code. Maybe this revealed some hidden error >> in package dependency checking. > > This is a package with no library and no executables. > That's not supposed to work.
It contains hsc2hs data all dependent packages use. Why shouldn't this be supposed to work? It does install needed files (two include files for hsc2hs), and they do stand for themselves to justify a package of its own. And other packages could also want to distribute just data. Say, a database of daytime saving dates to be used by a clock package. Thanks, Maurício
Duncan Coutts | 13 Nov 17:42

Re: Re: Weird dependency failure log

On Fri, 2009-11-13 at 12:08 -0200, Maurí­cio CA wrote:
> >> There's one thing special about bindings-DSL. It's
> >> a package with a set of macros for hsc2hs, and contains
> >> no Haskell code. Maybe this revealed some hidden error
> >> in package dependency checking.
> > 
> > This is a package with no library and no executables.
> > That's not supposed to work.
> 
> It contains hsc2hs data all dependent packages use.
> 
> Why shouldn't this be supposed to work? It does install needed
> files (two include files for hsc2hs), and they do stand for
> themselves to justify a package of its own.

Header files are associated with a library. If there is no library then
nothing gets registered. This is by design.

> And other packages could also want to distribute just data. Say, a
> database of daytime saving dates to be used by a clock package.

If it's not a library, nothing can depend on it.

Duncan
Maurí­cio CA | 13 Nov 18:53
Picon

Re: Weird dependency failure log

 >>> This is a package with no library and no executables. That's
 >>> not supposed to work.

 >> Why shouldn't this be supposed to work? It does install needed
 >> files (two include files for hsc2hs), and they do stand for
 >> themselves to justify a package of its own.

 > Header files are associated with a library. If there is no
 > library then nothing gets registered. This is by design.

Doesn't Cabal option 'install-includes' contradicts that?

 > If it's not a library, nothing can depend on it.

But please tell me then where my package fits. Many libraries I
wrote and use depend heavily on it. Versioning in this package is
extremely important, as a change in design for any macro would
change all names in depending libraries.

Thanks,
Maurício
Duncan Coutts | 13 Nov 22:49

Re: Re: Weird dependency failure log

On Fri, 2009-11-13 at 15:53 -0200, Maurí­cio CA wrote:
> >>> This is a package with no library and no executables. That's
>  >>> not supposed to work.
> 
>  >> Why shouldn't this be supposed to work? It does install needed
>  >> files (two include files for hsc2hs), and they do stand for
>  >> themselves to justify a package of its own.
> 
>  > Header files are associated with a library. If there is no
>  > library then nothing gets registered. This is by design.
> 
> Doesn't Cabal option 'install-includes' contradicts that?

No. The install-includes field is part of a library or executable
section in a .cabal file. It is not global to a package as a whole.

>  > If it's not a library, nothing can depend on it.
> 
> But please tell me then where my package fits.

I'm not sure I understand the question. Can you clarify what you mean.

> Many libraries I wrote and use depend heavily on it. Versioning in
> this package is extremely important, as a change in design for any
> macro would change all names in depending libraries.

I notice that you have changed the package to include a library.

Duncan
Maurí­cio CA | 13 Nov 23:47
Picon

Re: Weird dependency failure log


>> > Header files are associated with a library. >> > If there is no library then nothing gets >> > registered. This is by design. >> > If it's not a library, nothing can depend on >> > it. >> But please tell me then where my package fits. > I'm not sure I understand the question. Can you > clarify what you mean.
Well, you said that if it's not a library, it can't have dependencies, and my package is not a library and does have dependencies. Maybe it should not be a package at all, but then I would not know a safe way to distribute it without breaking packages when something changes. I inserted a dummy module so that the package is accepted as a dependency. But I'm not sure this is appropriate. Thanks, Maurício

Gmane