Duplication introduced by #4065.

tulcod authored Oct 31, 2016 and Edward Z. Yang committed Oct 31, 2016

Also bump version requirements for foreign libs (ghc>=7.8)

Edward Z. Yang authored Oct 28, 2016 and Edward Z. Yang committed Oct 31, 2016

The key idea is that once we put PackageTests in its own package, we can
ensure that its Setup.hs is compiled with the same version of Cabal
library as package-tests is compiled with.  This means that LBI reading
will *always succeed* which is quite nice.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

A stanza for a platform library looks something like

    platform-library test-package
      type:                native-shared

      if os(Windows)
        options: standalone
        mod-def-file: TestPackage.def

      other-modules:       MyPlatformLib.Hello
                           MyPlatformLib.SomeBindings
      build-depends:       base >=4.7 && <4.9
      hs-source-dirs:      src
      c-sources:           csrc/MyPlatformLibWrapper.c
      default-language:    Haskell2010

where native-shared means that we want to build a native shared library
(.so on Linux, .dylib on OSX, .dll on Windows). The parser also
recognizes native-static but this is not currently supported anywhere.
The standalone option means that the we merge all library dependencies
into the dynamic library (i.e., ghc options -shared -static), rather
than make the created dynamic library just record its dependencies (ghc
options -shared -dynamic); it is currently compulsory on Windows and
unsupported anywhere else. The mod-def-file can be used to specify a
module definition file, and is also Windows specific.

There is a bit of refactoring in Build: gbuild is the old buildOrReplExe
and now deals with both executables and platform libraries.

In #4017, hvr reported that when he used --allow-older/--allow-newer,
there was an assert failure in toConfiguredComponent.  Indeed
the problem was that toConfiguredComponent was testing version
ranges of build-depends to determine which package to select, but
there was no satisfying one (since the build-depends field had
not been updated.)

After thinking about this for a bit, it seemed a bit bogus for
us to be doing another version check at this late phase; we
already picked dependencies earlier in the configuration process.
So I decided to drop it.

To drop it, however, I needed to remove support for a feature (discussed
in #4020), which uses version ranges to disambiguate whether or not a
dependency is on an external package or an internal package.  This
feature doesn't seem to be very useful.  If someone asks, I'll
check on Hackage to see if anyone is using it.

Also added some useful extra debug info.

Fixes #4020 and #4017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

In 1.24, installedPkgs contained only references to the external package
database, not any internal libraries. In particular, when we built a
dynamically linked executable, installedPkgs did NOT have a reference to
the internal library; instead, depLibraryPaths has a special case
(hasInternalDeps) to add the final libdir to the RPATH.

In HEAD, after 0d15edef

, we started adding internal libraries (with the
INPLACE registrations) to installedPkgs to fix #2971.  But depLibraryPaths
was not updated, which means that the inplace registrations got picked
up and added to the RPATH, resulting in bad temporary directories
showing up in RPATHs.

In this commit, we just filter out internal entries from installedPkgs
and compute the library dirs for them from scratch (this code already
existed, so no loss!)

Fixes #4025.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Previously, we unconditionally blasted in all packages, even
if our component didn't actually depend on them.
This fixes #2971.

Also, added a test T2971a which is the opposite problem; previously
we didn't bring in include-dirs from internal libraries.  That
was fixed by the previous commit.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

`--dynlibdir` indicates the directory in which dynamic libraries
are installed. By default this setting is equal to:

`$libdir/$abi`

The static libraries will still end up in:

`$libdir/$libsubdir`

With `$libsubdir/$abi` as the default directory for dynamic
libraries, dynamic libraries will by default end up in a
single shared directory (per package database). This has the
potential to reduce start-up times for dynamically linked
executable as only one RPATH per package database will be
needed.

This commit uses the functionality defined in

https://phabricator.haskell.org/D2611

to tell GHC's > 8.0.1 package database that dynamic libraries
are copied to the directories mentioned in the

`dynamic-library-dirs`

field.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This reverts commit 85a76c9d.

This reverts commit 4ea94c45.

This reverts commit c6c3f2c5.

This reverts commit 68891ce4.

This reverts commit 38dc31b2.

This reverts commit 75db3da2.

This increases our test coverage for using Cabal with GHC 7.0, 7.2
and HEAD.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Also fix a wibble in GHC's output in this case.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Similiar to dabd9d98 which made
`PackageName` opaque, this makes `Distribution.Version.Version` opaque.

The most common version numbers occuring on Hackage are 3- and
4-part versions. This results in significant Heap overhead due to
`Data.Version`'s inefficient internal representation.

So like the `PackageName` commit, this commit is a preparatory commit to
pave the way for replacing `Version`'s internal representation by a
representation with a memory footprint which can be an order of
magnitude smaller.

Finally, this also adds a new functor-like convenience function

    alterVersion :: ([Int] -> [Int]) -> Version -> Version

for modifying the version number components.

In many places, we incorrectly used allBuildInfo, which
returns all BuildInfos that are buildable, and not
necessarily the ones we are actually going to *build*.
This used to "mostly do the right thing" because we
literally edited the PackageDescription to nub out things,
so you wouldn't see non-enabled components anyway.  However
when I added support for per-component configure, I stopped
editing the PackageDescription, which meant all of these
uses were wrong.

So, I updated them to do the right thing. Note that there
are still uses of allBuildInfo in Check, but that probably
requires a closer look.

Fixes #3847.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

In the previous documentation for 'ComponentEnabledSpec', I claimed
that enabled components were buildable, as well as requested
by the user.  In the course of working on #3847, however,
I realized that I hadn't actually *checked* that the component
was buildable anywhere.  In particular, the 'ComponentDisabled'
reason was *never used*.  This mostly didn't cause problems,
however, because when we 'flattenPD' all non-buildable components
get deleted, so you basically never actually have a non-buildable
'Component'.

But it still seemed a bit silly, so I fixed it by doing this:

1) I introduce a new concept of a component being requested,
which captures the use of --enable-tests and friends.  This
does NOT imply buildability.  Renamed ComponentEnabledSpec
to ComponentRequestedSpec

2) A component is enabled if it is requested and buildable.
If you give me a Component and a ComponentRequestedSpec I
can tell you if it's enabled.  However, if you give me a
ComponentName I can't, because I have no idea if it's buildable.

3) Stopped reexporting ComponentRequestedSpec from
Distribution.Simple.LocalBuildInfo

4) Added a test for attempting to specify a non-buildable
component as a target.  The test is accepting suboptimal
output at the moment, see #3858.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This implements a new syntactic sugar: The version range operator
`^>=` which is equivalent to `>=` intersected with an
automatically inferred major upper bound.

This new syntax is only allowed for `cabal-version: >=2.0`, and
allows to describe the most common use of version
bounds more conveniently:

    build-depends: foo ^>= 1.2.3.4,
                   bar ^>= 1

The declaration above is exactly equivalent to

    build-depends: foo >= 1.2.3.4 && < 1.3,
                   bar >= 1 && < 1.1

This also helps with the issue of the wildcard operator having the
surprising effect that e.g. `== 1.0.*` does not include the single 
digit version `1`.

The `^`-symbol was chosen because it can serve as a mnemonic when the
`>` sign is rotated and interpreted as "less than ceiling"

Moreover, `^` appears to become a quasi-standard to denote morally
equivalent operator that way in other language ecosystems which similiar
to Haskell have adopted semantic versioning:

 - Node: https://nodesource.com/blog/semver-tilde-and-caret/
 - Bower: https://bower.io/docs/api/#install
 - PHP: https://getcomposer.org/doc/articles/versions.md#caret

Ruby, on the other hand, uses a Tilde operator (`~>`) for that
purpose (but with a less robust semantic):

 - https://blog.codeship.com/optimists-guide-pessimistic-library-versioning

And Python is currently planing to use an `~=` operator:

 - https://www.python.org/dev/peps/pep-0440/#compatible-release

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Described in: https://github.com/ghc-proposals/ghc-proposals/pull/4



./Setup configure now takes an argument to specify a specific
component name that should solely be configured.

Most of the gyrations in Configure are all about making it so that
we can feed in internal dependencies via --dependency.

I dropped the package name match sanity check to handle convenience
library package name munging.  Consider an internal library named
'q' in package 'p'.  When we install it to the package database,
we munged the package name into 'z-p-z-q', so that it doesn't
conflict with the actual package named 'q'.  Now consider when
we feed it in with --dependency q=p-0.1-hash-q.  Previously,
Cabal checked that the 'q' in --dependency matched the package
name in the database... which it doesn't. So I dropped the check.

I also had to make register/copy unconditionally install internal
libraries; otherwise you can't refer to them from later builds.

Also a miscellaneous refactor: convenience libraries are printed with a
"header" stanza now (not really a stanza header).

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Modules that are built automatically at setup, like Paths_PACKAGENAME or others created with a build-type custom, appear on 'other-modules' for the Library, Executable, Test-Suite or Benchmark stanzas or also on 'exposed-modules' for libraries but are not really on the package when distributed. This makes commands like sdist fail because the file is not found, so with this new field modules that appear there are treated the same way as Paths_PACKAGENAME was and there is no need to create complex build hooks.
Just add the module names on 'other-modules' and 'exposed-modules' as always and on the new 'autogen-modules' besides.

The big change here is that most of the functions in
Distribution.Types.HookedBuildInfo have to take a
PackageDescription explicitly.  I hate the new type,
so I primed these new functions, and added functions
which use 'localPkgDescr'.  Presently those have WARNINGs
attached to them so people don't accidentally use them;
once we fix 'HookedBuildInfo' we can change this.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This is an omnibus patch, with the overall goal of making
LocalBuildInfo Great Again.  The essential ideas:

* New type 'TargetInfo' which bundles together 'ComponentLocalBuildInfo'
  and 'Component'.  Eventually, it will also record file paths / module
  targets.  This data structure is basically what you want; a lot of
  old Cabal code did lots of gyrations converting from
  'ComponentLocalBuildInfo' to 'Component' and vice versa, now
  it's all centralized.

* The "new" API for 'LocalBuildInfo' is in
  "Distribution.Types.LocalBuildInfo".  The general principle
  is, where we previous dealt in 'ComponentLocalBuildInfo',
  we now deal in 'TargetInfo'.  There are shockingly few
  functions we need!

* I've restored 'componentsConfigs' to its Cabal 1.24 signature
  for BC.

* I killed a number of unused functions from "Distribution.Simple.LocalBuildInfo":
  'getLocalComponent', 'maybeGetDefaultLibraryLocalBuildInfo',
  'maybeGetComponentLocalBuildInfo', 'checkComponentsCyclic' and
  'enabledComponents'.  For each I checked on Hackage that they were
  not used.

* 'getComponentLocalBuildInfo', 'withComponentsInBuildOrder' and
  'componentsInBuildOrder' are deprecated to encourage people
  to instead use the 'TargetInfo's to finger which components
  they want built.

* 'ComponentLocalBuildInfo' now stores internally the computed
  'componentInternalDeps', so that 'LocalBuildInfo' can simply store
  a graph of 'ComponentLocalBuildInfo'.

* The code in Configure has been streamlined to use our new Graph
  data type to great success.

* The type of 'runTest' changed to take a 'ComponentLocalBuildInfo',
  bringing it more in line with everything else.

* New function 'readTargetInfos' which combines 'readBuildTargets'
  and 'checkBuildTargets', which is what you really wanted anyway.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This implements the flag `--allow-older` which is the analogous to
`--allow-newer` acting on lower bounds.

The resulting code is more verbose, but it is more backwards-compatible
and actually is simpler to understand in some cases (because
CLibName uniquely identifies the "public library"; no faffing
about with package names to figure it out.)

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>