summaryrefslogtreecommitdiff
path: root/utils/ghc-pkg
Commit message (Collapse)AuthorAgeFilesLines
* When verbose, give more information about cache statusIan Lynagh2013-05-301-17/+35
|
* Small refactoring in ghc-pkgIan Lynagh2013-04-281-6/+4
|
* Remove some old "backwards compatibility" codeIan Lynagh2013-04-281-24/+4
| | | | | | It was marked as "backwards compatibility" in 2006, so I think can be removed now. It allowed using old field names when looking at fields with ghc-pkg.
* Make "ghc-pkg field pkg field --simple-output" do something usefulIan Lynagh2013-04-281-16/+20
| | | | It used to just ignore the --simple-output flag
* Automatically add the $(exeext) to program namesIan Lynagh2013-03-031-4/+2
| | | | | | | We now define _PROGNAME, and _PROG is automatically defined with $(exeext). This will shortly automatically use the right exeext depending on what stage it is being compiled with (exeext may be different for different stages when cross-compiling).
* Use more of the automatically generated INPLACE variablesIan Lynagh2013-03-031-1/+1
|
* Rename $(Windows) to $(Windows_Host)Ian Lynagh2013-03-011-1/+1
|
* Define utils/ghc-pkg_dist_PROG correctly for WindowsIan Lynagh2013-02-161-3/+1
|
* Build the stage0 ghc-pkg with CabalIan Lynagh2013-02-161-56/+13
| | | | | | | This solves the problem of how to define MIN_VERSION_base for the binary package. Also fixed a couple of build system bugs along the way.
* Build system tweak: Do the package checks at configure timeIan Lynagh2013-02-151-1/+1
| | | | | | | | This removes the '.PHONY' rule, so means that "make" in a built tree won't repeat the check. We also now check the .cabal files for the executables as well as the libraries.
* Stop using the deprecated System.CmdIan Lynagh2013-02-151-2/+1
|
* install ghc-pkg correctly when Stage1Only=YES (#7639)Simon Marlow2013-02-051-20/+27
|
* Try to make ghc-pkg and ghc-cabal use the same flags when bootstrapping.Simon Marlow2013-02-011-1/+0
| | | | | They share modules in Cabal, and unless they use exactly the same flags GHC recompiles the modules.
* 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.
View Lorry Controller Status