GitLab

Added tests for this case, as well as some more.  This
probably breaks the Windows build.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

The flag --skip-shared-library-tests allows the tests to run when
shared libraries are unavailable, such as during the AppVeyor build.

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

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

GHC 8.0 is switching the state sponsored way to specify
linker names from -this-package-key to -this-unit-id, so
it behooves us to use the right one.  But it didn't make
much sense to pass ComponentIds to a flag named UnitId,
so I went ahead and finished a (planned) refactoring
to distinguish ComponentIds from UnitIds.

At the moment, there is NO difference between a ComponentId
and a UnitId; they are identical.  But semantically, a
component ID records what sources/flags we chose (giving us enough
information to typecheck a package), whereas a unit ID records
the component ID as well as how holes were instantiated
(giving us enough information to build it.)  MOST code
in the Cabal library wants unit IDs, but there are a few
places (macros and configuration) where we really do
want a component ID.

Some other refactorings that got caught up in here:

    - Changed the type of componentCompatPackageKey to String, reflecting the
      fact that it's not truly a UnitId or ComponentId.

    - Changed the behavior of CURRENT_PACKAGE_KEY to unconditionally
      give the compatibility package key, which is actually what you
      want if you're using it for the template Haskell trick.  I also
      added a CURRENT_COMPONENT_ID macro for the actual component ID,
      which is something that the Cabal test-suite will find useful.

    - Added the correct feature test for GHC 8.0 ("Uses unit IDs").
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

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>

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

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

I've rewritten the test suite to be more concise and "correct by
construction".  The primary method that this is achieved by
is introducing the 'TestM' monad, which carries around the
important state for the tests so that (1) we don't have to
pass it as an argument all around, and (2) we can automatically
make the correct decisions about how to do things.  This new
method emphasises "configuration by convention": we assume
that a test-case named "Foo" has its test packages in the
directory "tests/PackageTests/Foo".

A secondary change is that all command functions automatically fail if
they have a non-zero exit code (unless you use the 'shouldFail'
combinator which inverts the sense.)  This saves a lot of typing
on test-cases.  (In fact, I've reorganized all of the commands
related here.)

In the process, I've tightened up the logic for how to find the
LocalBuildInfo of the Cabal we've testing, so we should now
reliably be testing the inplace Cabal library, and not the
system library (as was often the case.)

Because things are a lot shorter, there is no good reason to
make Check modules except for the biggest test cases.  Most
test-cases have been folded into PackageTests.Tests; if you
have a small test-case you should just put it there.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

This mode implements #2911, and allows to connect the test runner
directly to stdout/stdin. This is more reliable in the presence of no
threading, i.e. a work-arond for #2398.

I make the test suite use this, so that it passes again, despite
printing lots of stuff. Once #2398 is fixed properly, the test suite
should probably be extended to test all the various --show-details
modes.

The test case is changed to print a rather large amount of text, large
enough to fill a buffer. This way, the buffer draining functionality in
the test runner is tested, and it reveals #2398.

This makes the test suite currently fail, of course, but the bug was
there before.

Today in Cabal, when you build and install a package, it is
uniquely identified using an InstalledPackageId which is computed
using the ABI hash of the library that was installed.  There
are few problems with doing it this way:

    - In a Nix-like world, we should instead uniquely identify
      build products by some sort of hash on the inputs to the
      compilation (source files, dependencies, flags).  The ABI
      hash doesn't capture any of this!

    - An InstalledPackageId suggests that we can uniquely identify
      build products by hashing the source and dependencies of
      a package as a whole.  But Cabal packages contain many components:
      a library, test suite, executables, etc.  Currently, when
      we say InstalledPackageId, we are really just talking about
      the dependencies of the library; however, this is unacceptable
      if a Cabal package can install multiple libraries; we need
      different identifiers for each.

    - We've also needed to compute another ID, which we've called
      the "package key", which is to be used for linker symbols
      and type equality GHC-side.  It is confusing what the distinction
      between this ID and InstalledPackageIds are; the main reason
      we needed another ID was because the package key was needed
      prior to compilation, whereas the ABI hash was only available
      afterwards.

This patch replaces InstalledPackageId and PackageKey with a
new identifier called ComponentId, which has the following
properties:

    - It is computed per-component, and consists of a package
      name, package version, hash of the ComponentIds
      of the dependencies it is built against, and the name
      of the component.  For example, "foo-0.1-abcdef" continues
      to identify the library of package foo-0.1, but
      "foo-0.1-123455-foo.exe" would identify the executable,
      and "foo-0.1-abcdef-bar" would identify a private sub-library
      named bar.

    - It is passed to GHC to be used for linker symbols and
      type equality.  So as far as GHC is concerned, this is
      the end-all be-all identifier.

    - Cabal the library has a simple, default routine for computing
      a ComponentId which DOES NOT hash source code;
      in a later patch Duncan is working on, cabal-install can
      specify a more detailed ComponentId for a package
      to be built with.

Here are some knock-on effects:

    - 'id' is a ComponentId

    - 'depends' is now a list of ComponentIds

    - New 'abi' field to record what the ABI of a unit is (as it is no longer
      computed by looking at the output of ghc --abi-hash).

    - The 'HasInstalledPackageId' typeclass is renamed to
      'HasComponentId'.

    - GHC 7.10 has explicit compatibility handling with
      a 'compatPackageKey' (an 'ComponentId') which is
      in a compatible format.  The value of this is read out
      from the 'key' field.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Prior to this patch, the testsuite used your global package db, and
sometimes, the inplace package db, which led to errors if you didn't
have old-time installed globally. They looked like this:

BuildDeps/SameDepsAllRound:          Cabal result was Result {successful = False, success = Failure, outputText = "\"/home/enolan/cabal/Cabal/tests/Setup configure --user -w  /home/enolan/.nix-profile/bin/ghc\" in PackageTests/BuildDeps/SameDepsAllRound\nConfiguring SameDepsAllRound-0.1...\nSetup: At least the following dependencies are missing:\nold-time -any\n"}

When running the `strip` command (without the -D option) on an installed
.a file, `strip` will write the current time to all file headers in the
.a file. Update the DeterministicAr test to allow this.

The DeterministicAr test is supposed to test for regressions in
relinking avoidance. It is sufficient to do so in the build directory
only.

Fixes #2489. The detailed-0.9 test suite runner would deadlock because
the IO manager was not draining the output pipe of the child
process. Thanks to @r0ml for the patch.

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

In GHC 7.10, Cabal always generate package keys, including in
cases where Backpack was involved (e.g. --instantiated-with).
In fact, in these case, GHC needs to be able to generate the
package key (because it will often make a substitution on the
instantiation, and needs to know if this identity coincides with
anything else we've seen previously).

Thus, we introduce a new notion, the 'LibraryName', which
is JUST the non-Backpack portion of a package key.  For ordinary
packages that are definite, a 'LibraryName' is simply
the 'PackageId' plus 'PackageKey'; for indefinite Backpack packages,
when a package gets instantiatied, it may end up with different
'PackageKey's even though the 'LibraryName' stays the same.
'LibraryName's can be computed purely by Cabal.

This patch:

    - Defines library name, which are the source package ID plus
      a hash of all the source package ID and the library names of external,
      textual dependencies,

    - Redefines the package key to be JUST the hash portion of a
      library name, in the case that Backpack is not used,

    - Records the library name in InstalledPackageInfo.

Note: the source package ID is included both externally (so the library
name is a useful handle to refer to package) and internally (so the
hash can stand alone as the package key.)

A major refactoring which is part of this commit is moving package keys/library
names from LocalBuildInfo to LibComponentBuildInfo.  If you have an LBI, you can
still extract a package key/library name using the new
localPackageKey/localLibraryName function (which looks through the
ComponentBuildInfos of a LocalBuildInfo for the library in question).  This is
conceptually cleaner for two reasons:

    1. Only dependencies of the *library* are counted as part
    of the library name, as opposed to *all* dependencies which
    we previously used.

    2. A library name doesn't really mean much for an executable,
    or a test suite, since no one else will have to link against
    them.  So we can fall back on something simpler.

A more minor refactoring is the 'LibraryName' type, which was
previously defined by LocalBuildInfo and generally looked something
like "HSprocess-0.1-XXXX".  We change the meaning of 'LibraryName'
to be "process-0.1-XXXX" (thus we have to insert some HS additions
in the code) and eliminate componentLibraries, thus assuming that
there is only ONE Haskell library (which was the case.)  So
we remove a little bit of generality and in return get code
that is much easier to read.  (The only downside is GHC's hack
to split DLLs into multiples has to be adjusted slightly, but
this is not a big price to pay.)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Add functionality to allow preprocessors like hsc2hs and C2HS to inform
Cabal of extra C sources that they create that need to be compiled and
linked.  Includes hsc2hs-based test case.

Starting with version 7.10, GHC puts the module interface (.mix) files
for each project in a subdirectory of -hpcdir named for the package
key. We must adjust the search path accordingly when checking for the
.mix file.

- make some paths non-global via / prefix
- remove redundancies
- add /Cabal/Setup and /cabal-install/Setup

Some package tests run multiple tests on the same package, causing the
build directory to be overwritten. For debugging, it is important to
keep the build directory contents, so in this case we run each test
with a different build directory.

It doesn't make any sense to do a profiling build of an executable if
the library doesn't have a profiled build! The option
--enable-executable-profiling is changed to --enable-profiling to
reflect that it is now a global flag. The old option is still recognized
(for now).

Dynamically linking executables will fail without a shared library
unless the executables do not depend on the library or there is no
library. If there is no library, building shared libraries comes at no
cost. If there is a library, the executables usually depend on it, so it
makes sense to --enable-shared.

If the user passes --disable-shared, it will still be honored, but a
warning will be produced.