Add support for convenience libraries #269
Comments
|
(Imported comment by @dcoutts on 2008-05-09) There is the constraint that there be at most one installable library so I'm not sure a bool flag is quite right. |
|
(Imported comment by @dcoutts on 2008-05-09) This would mean that the lib would always have to be built statically even if the user requests dynamic libs. So this feature mainly depends on the ability to use build-depends: on a lib defined within the same package (whether that lib is to be installed or not). Similarly for build-tools. This would also solve ticket #89. |
|
Last comment 2008(!). And is this even reasonably feasible, given the apparent complexity wrt. static vs. dynamic[1]? "Create an app-specific library" does not seem too onerous a requirement, especially if #2631 comes to fruition. [1] I don't know if "static" here includes C libraries, but if it does... glibc simply cannot be statically linked in any case. |
|
IOW: Close. |
|
No I think this is quite feasible and indeed still a good idea. |
|
Is anyone (realistically) going to implement it? I'm voting for "WONTFIX-UNLESS-SOMEONE-STEPS-UP". (I don't necessarily think it's a bad idea, but issue trackers of GitHub's caliber aren't meant for "wishlist" items.) EDIT: Btw, this has been open since 2008 and nobody showed up to implement during all that time. That should tell you something. Please just close this. |
|
@BardurArantsson: Why the eagerness to get a valid issue closed? Maybe someone will come along five years from now looking for something to do and find this. Let's not make it harder to find by closing it. I'm not sure why you think wishlist items don't belong in the issue tracker? |
|
I think even closed issues remain in the tracker, and can be found so this is not a reason to keep it open.. |
|
@Martinvik: People looking for something to work on rarely look in the closed issues. |
|
@BartMassey The likelihood of anyone randomly dropping by and picking this up is nil for all practical purposes. I refer to the fact that this has been open since 2008. Meanwhile, every such item is causes a certain (small) amount of wasted time every time any one browses through the issue list. Given the above, I believe it's better to just close such issues. (I have a whole rant about why bug trackers are not the place for wishlist items in general, but I'll spare you :) .) |
|
Btw, my half-baked theory on why next to no drop-by contributors do wishlist items is that people tend to want to scratch their own itch -- in which case it won't matter if there's an open issue. (Unless they're just trying to pad their own résumé, in which case they might as well work on something that matters to more people. There's plenty of more important issues to go round.) |
|
I'd rather add label That said, it's obvious that I'd only close issues when there is real need (obsolete, or fixed / implemented / or clearly wontfix). There are labels, which could be used to classify issues. IMHO enchancement and milestone: ⊥ do the job quite well. The pr welcome -label might communicate it even better. No need to close with the message "re-open if needed". There are people, who want to contribute, but have no idea about where to start or what to do, and what is easy and what's not. The infrastructure hackathon is one of the empirical proofs of that. And returning to this feature: it might be easy task: as you don't need to register/copy the library bits, only executable(s). IIRC there was an issue related to that (more component oriented approach in |
|
The problem is that if we don't have a clear guideline for exactly how to proceed on any given issue then "pr welcome" or "easy" issues are, I'd argue, even worse than useless because people will just dive in and immediately get discouraged because these things often unfortunately aren't easy due to the state of the cabal-install code base. Either that or we need some person who's willing to be designated "mentor" on said issue and who can help guide the person through. (Similar to a hackathon.) I don't deny that these people who want to help exist -- but I think there are more useful issues they could be working on! (See also below.) The problem with labels is that they have no semantics associated with them by GH Issues... and the project doesn't seem to have any either? (Didn't do a particularly thorough search, but I couldn't find any description of what any of the labels in here actually mean.) I also have a whole rant about GH Issues... :). I'm not necessarily saying that wishlist items should automatically be discarded/closed, but wishlist items with no action since 2008? C'mon, now! That's obviously a wishlist item that no more than 1+\epsilon people care about. (In general, I think there must be some sort of "deadline" for wishlist items, unless we're talking rare cases of wishlist items which are showing clear progress towards being solved.) Btw, thanks for the description of a possible solution for this concrete issue. THIS is what should be front-and-center (i.e. in the issue description) for any "easy" or "pr welcome" type issue. (This is a bit of side -- but related -- issue, but the project as a whole could definitely do better on the "pr welcome" front -- it certainly doesn't appear like PRs are particularly welcome at the moment. There are a lot of lingering PRs in the queue, many probably obsolete or not which will have to be redone because master has moved on... not encouraging for outsiders :/. I know people are doing their best, but... I think something needs to change.) EDIT: Sorry, that turned out longer than I intended. |
|
I reviewed the PR queue. If a PR has action-required on it, it means that the PR needs updates before it can go in (not JUST rebasing; it was CRed but there were things that needed to be changed.) Should we close those PRs to make the PR queue look more friendly? Phabricator does WAY better in this regard. In any case, it is not easy to contribute modifications to Cabal. I wish it were easier, but Cabal is a big ball of wax and it's harder than it should be. Issues like this require a bit of refactoring to happen first, before the actual issue can be done. I don't really know what to do... except refactor more! |
|
@ezyang I think maybe doing the action-required -> close thing might be feasible, but it's Yet Another Informal Rule That All Project Members/Contributors Have To Rememember so I'd lean towards not doing it. I don't know Phabricator[1], but I don't find it surprising that it does this better -- almost everything does, probably including the old-fashioned mailing-lists-for-git-patches approach :). Agreed re: re-factoring, but I think it'll need some concerted effort to get the overall code base into better shape. (I've been thinking on-and-off about a Free monad refactoring, but that's probably completely unrealistic without a complete rewrite.) [1] I'm used to gerrit, myself. It works way better than this GitHub PR nonsense and it doesn't involve installing any new executables on your system (unlike Phabricator) :). |
|
@BardurArantsson I tried using the "action-required" label to mark this, but no one could remember to add/remove this label as necessary (and non-contributors don't even have the rights to do it!) I think close is better: we only need to educate people with commit bits how to do this (users will automatically know to reopen requests when they submit them.) I have definitely also come to the conclusion that Cabal needs more monads(TM). |
|
I'm not sure how re-opening in github works; IIRC non-collaborator cannot reopen issue if collaborator have closed it |
|
I guess that's this bug: isaacs/github#361 So we can't do that. |
Cabal's LibV09 support has always been a bit skeevy. The general
idea was that a detailed-0.9 test-suite is built as a library
and an Cabal-provided stub executable. In particular, the test suite
library must be installed to the installed package database so that the
executable can be compiled.
Old versions of Cabal did something very skeevy here: they installed
the test library as a "package", with the same package name as
the "test-suite" stanza; furthermore, they built the products
into the same directory as the library proper.
Consequently, a lot of bad things could happen (both of which I've
added tests for):
1. If the name of the test suite and the name of some other
package coincide (and have the same version), they will clobber
each other. In GHC 7.8 and earlier, this just flat out
kills the build, because it will shadow. There's an explicit
test to make sure test suites don't conflict with the package
name, but you can get unlucky.
2. The test suite library is built into the same directory
as the main library, which means that if the test library
implements the same module name as something in the main
library it will clobber the interface file and badness
will ensue.
This patchset fixes both of these issues, by (1) giving internal
test libraries proper names which are guaranteed to be unique
up to Cabal's dependency resolution, and (2) building the test
suite library into a separate directory.
In doing so, it also lays the groundwork for other types of
internal libraries, e.g. haskell#269, as well as extra (invisible)
libraries which we may install.
For GHC 7.8 and earlier, we follow the reserved namespace
convention as per haskell#3017.
Signed-off-by: Edward Z. Yang <[email protected]>
Cabal's LibV09 support has always been a bit skeevy. The general
idea was that a detailed-0.9 test-suite is built as a library
and an Cabal-provided stub executable. In particular, the test suite
library must be installed to the installed package database so that the
executable can be compiled.
Old versions of Cabal did something very skeevy here: they installed
the test library as a "package", with the same package name as
the "test-suite" stanza; furthermore, they built the products
into the same directory as the library proper.
Consequently, a lot of bad things could happen (both of which I've
added tests for):
1. If the name of the test suite and the name of some other
package coincide (and have the same version), they will clobber
each other. In GHC 7.8 and earlier, this just flat out
kills the build, because it will shadow. There's an explicit
test to make sure test suites don't conflict with the package
name, but you can get unlucky.
2. The test suite library is built into the same directory
as the main library, which means that if the test library
implements the same module name as something in the main
library it will clobber the interface file and badness
will ensue.
This patchset fixes both of these issues, by (1) giving internal
test libraries proper names which are guaranteed to be unique
up to Cabal's dependency resolution, and (2) building the test
suite library into a separate directory.
In doing so, it also lays the groundwork for other types of
internal libraries, e.g. haskell#269, as well as extra (invisible)
libraries which we may install.
For GHC 7.8 and earlier, we follow the reserved namespace
convention as per haskell#3017.
Signed-off-by: Edward Z. Yang <[email protected]>
|
I have a working implementation of this. I'll clean it up and PR. |
|
Thanks! |
|
One thing is that my implementation "accidentally" supports installing the helper libraries too (although there's no way to refer to them, except through the real library, or dynamic linking.) |
Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world. Private
libraries are signified using the
library foo
stanza. Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)
This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)
There is a "default" library which is identified by the fact
that its library name coincides with the package name. There
are some new convenience functions to permit referencing this.
There are a few latent bugs in this commit which are fixed
in later commits in this patchset. (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)
Signed-off-by: Edward Z. Yang <[email protected]>
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world. Private
libraries are signified using the
library foo
stanza. Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)
This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)
There is a "default" library which is identified by the fact
that its library name coincides with the package name. There
are some new convenience functions to permit referencing this.
There are a few latent bugs in this commit which are fixed
in later commits in this patchset. (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)
Signed-off-by: Edward Z. Yang <[email protected]>
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world. Private
libraries are signified using the
library foo
stanza. Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)
This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)
There is a "default" library which is identified by the fact
that its library name coincides with the package name. There
are some new convenience functions to permit referencing this.
There are a few latent bugs in this commit which are fixed
in later commits in this patchset. (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)
Signed-off-by: Edward Z. Yang <[email protected]>
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world. Private
libraries are signified using the
library foo
stanza. Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)
This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)
There is a "default" library which is identified by the fact
that its library name coincides with the package name. There
are some new convenience functions to permit referencing this.
There are a few latent bugs in this commit which are fixed
in later commits in this patchset. (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)
Signed-off-by: Edward Z. Yang <[email protected]>
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world. Private
libraries are signified using the
library foo
stanza. Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)
This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)
There is a "default" library which is identified by the fact
that its library name coincides with the package name. There
are some new convenience functions to permit referencing this.
There are a few latent bugs in this commit which are fixed
in later commits in this patchset. (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)
Signed-off-by: Edward Z. Yang <[email protected]>
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Cabal's LibV09 support has always been a bit skeevy. The general
idea was that a detailed-0.9 test-suite is built as a library
and an Cabal-provided stub executable. In particular, the test suite
library must be installed to the installed package database so that the
executable can be compiled.
Old versions of Cabal did something very skeevy here: they installed
the test library as a "package", with the same package name as
the "test-suite" stanza; furthermore, they built the products
into the same directory as the library proper.
Consequently, a lot of bad things could happen (both of which I've
added tests for):
1. If the name of the test suite and the name of some other
package coincide (and have the same version), they will clobber
each other. In GHC 7.8 and earlier, this just flat out
kills the build, because it will shadow. There's an explicit
test to make sure test suites don't conflict with the package
name, but you can get unlucky.
2. The test suite library is built into the same directory
as the main library, which means that if the test library
implements the same module name as something in the main
library it will clobber the interface file and badness
will ensue.
This patchset fixes both of these issues, by (1) giving internal
test libraries proper names which are guaranteed to be unique
up to Cabal's dependency resolution, and (2) building the test
suite library into a separate directory.
In doing so, it also lays the groundwork for other types of
internal libraries, e.g. haskell#269, as well as extra (invisible)
libraries which we may install.
For GHC 7.8 and earlier, we follow the reserved namespace
convention as per haskell#3017.
Signed-off-by: Edward Z. Yang <[email protected]>
Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world. Private
libraries are signified using the
library foo
stanza. Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)
This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)
There is a "default" library which is identified by the fact
that its library name coincides with the package name. There
are some new convenience functions to permit referencing this.
There are a few latent bugs in this commit which are fixed
in later commits in this patchset. (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)
Signed-off-by: Edward Z. Yang <[email protected]>
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world. Private
libraries are signified using the
library foo
stanza. Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)
This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)
There is a "default" library which is identified by the fact
that its library name coincides with the package name. There
are some new convenience functions to permit referencing this.
There are a few latent bugs in this commit which are fixed
in later commits in this patchset. (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)
Signed-off-by: Edward Z. Yang <[email protected]>
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world. Private
libraries are signified using the
library foo
stanza. Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)
This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)
There is a "default" library which is identified by the fact
that its library name coincides with the package name. There
are some new convenience functions to permit referencing this.
There are a few latent bugs in this commit which are fixed
in later commits in this patchset. (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)
Signed-off-by: Edward Z. Yang <[email protected]>
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world. Private
libraries are signified using the
library foo
stanza. Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)
This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)
There is a "default" library which is identified by the fact
that its library name coincides with the package name. There
are some new convenience functions to permit referencing this.
There are a few latent bugs in this commit which are fixed
in later commits in this patchset. (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)
Signed-off-by: Edward Z. Yang <[email protected]>
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world. Private
libraries are signified using the
library foo
stanza. Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)
This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)
There is a "default" library which is identified by the fact
that its library name coincides with the package name. There
are some new convenience functions to permit referencing this.
There are a few latent bugs in this commit which are fixed
in later commits in this patchset. (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)
Signed-off-by: Edward Z. Yang <[email protected]>
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world. Private
libraries are signified using the
library foo
stanza. Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)
This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)
There is a "default" library which is identified by the fact
that its library name coincides with the package name. There
are some new convenience functions to permit referencing this.
There are a few latent bugs in this commit which are fixed
in later commits in this patchset. (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)
Signed-off-by: Edward Z. Yang <[email protected]>
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world. Private
libraries are signified using the
library foo
stanza. Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)
This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)
There is a "default" library which is identified by the fact
that its library name coincides with the package name. There
are some new convenience functions to permit referencing this.
There are a few latent bugs in this commit which are fixed
in later commits in this patchset. (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)
Signed-off-by: Edward Z. Yang <[email protected]>
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
|
Again, thanks huge for this. It is really appreciated. |
|
Yes, thanks @ezyang! |
(Imported from Trac #276, reported by rl on 2008-05-09)
I'd like to have a package with several binaries which all use a convenience library included in that same package. The convenience library should NOT be installed. For this to work, Cabal needs two things. Firstly, it must allow dependencies within a package such that I could describe the library and have the binaries depend on it. Secondly, it should have an "installable" flag, similar to "buildable". A thing that's not installable would be built but not installed. The same mechanism could be used for package-internal tools.
The text was updated successfully, but these errors were encountered: