aboutsummaryrefslogtreecommitdiffhomepage
path: root/Makefile
Commit message (Collapse)AuthorAge
* exclude Setup.hs from buildGravatar Ross Paterson2006-08-24
|
* [project @ 2005-07-21 12:54:33 by simonmar]Gravatar simonmar2005-07-21
| | | | | | | | | | | Hack Makefiles so that 'make distclean' works even if the tree has not been configured, or 'make distclean' has already been run. This is to solve problems caused by 'make distclean' removing files that it needs itself - previously we were arranging to remove certain files right at the end of cleaning, but this is fragile. So now we assume that e.g. the X11 library is always enabled when we're cleaning.
* [project @ 2005-03-02 16:39:57 by ross]Gravatar ross2005-03-02
| | | | *Config.h files are in include/ (MERGE to STABLE)
* [project @ 2005-03-02 14:46:16 by simonmar]Gravatar simonmar2005-03-02
| | | | distcleaning of things generated by configure
* [project @ 2004-11-26 16:22:12 by simonmar]Gravatar simonmar2004-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Further integration with the new package story. GHC now supports pretty much everything in the package proposal. - GHC now works in terms of PackageIds (<pkg>-<version>) rather than just package names. You can still specify package names without versions on the command line, as long as the name is unambiguous. - GHC understands hidden/exposed modules in a package, and will refuse to import a hidden module. Also, the hidden/eposed status of packages is taken into account. - I had to remove the old package syntax from ghc-pkg, backwards compatibility isn't really practical. - All the package.conf.in files have been rewritten in the new syntax, and contain a complete list of modules in the package. I've set all the versions to 1.0 for now - please check your package(s) and fix the version number & other info appropriately. - New options: -hide-package P sets the expose flag on package P to False -ignore-package P unregisters P for this compilation For comparison, -package P sets the expose flag on package P to True, and also causes P to be linked in eagerly. -package-name is no longer officially supported. Unofficially, it's a synonym for -ignore-package, which has more or less the same effect as -package-name used to. Note that a package may be hidden and yet still be linked into the program, by virtue of being a dependency of some other package. To completely remove a package from the compiler's internal database, use -ignore-package. The compiler will complain if any two packages in the transitive closure of exposed packages contain the same module. You *must* use -ignore-package P when compiling modules for package P, if package P (or an older version of P) is already registered. The compiler will helpfully complain if you don't. The fptools build system does this. - Note: the Cabal library won't work yet. It still thinks GHC uses the old package config syntax. Internal changes/cleanups: - The ModuleName type has gone away. Modules are now just (a newtype of) FastStrings, and don't contain any package information. All the package-related knowledge is in DynFlags, which is passed down to where it is needed. - DynFlags manipulation has been cleaned up somewhat: there are no global variables holding DynFlags any more, instead the DynFlags are passed around properly. - There are a few less global variables in GHC. Lots more are scheduled for removal. - -i is now a dynamic flag, as are all the package-related flags (but using them in {-# OPTIONS #-} is Officially Not Recommended). - make -j now appears to work under fptools/libraries/. Probably wouldn't take much to get it working for a whole build.
* [project @ 2004-09-15 15:55:45 by stolz]Gravatar stolz2004-09-15
| | | | | | | | | Add System.Posix.Signals.Exts which re-exports S.P.Signals and adds the two signals SIGINFO on (*BSD) and SIGWINCH (most Unices) which are not in POSIX. You should use cpp to test if those are defined before using them. This is encouraged by not providing dummy-definitions on platforms which do not offer that particular flavour.
* [project @ 2003-11-10 15:32:45 by simonmar]Gravatar simonmar2003-11-10
| | | | Change the documentation title from "Haskell Core Libraries" to "Haskell Hierarchical Libraries".
* [project @ 2003-06-19 10:47:25 by simonmar]Gravatar simonmar2003-06-19
| | | | | | Remove Network.Sendfile at request of Volker Stolz. We currently have some build problems with it (it depends on both unix and network packages). It might come back at some point in the future.
* [project @ 2003-06-10 10:58:06 by simonmar]Gravatar simonmar2003-06-10
| | | | Move Network.Sendfile into the unix package to fix the build.
* [project @ 2003-05-23 18:35:55 by stolz]Gravatar stolz2003-05-23
| | | | Need flags here as well.
* [project @ 2003-05-21 16:02:44 by stolz]Gravatar stolz2003-05-21
| | | | | | Solaris2 needs _POSIX_PTHREAD_SEMANTICS for the getpw*_r() prototypes. Make libraries/unix/Makefile use a new variable unix_SRC_HSC2HS_OPTS which we configure in mk/config.mk.
* [project @ 2003-05-16 06:41:25 by stolz]Gravatar stolz2003-05-16
| | | | | | | | | - move System.DL to System.Posix.DynamicLinker - take ownership There's a compiler warning when passing the 'const char*' result from dlerror() to peekCString (discarded qualifier). Does an FFI-expert know how to get rid of this warning?
* [project @ 2003-03-03 01:51:58 by stolz]Gravatar stolz2003-03-03
| | | | Import System/DL*
* [project @ 2003-01-17 17:01:14 by stolz]Gravatar stolz2003-01-17
| | | | | | - Add sendfile-API for pumping out data via sendfile(2) Currently supported are Linux (tested) & FreeBSD (not tested yet), others will throw a runtime error until I get around to implement a fallback.
* [project @ 2002-09-12 16:38:21 by simonmar]Gravatar simonmar2002-09-12
| | | | More POSIX bits... we're getting there.
* [project @ 2002-09-10 20:54:33 by panne]Gravatar panne2002-09-10
| | | | No prologue.txt, no -p...
* [project @ 2002-09-06 14:34:15 by simonmar]Gravatar simonmar2002-09-06
Partial rewrite of the POSIX library. The main purpose of this sweep is to remove the last dependencies of the compiler on hslibs. When I've committed the associated compiler changes, only the 'base' package will be required to bootstrap the compiler. Additionally to build GHCi, the 'readline' and 'unix' packages will be required. The new POSIX library lives mostly in libraries/unix, with a few bits required for compiler bootstrapping in libraries/base. The 'base' package is mostly free of hsc2hs code to make bootstrapping from HC files easier, but the 'unix' package will use hsc2hs liberally. The old POSIX library continues to provide more-or-less the same interface as before, although some of the types are more correct now (previously lots of POSIX types were just mapped to Int). The new interface is largely the same as the old, except that some new functionality from the latest POSIX spec has been added (eg. symbolic links). So far, the new POSIX library has signal support, directory/file operations and lots of stuff from unistd.h. The module names are: System.Posix The main dude, exports everything System.Posix.Types All the POSIX types, using the same naming scheme as Foreign.C.Types, Eg. CUid, COff, etc. Many of these types were previously exported by GHC.Posix. Additionally exports the "nicer" names used by the old POSIX library for compatibility (eg. ProcessID == CPid, FileMode == CMode, etc.) All reasonable instances are derived for these types. System.Posix.Signals Signal support, contains most of which was in PosixProcPrim before. The RTS interface to the signal handling support has been rationalised slightly. System.Posix.Directory Directory support, most were in PosixFiles before. System.Posix.Files File operations, most were in PosixFiles before. System.Posix.Unistd (for want of a better name) Miscellaneous bits that mostly come from the unistd.h header file. PosixProcEnv before. The rest of the library should pan out like so: System.Posix.IO System.Posix.Error (maybe) System.Posix.Process System.Posix.Terminal (I've no doubt broken Win32 support, but I'm checking the build at the moment).