New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for convenience libraries #269

Closed
bos opened this Issue May 24, 2012 · 23 comments

Comments

Projects
None yet
8 participants
@bos
Contributor

bos 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.

@bos

This comment has been minimized.

Show comment
Hide comment
@bos

bos May 24, 2012

Contributor

(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

bos 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.

@bos

This comment has been minimized.

Show comment
Hide comment
@bos

bos May 24, 2012

Contributor

(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.

Contributor

bos 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.

@BardurArantsson

This comment has been minimized.

Show comment
Hide comment
@BardurArantsson

BardurArantsson Jun 25, 2015

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

BardurArantsson commented Jun 25, 2015

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.

@BardurArantsson

This comment has been minimized.

Show comment
Hide comment
@BardurArantsson

BardurArantsson Jun 25, 2015

Collaborator

IOW: Close.

Collaborator

BardurArantsson commented Jun 25, 2015

IOW: Close.

@dcoutts

This comment has been minimized.

Show comment
Hide comment
@dcoutts

dcoutts Jun 27, 2015

Member

No I think this is quite feasible and indeed still a good idea.

Member

dcoutts commented Jun 27, 2015

No I think this is quite feasible and indeed still a good idea.

@BardurArantsson

This comment has been minimized.

Show comment
Hide comment
@BardurArantsson

BardurArantsson Aug 21, 2015

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.

Collaborator

BardurArantsson commented Aug 21, 2015

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.

@BartMassey

This comment has been minimized.

Show comment
Hide comment
@BartMassey

BartMassey Nov 29, 2015

@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?

BartMassey commented Nov 29, 2015

@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?

@martinvlk

This comment has been minimized.

Show comment
Hide comment
@martinvlk

martinvlk Nov 30, 2015

Contributor

I think even closed issues remain in the tracker, and can be found so this is not a reason to keep it open..

Contributor

martinvlk commented Nov 30, 2015

I think even closed issues remain in the tracker, and can be found so this is not a reason to keep it open..

@BartMassey

This comment has been minimized.

Show comment
Hide comment
@BartMassey

BartMassey Nov 30, 2015

@martinvik: People looking for something to work on rarely look in the closed issues.

BartMassey commented Nov 30, 2015

@martinvik: People looking for something to work on rarely look in the closed issues.

@BardurArantsson

This comment has been minimized.

Show comment
Hide comment
@BardurArantsson

BardurArantsson Nov 30, 2015

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

BardurArantsson commented Nov 30, 2015

@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 :) .)

@BardurArantsson

This comment has been minimized.

Show comment
Hide comment
@BardurArantsson

BardurArantsson Nov 30, 2015

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

BardurArantsson commented Nov 30, 2015

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.)

@phadej

This comment has been minimized.

Show comment
Hide comment
@phadej

phadej Nov 30, 2015

Collaborator

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

phadej 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.

@BardurArantsson

This comment has been minimized.

Show comment
Hide comment
@BardurArantsson

BardurArantsson Dec 2, 2015

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.

Collaborator

BardurArantsson commented Dec 2, 2015

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.

@ezyang

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Dec 23, 2015

Contributor

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!

Contributor

ezyang 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!

@BardurArantsson

This comment has been minimized.

Show comment
Hide comment
@BardurArantsson

BardurArantsson Dec 27, 2015

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) :).

Collaborator

BardurArantsson commented Dec 27, 2015

@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) :).

@ezyang

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Dec 27, 2015

Contributor

@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).

Contributor

ezyang 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).

@phadej

This comment has been minimized.

Show comment
Hide comment
@phadej

phadej Dec 28, 2015

Collaborator

I'm not sure how re-opening in github works; IIRC non-collaborator cannot reopen issue if collaborator have closed it

Collaborator

phadej 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

@ezyang

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Dec 28, 2015

Contributor

I guess that's this bug: isaacs/github#361

So we can't do that.

Contributor

ezyang commented Dec 28, 2015

I guess that's this bug: isaacs/github#361

So we can't do that.

ezyang added a commit to ezyang/cabal that referenced this issue Jan 2, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 2, 2016

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 <ezyang@cs.stanford.edu>

@ezyang ezyang self-assigned this Jan 2, 2016

@ezyang

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Jan 2, 2016

Contributor

I have a working implementation of this. I'll clean it up and PR.

Contributor

ezyang commented Jan 2, 2016

I have a working implementation of this. I'll clean it up and PR.

@BartMassey

This comment has been minimized.

Show comment
Hide comment
@BartMassey

BartMassey commented Jan 3, 2016

Thanks!

@ezyang

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Jan 3, 2016

Contributor

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.)

Contributor

ezyang 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.)

ezyang added a commit to ezyang/cabal that referenced this issue Jan 3, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 3, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 4, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 8, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 8, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit that referenced this issue Jan 10, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 10, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 12, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 12, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 15, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 19, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 19, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 27, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 27, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 28, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Jan 28, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Feb 2, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Feb 2, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Feb 2, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Feb 2, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Feb 2, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Feb 2, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Feb 6, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Feb 6, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Feb 20, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Feb 20, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Feb 20, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Feb 20, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 5, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 5, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

garetxe added a commit to garetxe/cabal that referenced this issue Mar 5, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 16, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 16, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 16, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 16, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 18, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 18, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 28, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 28, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 28, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 28, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 29, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 29, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 29, 2016

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 <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Mar 29, 2016

Tests for internal libraries (#269) and separate cabal_macros.h (#1893)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

@ezyang ezyang closed this in #3022 Mar 29, 2016

@BartMassey

This comment has been minimized.

Show comment
Hide comment
@BartMassey

BartMassey Mar 30, 2016

Again, thanks huge for this. It is really appreciated.

BartMassey commented Mar 30, 2016

Again, thanks huge for this. It is really appreciated.

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Mar 30, 2016

Member

Yes, thanks @ezyang!

Member

23Skidoo commented Mar 30, 2016

Yes, thanks @ezyang!

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