summaryrefslogtreecommitdiff
path: root/utils/ghc-pkg
Commit message (Collapse)AuthorAgeFilesLines
* Tidy up cross-compilingSimon Marlow2013-01-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have two cases: 1. building a cross-compiler 2. compiling GHC to run on a foreign platform These two are done with almost the same setup: (1) is the stage 1 compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES. The only difference between (1) and (2) is that you if you set up the build for (1), then it stops before stage 2 and you can 'make install' to install stage 1. Unfortunately, (2) didn't work, and the build system code needed some tidying up. Change to the way the build is set up: Before ------ To build a cross-compiler: ./configure --target=<..> To compile a foreign GHC: ./configure --host=<..> --target=<..> Now --- To build a cross-compiler: ./configure --target=<..> And set "Stage1Only=YES" in mk/build.mk To compile a foreign GHC: ./configure --target=<..>
* Update dependenciesIan Lynagh2012-11-301-1/+1
|
* Make ghc-pkg print less on error.Ben Millwood2012-11-301-5/+6
|
* fix typo, courtesy of Jon Cave, thanks!Gabor Greif2012-11-081-1/+1
|
* Fix a makefile ruleIan Lynagh2012-10-291-1/+1
|
* Move ghc-pkg's generated Version.hs inside the dist directoriesIan Lynagh2012-10-291-6/+9
|
* Make "ghc-pkg check" check for prof and dyn ways, as well as vanillaIan Lynagh2012-10-251-17/+23
| | | | | In particular, this fixes it if we are using dynamic libraries by default and don't build the vanilla way.
* Remove an outdated commentIan Lynagh2012-10-251-1/+1
|
* ghc-pkg: Print something when no packages are found; fixes #6119Ian Lynagh2012-10-111-1/+4
| | | | | | | | | | We used to say $ ghc-pkg list blargle /usr/local/lib/ghc-7.4.1/package.conf.d which may imply that blargle was found in /usr/local/lib/ghc-7.4.1/package.conf.d
* Tweak the build system handling of shell wrappersIan Lynagh2012-09-271-1/+1
| | | | | | | Rather than having a separate foo_INSTALL_SHELL_WRAPPER variable, we just use foo_INSTALL && foo_SHELL_WRAPPER
* Update dependency on directory.Paolo Capriotti2012-09-091-1/+1
|
* make sure to remove the right link before calling 'ln -s' (could we use 'ln ↵Gabor Greif2012-08-301-2/+2
| | | | -sf'?)
* ghc-pkg: restore -no-user-package-conf flag.Paolo Capriotti2012-07-181-0/+2
|
* improve the --help docs a bit (#7008)Simon Marlow2012-07-021-4/+6
|
* Accept -package-conf so cabal-install worksIan Lynagh2012-05-271-1/+1
| | | | | Really we ought to support all the old flags, but warn that they are deprecated.
* Don't use stdcall on Win64: It isn't supported; ccall is used insteadIan Lynagh2012-05-161-1/+11
|
* Rename package-conf flags to package-db.Paolo Capriotti2012-05-153-14/+14
| | | | | | | | Rename package database flags in both GHC and ghc-pkg so that they are consistent with Cabal nomenclature. Add a version check to the build system so that the correct set of package db flags are used when the bootstrapping GHC has version < 7.5.
* Add SRC_[CH]C_WARNING_OPTSIan Lynagh2012-04-261-0/+1
| | | | | | | | | | | This allows you to say things like SRC_HC_WARNING_OPTS += -fno-warn-unsupported-calling-conventions in mk/validate.mk. Unfortunately, we can't just use SRC_HC_OPTS, as that gets put before the more specific options (e.g. ghc-options in a .cabal file), many of which include -Wall. So now we have: ghc $(SRC_HC_OPTS) ... options from .cabal etc ... $(SRC_HC_WARNING_OPTS)
* ghc-pkg: make sure info messages go to stdout and errors to stderr (#3818)Paolo Capriotti2012-03-081-30/+40
|
* GHC trees no longer include the extensible-exceptions packageIan Lynagh2012-02-211-1/+0
|
* Improve support for cross-compilationSimon Marlow2012-01-301-11/+22
| | | | Patchset from Stephen Blackheath <stephen.blackheath@ipwnstudios.com>
* Improve the way we call "rm" in the build system; fixes trac #4916Ian Lynagh2011-11-191-5/+5
| | | | | | | | | | We avoid calling "rm -rf" with no file arguments; this fixes cleaning on Solaris, where that fails. We also check for suspicious arguments: anything containing "..", starting "/", or containing a "*" (you need to call $(wildcard ...) yourself now if you really want globbing). This should make things a little safer.
* Follow cabal->Cabal rename, and fix haddock index generationIan Lynagh2011-10-231-1/+1
| | | | We now make use of the ghc-packages file when making the haddock index.
* add a ToDoSimon Marlow2011-09-211-0/+3
|
* Fix validation problem when GHC is 7.2.1, warnings from binary.David Terei2011-08-191-1/+1
|
* Relax some dependenciesIan Lynagh2011-07-081-1/+1
|
* Follow Cabal reorganisation, and improve build system a littleIan Lynagh2011-06-231-1/+1
|
* Fix ghc-pkg's quoting of the pkgroot fieldIan Lynagh2011-06-191-1/+1
|
* SafeHaskell: Add trust flag to packagesDavid Terei2011-06-171-2/+20
|
* Fix parsing "$topdir" in package configIan Lynagh2011-06-101-18/+20
| | | | It was only working when followed by something, e.g. "$topdir/base".
* Fix buildIan Lynagh2011-06-091-1/+1
|
* Fix for $topdir appearing in the haddock-html fieldDuncan Coutts2011-06-091-1/+2
| | | | | I'd naively assumed that the haddock-html field would only use the $httptopdir variable. Hopefully this will fix the windows build.
* ghc-pkg: report parser warnings when registering packagesDuncan Coutts2011-05-251-4/+11
|
* Provide the pkgroot value in ghc-pkg dump & describe when necessaryDuncan Coutts2011-05-251-40/+84
| | | | | | | | | | | | | | | | | | | | | | Tools handling installed packages need to be able to interpret the paths which are relative to the ${pkgroot} which means they need to know the value of ${pkgroot}. With ghc-pkg this is not always obvious since ghc-pkg does not currently have any way machine interface for reporting the location of its package dbs (global, user). The solution we have arrived at is simply to emit the pkgroot as an extra field when it is needed. There are two cases: * --no-expand-pkgroot: ghc-pkg dump/describe will not expand the ${pkgroot} var, so it will appear literally in the output and the pkgroot field will be generated so that tools know what value to use for the ${pkgroot}. * --expand-pkgroot: ghc-pkg dump/describe will expand the ${pkgroot} and ${pkgrooturl} vars and will not generate the pkgroot field. The defaults are: * ghc-pkg dump/describe --no-expand-pkgroot * ghc-pkg field --expand-pkgroot
* Add stricter ghc-pkg checks on package file/dir/url fieldsDuncan Coutts2011-05-251-10/+25
| | | | | | | The haddock-html and haddock-interface fields are now checked as well. Had to fix up ghc-cabal as it used relative paths for the inplace package's haddock-html. It turns out that these were never used so it could simply be omitted.
* Implement ${pkgroot} spec, allows relocatable registered packagesDuncan Coutts2011-05-251-51/+100
| | | | | | | | | | | | | | Historically ghc implemented relocatable packages by allowing "$topdir" in the package registration info and having ghc expand this with its notion of $topdir. The topdir refers to where ghc itself is installed (specifically the libdir). The ${pkgroot} spec takes this idea and makes it portable. (http://www.haskell.org/pipermail/libraries/2009-May/011772.html) Instead of paths relative to where ghc is installed, they can be relative to the package database itself. Thus it is no longer a ghc-specific idea and can work for package collections other than the global package db.
* Deprecate the ghc-pkg --auto-ghci-libs flagDuncan Coutts2011-05-251-0/+3
| | | | | | It was never a universal solution. It only worked with the GNU linker. It has not been used by Cabal for ages. GHCi can now load .a files so it will not be needed in future.
* ghc-pkg: don't expand ${name}-style env vars by defaultDuncan Coutts2011-05-251-4/+12
| | | | | | | | | | | | | For shell-based build systems the feature is still available as: ghc-pkg register --expand-env-vars Historically, ghc-pkg allowed environment variables to appear in the input files for ghc-pkg register. They are not stored in the package database but are expanded upon registration. This feature helped for build systems based on makefiles and shell scripts. These days the vast majority of such files are generated by Cabal and we don't want any ${name} strings (e.g. perhaps in a package description) getting accidentally interpreted as an environment variable.
* Unicode fixes, taking into account PEP383 supportMax Bolingbroke2011-05-141-10/+11
|
* ghc-pkg dependency on ghc-cabal should be an order-only dependency,Simon Marlow2011-04-111-2/+4
| | | | otherwise we repeatedly try to rebuild ghc-pkg if ghc-cabal is newer.
* Add NondecreasingIndentation to the list of extensions in ghc-pkgIan Lynagh2011-01-171-1/+1
|
* On Cygwin, use a Cygwin-style path for /bin/install's destinationIan Lynagh2011-01-061-1/+1
| | | | | | | | | | | | | | | | | cygwin's /bin/install doesn't set file modes correctly if the destination path is a C: style path: $ /bin/install -c -m 644 foo /cygdrive/c/cygwin/home/ian/foo2 $ /bin/install -c -m 644 foo c:/cygwin/home/ian/foo3 $ ls -l foo* -rw-r--r-- 1 ian None 0 2011-01-06 18:28 foo -rw-r--r-- 1 ian None 0 2011-01-06 18:29 foo2 -rwxrwxrwx 1 ian None 0 2011-01-06 18:29 foo3 This causes problems for bindisttest/checkBinaries.sh which then thinks that e.g. the userguide HTML files are binaries. We therefore use a /cygdrive path if we are on cygwin
* Replace uses of the old try function with the new oneIan Lynagh2010-12-181-4/+6
|
* Replace uses of the old catch function with the new oneIan Lynagh2010-12-181-6/+6
|
* Remove more dead code now we require GHC >= 6.12Ian Lynagh2010-12-151-71/+3
|
* Remove the no-ghci-lib warning in ghc-pkgIan Lynagh2010-11-271-7/+4
| | | | | GHCi libs are no longer necessary, as we can use the .a or .so versions instead.
* Remove ghc-pkg's dependency on haskell98Ian Lynagh2010-10-132-4/+1
|
* Fix build on Windows: ghc-pkg/Main.hs needs ForeignFunctionInterfaceIan Lynagh2010-10-121-1/+1
|
* Fix build following haskell98 and -fglasgow-exts changesIan Lynagh2010-10-061-1/+1
|
* Bump dependenciesIan Lynagh2010-09-171-1/+1
|
View Lorry Controller Status