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
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.
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
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
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
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
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
participants (3)
-
Duncan Coutts -
Maurício CA -
Ross Paterson