Add support for convenience libraries #269

Closed
opened this Issue May 24, 2012 · 23 comments

None yet

8 participants

Contributor
commented May 24, 2012
 (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.
Contributor
commented May 24, 2012
 (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.
Contributor
commented May 24, 2012
 (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.
Collaborator
 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.
Collaborator
 IOW: Close.
Member
commented Jun 27, 2015
 No I think this is quite feasible and indeed still a good idea.
referenced this issue Jul 11, 2015
Closed

Scoped packages (i.e. multiple libraries in a Cabal package) #2716

Collaborator
 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.
referenced this issue Nov 29, 2015
Closed

Non-package for sharing object file builds between multiple executables in same project #2938

 @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?
Contributor
 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.
Collaborator
 @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 :) .)
Collaborator
 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.)
Collaborator
commented Nov 30, 2015
 I'd rather add label pr welcome, to indicate that it's ok to implement this or that feature request and submit the pr. 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 cabal-install), which could solve this trivially.
Collaborator
 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.
Contributor
commented Dec 23, 2015
 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!
Collaborator
 @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) :).
Contributor
commented Dec 27, 2015
 @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).
Collaborator
commented Dec 28, 2015
 I'm not sure how re-opening in github works; IIRC non-collaborator cannot reopen issue if collaborator have closed it
Contributor
commented Dec 28, 2015
 I guess that's this bug: isaacs/github#361 So we can't do that.
referenced this issue Jan 1, 2016
Closed

Reserve a package namespace for sub-libraries in GHC 7.8 and prior #3017

added a commit to ezyang/cabal that referenced this issue Jan 2, 2016
 ezyang Properly assign component ID/build dir for LibV09 test libraries 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. #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 #3017. Signed-off-by: Edward Z. Yang  2e77ba5
added a commit to ezyang/cabal that referenced this issue Jan 2, 2016
 ezyang Properly assign component ID/build dir for LibV09 test libraries 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. #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 #3017. Signed-off-by: Edward Z. Yang  e8e47f6
referenced this issue Jan 2, 2016
Closed

Fix some bugs related to detailed-0.9 test suites #3015

self-assigned this Jan 2, 2016
Contributor
commented Jan 2, 2016
 I have a working implementation of this. I'll clean it up and PR.
 Thanks!
Contributor
commented Jan 3, 2016
 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.)
referenced this issue in ndmitchell/shake Jan 3, 2016
Closed

Make shake a library, make the executable/test-suite use it #360

added a commit to ezyang/cabal that referenced this issue Jan 3, 2016
 ezyang Properly assign component ID/build dir for LibV09 test libraries 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. #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 #3017. Signed-off-by: Edward Z. Yang  45331e8
added a commit to ezyang/cabal that referenced this issue Jan 3, 2016
 ezyang Implement "convenience libraries", fixes #269. 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. TODO: if we REALLY don't want to install a convenience library, we could add a "installable:" flag which toggles whether or not copy/register should install it. Extra sanity checking is necessary in this case. TODO: docs TODO: cabal-install must ignore convenience libraries when dep solving Signed-off-by: Edward Z. Yang  ef8ab6c
referenced this issue Jan 3, 2016
Merged

Convenience libraries #3022

added a commit to ezyang/cabal that referenced this issue Jan 4, 2016
 ezyang Implement "convenience libraries", fixes #269. 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. TODO: if we REALLY don't want to install a convenience library, we could add a "installable:" flag which toggles whether or not copy/register should install it. Extra sanity checking is necessary in this case. TODO: docs TODO: cabal-install must ignore convenience libraries when dep solving Signed-off-by: Edward Z. Yang  3fadf36
added a commit to ezyang/cabal that referenced this issue Jan 8, 2016
 ezyang Properly assign component ID/build dir for LibV09 test libraries 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. #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 #3017. Signed-off-by: Edward Z. Yang  b4d3e69
added a commit to ezyang/cabal that referenced this issue Jan 8, 2016
 ezyang Implement "convenience libraries", fixes #269. 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. TODO: if we REALLY don't want to install a convenience library, we could add a "installable:" flag which toggles whether or not copy/register should install it. Extra sanity checking is necessary in this case. TODO: docs TODO: cabal-install must ignore convenience libraries when dep solving Signed-off-by: Edward Z. Yang  44c458b
added a commit that referenced this issue Jan 10, 2016
 ezyang Properly assign component ID/build dir for LibV09 test libraries 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. #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 #3017. Signed-off-by: Edward Z. Yang  18fcd9c
added a commit to ezyang/cabal that referenced this issue Jan 10, 2016
 ezyang Implement "convenience libraries", fixes #269. 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. TODO: if we REALLY don't want to install a convenience library, we could add a "installable:" flag which toggles whether or not copy/register should install it. Extra sanity checking is necessary in this case. TODO: docs TODO: cabal-install must ignore convenience libraries when dep solving Signed-off-by: Edward Z. Yang  cee286b
added a commit to ezyang/cabal that referenced this issue Jan 12, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  32e905b
added a commit to ezyang/cabal that referenced this issue Jan 12, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  0ecdcea
added a commit to ezyang/cabal that referenced this issue Jan 12, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  2c3f3ca
referenced this issue Jan 13, 2016
Closed

Backpack design ticket #3038

added a commit to ezyang/cabal that referenced this issue Jan 13, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  d26ff19
added a commit to ezyang/cabal that referenced this issue Jan 13, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  06a3bed
added a commit to ezyang/cabal that referenced this issue Jan 14, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  44a4bd9
added a commit to ezyang/cabal that referenced this issue Jan 14, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  e0b4734
added a commit to ezyang/cabal that referenced this issue Jan 15, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  4bec746
added a commit to ezyang/cabal that referenced this issue Jan 15, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  9c84c7f
added a commit to ezyang/cabal that referenced this issue Jan 19, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  693eb9b
added a commit to ezyang/cabal that referenced this issue Jan 19, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  0f618ec
added a commit to ezyang/cabal that referenced this issue Jan 27, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  a0f25ff
added a commit to ezyang/cabal that referenced this issue Jan 27, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  cf35303
added a commit to ezyang/cabal that referenced this issue Jan 28, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  7526cb5
added a commit to ezyang/cabal that referenced this issue Jan 28, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  a7139a9
added a commit to ezyang/cabal that referenced this issue Feb 2, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  f58a1e8
added a commit to ezyang/cabal that referenced this issue Feb 2, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  ccf5d8d
added a commit to ezyang/cabal that referenced this issue Feb 2, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  875cfc6
added a commit to ezyang/cabal that referenced this issue Feb 2, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  428969e
added a commit to ezyang/cabal that referenced this issue Feb 2, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  8fcf9db
added a commit to ezyang/cabal that referenced this issue Feb 2, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  3b6c13b
added a commit to ezyang/cabal that referenced this issue Feb 6, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  0f4ed00
added a commit to ezyang/cabal that referenced this issue Feb 6, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  49d95b9
added a commit to ezyang/cabal that referenced this issue Feb 20, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  cd3d770
added a commit to ezyang/cabal that referenced this issue Feb 20, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  f0fe48f
added a commit to ezyang/cabal that referenced this issue Feb 20, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  c0e9506
added a commit to ezyang/cabal that referenced this issue Feb 20, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  feeba7b
added a commit to ezyang/cabal that referenced this issue Mar 5, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  86cba88
added a commit to ezyang/cabal that referenced this issue Mar 5, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  2b82955
added a commit to garetxe/cabal that referenced this issue Mar 5, 2016
 ezyang + garetxe Properly assign component ID/build dir for LibV09 test libraries 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. #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 #3017. Signed-off-by: Edward Z. Yang  78c7105
added a commit to ezyang/cabal that referenced this issue Mar 16, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  4b721d7
added a commit to ezyang/cabal that referenced this issue Mar 16, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  af947dc
added a commit to ezyang/cabal that referenced this issue Mar 16, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  a1d539d
added a commit to ezyang/cabal that referenced this issue Mar 16, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  fde7e8c
added a commit to ezyang/cabal that referenced this issue Mar 18, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  6fe0abc
added a commit to ezyang/cabal that referenced this issue Mar 18, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  475ab7a
added a commit to ezyang/cabal that referenced this issue Mar 28, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  7dd2346
added a commit to ezyang/cabal that referenced this issue Mar 28, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  1e66854
added a commit to ezyang/cabal that referenced this issue Mar 28, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  b283e08
added a commit to ezyang/cabal that referenced this issue Mar 28, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  b8ab450
added a commit to ezyang/cabal that referenced this issue Mar 29, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  746a2e0
added a commit to ezyang/cabal that referenced this issue Mar 29, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  86e9340
added a commit to ezyang/cabal that referenced this issue Mar 29, 2016
 ezyang Implement "convenience libraries", fixes #269. 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  2040c1c
added a commit to ezyang/cabal that referenced this issue Mar 29, 2016
 ezyang Tests for internal libraries (#269) and separate cabal_macros.h (#1893) Signed-off-by: Edward Z. Yang  36eb65e
closed this in #3022 Mar 29, 2016
 Again, thanks huge for this. It is really appreciated.
Member
 Yes, thanks @ezyang!
referenced this issue Jan 3, 2017
Open

Multiple public libraries in a package #4206

to join this conversation on GitHub. Already have an account? Sign in to comment