build-depends in old-style package descriptions
The build-depends field has been moved from the package level to the individual library and executable components. (And the new build-tools and pkgconfig-depends fields are similarly attached to components.) I'm not sure whether this is a good idea, but more specifically I came across this in the parser for old-style package descriptions in Distribution.PackageDescription: -- The 'build-depends' field was global so far. Now it's -- supported in each section. -- XXX: we actially have two options here -- (1) put all dependencies into the library section, if the -- library section would be empty, mark it as not buildable -- (2) duplicate all dependencies in each section, libraries -- and executables -- Right now we go with (1) Surely (1) is just wrong. Is there any reason not to do (2)?
On Sun, 2007-09-09 at 10:21 +0100, Ross Paterson wrote:
The build-depends field has been moved from the package level to the individual library and executable components. (And the new build-tools and pkgconfig-depends fields are similarly attached to components.) I'm not sure whether this is a good idea, but more specifically I came across this in the parser for old-style package descriptions in Distribution.PackageDescription:
-- The 'build-depends' field was global so far. Now it's -- supported in each section. -- XXX: we actially have two options here -- (1) put all dependencies into the library section, if the -- library section would be empty, mark it as not buildable -- (2) duplicate all dependencies in each section, libraries -- and executables -- Right now we go with (1)
Surely (1) is just wrong. Is there any reason not to do (2)?
(1) was easier at the time. (2) should be relatively easy to implement now, but since the current implementation works, I didn't bother so far. I know that (1) is a rather hackish solution, but why is it "just wrong"? (After all, it works.)
On Sun, Sep 09, 2007 at 03:18:43PM +0200, Thomas Schilling wrote:
(1) was easier at the time. (2) should be relatively easy to implement now, but since the current implementation works, I didn't bother so far. I know that (1) is a rather hackish solution, but why is it "just wrong"? (After all, it works.)
It makes a package that doesn't contain a library look like it does have one (though unbuildable). I think there's an important difference between the two cases; it certainly matters to clients.
On Sun, 2007-09-09 at 14:42 +0100, Ross Paterson wrote:
On Sun, Sep 09, 2007 at 03:18:43PM +0200, Thomas Schilling wrote:
(1) was easier at the time. (2) should be relatively easy to implement now, but since the current implementation works, I didn't bother so far. I know that (1) is a rather hackish solution, but why is it "just wrong"? (After all, it works.)
It makes a package that doesn't contain a library look like it does have one (though unbuildable). I think there's an important difference between the two cases; it certainly matters to clients.
Note that it does not rewrite the _external_ package description. Cabal now internally uses the section-based syntax, so we have to rewrite old flat package descriptions to the section-based format _internally_. I.e., the actual text-file is never overridden, so no end-user will ever see this.
On Sun, Sep 09, 2007 at 05:37:32PM +0200, Thomas Schilling wrote:
Note that it does not rewrite the _external_ package description. Cabal now internally uses the section-based syntax, so we have to rewrite old flat package descriptions to the section-based format _internally_. I.e., the actual text-file is never overridden, so no end-user will ever see this.
I realize that -- I'm concerned about clients of the Cabal library (e.g. the HackageDB scripts), whose view of the package description goes through this function.
On Sun, Sep 09, 2007 at 03:18:43PM +0200, Thomas Schilling wrote:
On Sun, 2007-09-09 at 10:21 +0100, Ross Paterson wrote:
The build-depends field has been moved from the package level to the individual library and executable components. (And the new build-tools and pkgconfig-depends fields are similarly attached to components.) I'm not sure whether this is a good idea, but more specifically I came across this in the parser for old-style package descriptions in Distribution.PackageDescription:
-- The 'build-depends' field was global so far. Now it's -- supported in each section. -- XXX: we actially have two options here -- (1) put all dependencies into the library section, if the -- library section would be empty, mark it as not buildable -- (2) duplicate all dependencies in each section, libraries -- and executables -- Right now we go with (1)
Surely (1) is just wrong. Is there any reason not to do (2)?
(1) was easier at the time. (2) should be relatively easy to implement now, but since the current implementation works, I didn't bother so far. I know that (1) is a rather hackish solution, but why is it "just wrong"? (After all, it works.)
Could we not just replace (deps, libfs1) = partition ((`elem` constraintFieldNames) . fName) libfs0 libfs = if null libfs1 && not (null deps) then [F (lineNo (head deps)) "buildable" "False"] else libfs1 with (deps, libfs) = partition ((`elem` constraintFieldNames) . fName) libfs0
On Tue, Sep 18, 2007 at 10:02:52AM +0100, Ross Paterson wrote:
Could we not just replace
(deps, libfs1) = partition ((`elem` constraintFieldNames) . fName) libfs0 libfs = if null libfs1 && not (null deps) then [F (lineNo (head deps)) "buildable" "False"] else libfs1
with
(deps, libfs) = partition ((`elem` constraintFieldNames) . fName) libfs0
Is there any reason not to do this? It would simplify the interface for clients.
participants (2)
-
Ross Paterson -
Thomas Schilling