This project is mirrored from https://github.com/haskell/Cabal.
Pull mirroring updated .
- 13 Feb, 2016 2 commits
-
-
Mikhail Glushenkov authored
-
Mikhail Glushenkov authored
-
- 30 Jan, 2016 1 commit
-
-
Mikhail Glushenkov authored
-
- 25 Jan, 2016 1 commit
-
-
Mikhail Glushenkov authored
Fixes #3003.
-
- 16 Jan, 2016 1 commit
-
-
Edward Z. Yang authored
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>
-
- 08 Jan, 2016 1 commit
-
-
Edward Z. Yang authored
Instead of qualifying, in some cases I just added an extra 'hiding' pragma to squelch errors. Common conflicts (just grep for hiding): - Flag - Distribution.Simple.Compiler - Distribution.PackageDescription - Distribution.Simple.Setup - installedComponentId - Distribution.Package - Distribution.InstalledPackageInfo - doesFileExist - Distribution.PackageDescription.Check - instantiatedWith - I renamed the field in InstalledPackageInfo. But it's probably going away with Backpack bits; I migth just excise it soon. - absoluteInstallDirs and substPathTemplate - Distribution.Simple.InstallDirs - Distribution.Simple.LocalBuildInfo I fixed some shadowing errors by renaming local variables in some cases. Common shadowings (we should perhaps consider not using these as method/field names): - freeVars - components - noVersion - verbosity - get - description - name Some data structures were moved around (IPIConvert and ABIHash) to make it easier to handle import lists. Some functions in Utils could be turned into reexports of standard library functions. No explicit imports were removed from non-Cabal imports. These imports help maintain warning cleanliness across versions of GHC, so I don't recommend removing them. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
- 09 Oct, 2015 1 commit
-
-
Edward Z. Yang authored
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>
-
- 21 Jul, 2015 1 commit
-
-
Edward Z. Yang authored
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>
-
- 19 Oct, 2014 1 commit
-
-
Mikhail Glushenkov authored
Fixes #2130.
-
- 02 Feb, 2014 1 commit
-
-
Mikhail Glushenkov authored
It's just noise that duplicates information in the 'LICENSE' file.
-
- 15 Mar, 2013 1 commit
-
-
refold authored
-
- 12 Mar, 2013 1 commit
-
-
ian@well-typed.com authored
Cabal doesn't know how to build them, but it does know how to install and register them. In particular, this means that GHC's build system can use Cabal to install them.
-
- 23 Oct, 2011 1 commit
-
-
Ian Lynagh authored
Makes things a little simpler in GHC's build system if libraries are in the same directory as their name.
-
- 19 Jun, 2011 1 commit
-
-
Duncan Coutts authored
At the top level we now have cabal/ and cabal-install/
-
- 07 Jul, 2009 1 commit
-
-
Ian Lynagh authored
-
- 09 Dec, 2008 1 commit
-
-
Duncan Coutts authored
Also document the functions in the ModuleName module.
-
- 11 Aug, 2008 1 commit
-
-
Simon Marlow authored
Now when using CPP you get MIN_VERSION_<package>(A,B,C) for each <package> in build-depends, which is true if the version of <package> in use is >= A.B.C, using the normal ordering on version numbers. This is done by auto-generating a header file dist/build/autogen/cabal_macros.h, and passing a -include flag when running CPP.
-
- 28 Jun, 2008 1 commit
-
-
Duncan Coutts authored
Use cabal-devel@haskell.org as the maintainer in most cases except for a few which were pre-existing modules copied from elsewhere or modules like L.H.Extension which really belong to libraries@haskell.org Remove the useless stability module. We have more detailed information on stability elsewhere (in the version number and user guide). Add more top level module documentation, taken from the source guide.
-
- 26 Jun, 2008 2 commits
-
-
Duncan Coutts authored
-
Duncan Coutts authored
-
- 14 Jun, 2008 1 commit
-
-
Duncan Coutts authored
-
- 11 May, 2008 1 commit
-
-
Ian Lynagh authored
-
- 09 Apr, 2008 1 commit
-
-
Duncan Coutts authored
-
- 07 Apr, 2008 1 commit
-
-
Duncan Coutts authored
I broke this recently when refactoring. Restore the original behaviour. Was generating "libHSfoo_p-1.0.a" when it should be "libHSfoo-1.0_p.a".
-
- 21 Mar, 2008 3 commits
-
-
Duncan Coutts authored
This is a tad subtle since we actually have two ways of parsing compiler flavours. One expects, or at least allows lower case names like "ghc" and "nhc98", the other uses Read/Show which gives "GHC" and "NHC". What we're doing here is only changing the first variety. The cases where we parse using Read (and display using Show) are not changed. At some point we'll switch those over to the more liberal parser, but not yet as we don't want to cause compatibility problems.
-
Duncan Coutts authored
And change all uses.
-
Duncan Coutts authored
The instance for Version is in the Text module itself because the Version type is defined in base. This avoids an orphan instance.
-
- 17 Mar, 2008 1 commit
-
-
Duncan Coutts authored
So now it really gives just the lib name and not its location as well. It turned out that we more often want just the name since we're copying the same named file from one directory to another. Taking a PackageIdentifier means we do the conversion to string in one place rather than all over the place. It also means we're chaning the lib names for nhc98 to include the lib version number. This should not make any real difference to nhc98.
-
- 12 Mar, 2008 1 commit
-
-
Duncan Coutts authored
Especially instead of abusing a PackageIdentifier for the purpose.
-
- 07 Mar, 2008 1 commit
-
-
Duncan Coutts authored
(pkgName . packageId) and (pkgVersion . packageId) turn out to be very common so give them names.
-
- 04 Mar, 2008 1 commit
-
-
Duncan Coutts authored
-
- 22 Feb, 2008 1 commit
-
-
Duncan Coutts authored
Using 'packageId' seems a bit clearer that it's just the PackageIdentifier rather than 'package' which might indicate something containing more info. contain
-
- 05 Feb, 2008 1 commit
-
-
Duncan Coutts authored
New Distribution.Simple.BuildPaths module similar to the .InstallDirs module to hold all the paths and filenames used during a build. It's currently somewhat of a miscellaneous collection.
-