The fptools version of this package needs different Makefiles, so add them and remove the original GNUmakefiles.
* Isaac added a warning to haddock for Hooks Krasimir: the "data-files" field may contain filenames with directories. We should create the missing directories at install place first Use removeDirectoryRecursive instead of system "rm ..." because the former is more platform idependent. The sdist command was broken because it is using smartCopySources. The later was using the hs-source-dirs for lookup but at the target place the files were created without the corresponding source sub directories. Now it have boolean parameter which specifies whether to preserve to directory structure.
… a "make validate"
I throw a parse error if this package has the wrong cabal version. This is so that the user can get this error before getting an error for eg. an unknown field. Also check it in the sanity checker. I just hard-code the cabal version in the source, it would be nicer if we got it from the .cabal file. cabal could include the version in the cpp flags, but cabal's setup file needs to build without cabal, so that wouldn't actually work for us ahem.
…n a single step.
If the user configures with --user, that means that they are willing to satisfy dependencies from the user databaes. If that's the case, then it really only makes sense to install the package as --user as well, since if user A installs configures / builds the package with --user, then installs it as root, user B may attempt to use the package and not be able to fulfill the dependencies. Therefore, if the package is configured as --user, then we also will call ghc-pkg with --user. Of course, in this case: ./setup configure --user ./setup install --global Cabal will accept the user's instructions to install this globally, however ill conceived. This changes the type of the install hook, btw, since we now need to be able to tell the difference between passing the --global flag and not passing any flag. Any objections to this change?
This allows users to add programs to the list of programs that configure looks for. If a user adds a program with this hook, configure will try to find it, and arguments will be added to configure for this program. See test/withHooks for an example.
I added a test case. I'm a bit concerned about munging the modules by adding a 'hidden' pragma here, but it doesn't seem to cause a problem.
Have an unknown error while building "execWithC" for Hugs: Cases: 11 Tried: 0 Errors: 0 Failures: 0Setup.lhs: Warning: No license-file field. Setup.lhs: Warning: No license-file field. dist/build/programs/tt/Main.c: In function 'hugsprim_foo_0': dist/build/programs/tt/Main.c:16: warning: implicit declaration of function 'foo' runhugs: Error occurred ERROR ",tmp/lib/hugs/programs/tt/Main.hs" - Error while importing DLL "/home/ijones/usr/src/haskell/fptools/libraries/Cabal/tests/exeWithC/,tmp/lib/hugs/programs/tt/Main.so": /home/ijones/usr/src/haskell/fptools/libraries/Cabal/tests/exeWithC/,tmp/lib/hugs/programs/tt/Main.so: unexpected reloc type 0x09
…e than one executable block. Without this patch all executables go to void.
* Ross ghcconfig.h is not needed for GHC >= 6.4 update library links for haddock 0.7 (in Cabal.xml) * Krasimir * The sentence: An error will be returned from <literal>setup configure</literal> if this is not the case. is replaced with: If this is not the case then the compiled executable will have baked in all absolute paths. * The previous implementation for Paths_<pkgid>.hs building was broken on Windows. The prefixRel function was expecting that all bindir/libdir/datadir/... paths are $prefix relative but the corresponding functions (mkBinDir/mkLibDir/...) was returning absolute paths with expanded $path variable. This commit fixes the bug and also: * In LocalBuildInfo are added mkLibDirRel/mkBinDirRel/... functions. They return the corresponding but without the $prefix part. When the path isn't prefix relative then they return Nothing * The restriction that all paths on Windows are $prefix relative is removed. * The code in Paths_<pkgid>.hs can contain both absolute and prefix relative paths. When the package is configured only with $prefix relative paths then the generated executable will be prefix independent and can be moved from one directory to another. * Paths_<pkg>.hs was generated before each build and this was causing GHC to rebuild the package each time. Now it is generated only when it is older than .setup-config * Change the foreign import syntax to use the standard FFI syntax * Two changes to HADDOCK support: - In the last version only the exposed modules were passed to haddock. In order to generate proper documentation all modules should be processed from haddock but the non exposed modules should be hiden. - Added support for executable packages in Haddock.
from Neil Mitchell (fixed by Krasimir): On Windows, the path can be path;"c:\ghc\ghc-6.4\bin";restofpath, and thats still a valid path with GHC in it. Cabal doesn't find ghc with the quotes in, removing them does find it though. SimonMar: Add Distribution.Program to exposed-modules