Fri Aug 3 14:56:32 CEST 2007 Thomas Schilling <[EMAIL PROTECTED]>
* Add documentation for Cabal Configurations.
New patches:
[Add documentation for Cabal Configurations.
Thomas Schilling <[EMAIL PROTECTED]>**20070803125632] {
hunk ./doc/Cabal.xml 129
-Name: HUnit
-Version: 1.1
-License: BSD3
-Author: Dean Herington
-Homepage: http://hunit.sourceforge.net/
-Category: Testing
-Build-Type: Simple
-Build-Depends: base
-Synopsis: Unit testing framework for Haskell
-Exposed-modules:
- Test.HUnit, Test.HUnit.Base, Test.HUnit.Lang,
- Test.HUnit.Terminal, Test.HUnit.Text
-Extensions: CPP</programlisting>
+Name: HUnit
+Version: 1.1.1
+Cabal-Version: >= 1.2
+License: BSD3
+License-File: LICENSE
+Author: Dean Herington
+Homepage: http://hunit.sourceforge.net/
+Category: Testing
+Synopsis: A unit testing framework for Haskell
+
+Library {
+ Build-Depends: base
+ Exposed-modules:
+ Test.HUnit.Base, Test.HUnit.Lang, Test.HUnit.Terminal,
+ Test.HUnit.Text, Test.HUnit
+ Extensions: CPP
+}</programlisting>
hunk ./doc/Cabal.xml 157
+Cabal-Version: >= 1.2
hunk ./doc/Cabal.xml 162
-Build-Depends: HUnit
hunk ./doc/Cabal.xml 163
-Executable: program1
-Main-Is: Main.hs
-Hs-Source-Dirs: prog1
+Executable program1 {
+ Build-Depends: HUnit
+ Main-Is: Main.hs
+ Hs-Source-Dirs: prog1
+}
hunk ./doc/Cabal.xml 169
-Executable: program2
-Main-Is: Main.hs
-Hs-Source-Dirs: prog2
-Other-Modules: Utils</programlisting>
+Executable program2 {
+ Main-Is: Main.hs
+ Build-Depends: HUnit
+ Hs-Source-Dirs: prog2
+ Other-Modules: Utils
+}</programlisting>
hunk ./doc/Cabal.xml 183
+Cabal-Version: >= 1.2
hunk ./doc/Cabal.xml 188
-Build-Depends: HUnit
-Exposed-Modules: A, B, C
hunk ./doc/Cabal.xml 189
-Executable: program1
-Main-Is: Main.hs
-Hs-Source-Dirs: prog1
-Other-Modules: A, B
+Library {
+ Build-Depends: HUnit
+ Exposed-Modules: A, B, C
+}
hunk ./doc/Cabal.xml 194
-Executable: program2
-Main-Is: Main.hs
-Hs-Source-Dirs: prog2
-Other-Modules: A, C, Utils</programlisting>
+Executable program1 {
+ Main-Is: Main.hs
+ Hs-Source-Dirs: prog1
+ Other-Modules: A, B
+}
+
+Executable program2 {
+ Main-Is: Main.hs
+ Hs-Source-Dirs: prog2
+ Other-Modules: A, C, Utils
+}</programlisting>
hunk ./doc/Cabal.xml 234
- <quote><literal>--</literal></quote> are treated as comments
- and ignored.</para>
+ <quote><literal>--</literal></quote> are treated as comments
+ and ignored.</para>
+
+ <para>This file should contain of a number global property
+ descriptions and several sections.</para>
hunk ./doc/Cabal.xml 240
- <para>This file should contain one or more
- <firstterm>stanzas</firstterm> separated by blank lines:</para>
hunk ./doc/Cabal.xml 241
- <listitem>
- <para>The first stanza describes the package as a whole
- (see <xref linkend="general-fields"/>), as well as an optional
- library (see <xref linkend="library"/>) and relevant build
- information (see <xref linkend="buildinfo"/>).</para>
- </listitem>
- <listitem>
- <para>Each subsequent stanza (if any) describes an executable
- program (see <xref linkend="executable"/>) and relevant
- build information (see <xref linkend="buildinfo"/>).</para>
+ <listitem>
+ <para>The global properties describe the package as a whole,
+ such as name, license, author, etc. (see <xref
+ linkend="general-fields"/>).</para>
+ </listitem>
+ <listitem>
+ <para>Optionally, a number of <firstterm>configuration
+ flags</firstterm> can be declared. These can be used to
+ enable or disable certain features of a package. (see <xref
+ linkend="configurations"/>).</para>
+ </listitem>
+ <listitem>
+ <para>The (optional) library section specifies the library
+ properties (see <xref linkend="library"/>) and relevant build
+ information (see <xref linkend="buildinfo"/>).</para>
+ </listitem>
+ <listitem>
+ <para>Following is an arbitrary number of executable sections
+ which describe an executable program and (see <xref
+ linkend="executable"/>) relevant build information (see <xref
+ linkend="buildinfo"/>).</para>
hunk ./doc/Cabal.xml 265
- <para>Each stanza consists of a number of field/value pairs, with a
- syntax like mail message headers.</para>
+ <para>Each section consists of a number of property descriptions
+ in the form of field/value pairs, with a syntax roughly like mail
+ message headers.</para>
hunk ./doc/Cabal.xml 270
- <para>case is not significant in field names,
- but is significant in field values</para>
+ <para>Case is not significant in field names,
+ but is significant in field values.</para>
hunk ./doc/Cabal.xml 274
- <para>to continue a field value, indent the next line</para>
+ <para>To continue a field value, indent the next line
+ relative to the field name.</para>
hunk ./doc/Cabal.xml 278
- <para>to get a blank line in a field value, use an indented
+ <para>Field names may be indented, but all field values in
+ the same section must use the same indentation.</para>
+ </listitem>
+ <listitem>
+ <para>Tabs are <emphasis>not</emphasis> allowed as
+ indentation characters due to a missing standard
+ interpretation of tab width.</para>
+ </listitem>
+ <listitem>
+ <para>To get a blank line in a field value, use an indented
hunk ./doc/Cabal.xml 372
- <para>These fields may occur in the first stanza, and describe
- the package as a whole:</para>
+ <para>These fields may occur in the first top-level properties
+ section and describe the package as a whole:</para>
hunk ./doc/Cabal.xml 405
- Use <emphasis>only</emphasis> if this package requires
- a particular version of Cabal, since unfortunately
- early versions of Cabal do not recognize this field.
- List the field early in your <literal>.cabal</literal>
- file so that it will appear as a syntax error before
- any others.</para>
+ Since, with Cabal version 1.2 the syntax of package
+ descriptions has changed, this is now a required field.
+ List the field early in your <literal>.cabal</literal>
+ file so that it will appear as a syntax error before any
+ others, since old versions of Cabal unfortunately do not
+ recognize this field.</para>
+ <para>For compatibility, files written in the old syntax
+ are still recognized. Thus if you don't require
+ features introduced with or after Cabal version 1.2, you
+ may write your package description file using the old
+ syntax. Please consult the user's guide of that Cabal
+ version for a description of that syntax.</para>
hunk ./doc/Cabal.xml 579
- <varlistentry>
- <term>
- <literal>build-depends:</literal>
- <replaceable>package list</replaceable>
- </term>
- <listitem>
- <para>A list of packages, possibly annotated with versions,
- needed to build this one,
- e.g. <literal>foo > 1.2, bar</literal>.
- If no version constraint is specified, any version is
- assumed to be acceptable.</para>
- </listitem>
- </varlistentry>
-
hunk ./doc/Cabal.xml 626
- <para>If the package contains a library, the first stanza should
- also contain the following field:</para>
+ <para>The library section should contain the following
+ field:</para>
hunk ./doc/Cabal.xml 640
+ <varlistentry>
+ <term>
+ <literal>build-depends:</literal>
+ <replaceable>package list</replaceable>
+ </term>
+ <listitem>
+ <para>A list of packages, possibly annotated with versions,
+ needed to build this one,
+ e.g. <literal>foo > 1.2, bar</literal>.
+ If no version constraint is specified, any version is
+ assumed to be acceptable.</para>
+ </listitem>
+ </varlistentry>
+
+
hunk ./doc/Cabal.xml 657
- <para>The first stanza may also contain build information fields
- (see <xref linkend="buildinfo"/>) relating to the library.</para>
+ <para>The library section may also contain build information fields
+ (see <xref linkend="buildinfo"/>).</para>
hunk ./doc/Cabal.xml 664
- <para>Subsequent stanzas (if present) describe executable programs
- contained in the package, using the following fields, as well as
- build information fields (see <xref linkend="buildinfo"/>).</para>
+ <para>Executable sections (if present) describe executable
+ programs contained in the package and must have an argument
+ after the section label, which defines the name of the
+ executable. This is a freeform argument but may not contain
+ spaces.</para>
+
+ <para>The executable may be described using the following
+ fields, as well as build information fields (see <xref
+ linkend="buildinfo"/>).</para>
hunk ./doc/Cabal.xml 677
- <literal>executable:</literal>
- <replaceable>freeform</replaceable>
+ <literal>main-is:</literal> <replaceable>filename</replaceable>
hunk ./doc/Cabal.xml 681
- <para>The name of the executable program.</para>
+ <para>The name of the source file containing the
+ <literal>Main</literal> module, relative to one of the
+ directories listed in <literal>hs-source-dirs</literal>.</para>
hunk ./doc/Cabal.xml 686
-
- <varlistentry>
+ <varlistentry>
hunk ./doc/Cabal.xml 688
- <literal>main-is:</literal> <replaceable>filename</replaceable>
- (required)
+ <literal>build-depends:</literal>
+ <replaceable>package list</replaceable>
hunk ./doc/Cabal.xml 692
- <para>The name of the source file containing the
- <literal>Main</literal> module, relative to one of the
- directories listed in <literal>hs-source-dirs</literal>.</para>
+ <para>A list of packages, possibly annotated with versions,
+ needed to build this executable,
+ e.g. <literal>foo > 1.2, bar</literal>.
+ If no version constraint is specified, any version is
+ assumed to be acceptable.</para>
hunk ./doc/Cabal.xml 701
- <para>These stanzas may also contain build information fields
- (see <xref linkend="buildinfo"/>) relating to the executable.</para>
hunk ./doc/Cabal.xml 706
- <para>The following fields may be optionally present
- in any stanza, and give information for the building
- of the corresponding library or executable. See also
- <xref linkend="system-dependent"/> for a way to supply
- system-dependent values for these fields.</para>
+ <para>The following fields may be optionally present in a
+ library or executable section, and give information for the
+ building of the corresponding library or executable. See also
+ <xref linkend="system-dependent"/> and <xref linkend="configurations"/>
+ for a way to supply system-dependent values for these
+ fields.</para>
hunk ./doc/Cabal.xml 968
+
+ <sect3 id="configurations">
+ <title>Configurations</title>
+ <para>Library and executable sections may include conditional
+ blocks, which test for various system parameters and
+ configuration flags. The flags mechanism is rather generic,
+ but most of the time a flag represents certain feature, that
+ can be switched on or off by the package user.</para>
+ <para>Here is an example package description file using
+ configurations:</para>
+ <example id="package-with-configurations-example">
+ <title>A package containing a library and executable programs</title>
+
+ <programlisting>Name: Test1
+Version: 0.0.1
+Cabal-Version: >= 1.1.7
+License: BSD3
+Author: Jane Doe
+Synopsis: Test package to test configurations
+Category: Example
+
+Flag Debug {
+ Description: Enable debug support
+ Default: False
+}
+
+Flag WebFrontend {
+ Description: Include API for web frontend.
+ -- defaults to True
+}
+
+Library {
+ Build-Depends: base
+ Exposed-Modules: Testing.Test1
+ Extensions: CPP
+
+
+ if flag(debug) {
+ GHC-Options: -DDEBUG
+ if !os(win32) {
+ CC-Options: "-DDEBUG"
+ } else {
+ CC-Options: "-DNDEBUG"
+ }
+ }
+
+ if flag(webfrontend) {
+ Build-Depends: cgi > 0.42
+ Exposed-Modules: Testing.WebStuff
+ }
+}
+
+Executable test1 {
+ Main-is: T1.hs
+ Other-Modules: Testing.Test1
+ Build-Depends: base
+
+ if flag(debug) {
+ CC-Options: "-DDEBUG"
+ GHC-Options: -DDEBUG
+ }
+}</programlisting>
+ </example>
+ <sect4>
+ <title>Configuration Flags</title>
+ <para>A flag section takes the flag name as an argument and
+ may contain the following fields.</para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ <literal>description:</literal>
+ <replaceable>freeform</replaceable>
+ </term>
+ <listitem>
+ <para>The description of this flag.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>default:</literal>
+ <replaceable>Boolean</replaceable>
+ (default: <literal>True</literal>)
+ </term>
+ <listitem>
+ <para>The default value of this flag.</para>
+ <para>Note that this value may be overridden in several
+ ways (see <xref linkend="flag-control"/>). The
+ rationale for having flags default to True is that users
+ usually want new features as soon as they are available.
+ Flags representing features that are not (yet)
+ recommended for most users (such as experimental
+ features or debugging support) should therefore
+ explicitly override the default to False.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </sect4>
+ <sect4 id="conditionals">
+ <title>Conditional Blocks</title>
+ <para>Conditional blocks may appear anywhere inside a
+ library or executable section. They have to follow rather
+ strict formatting rules.</para>
+ <para>Conditional blocks must always be of the shape
+ <literallayout>
+ <literal>if </literal><replaceable>condition</replaceable><literal> {</literal>
+ <replaceable> property-descriptions-or-conditionals*</replaceable>
+ <literal>}</literal>
+ </literallayout> or
+ <literallayout>
+ <literal>if </literal><replaceable>condition</replaceable><literal> {</literal>
+ <replaceable> property-descriptions-or-conditionals*</replaceable>
+ <literal>} else {</literal>
+ <replaceable> property-descriptions-or-conditionals*</replaceable>
+ <literal>}</literal>
+ </literallayout></para>
+
+ <para>Note that the condition and the opening brace have to
+ be all on the same line. Similar for the closing brace and
+ a possible <literal>else</literal> part. In particular, it
+ is <emphasis>not</emphasis> possible to have multiple
+ closing braces on one line or to have the
+ <literal>else</literal> followed directly by an
+ <literal>if</literal>.</para>
+ <para>Properties inside an if block must be indented at
+ least as much as the opening <literal>if</literal>
+ (preferably more).</para>
+
+ </sect4>
+ <sect4 id="conditions">
+ <title>Conditions</title>
+ <para>Conditions can be formed using boolean tests and the
+ boolean operators <literal>||</literal> (disjunction /
+ logical "or"), <literal>&&</literal> (conjunction /
+ logical "and"), or <literal>!</literal> (negation / logical
+ "not"). The unary <literal>!</literal> takes highest
+ precedence, <literal>||</literal> takes lowest. Precedence
+ levels may be overridden through the use of parentheses.
+ For example, <literal>os(darwin) && !arch(i386) || os(freebsd)</literal>
+ is equivalent to <literal>(os(darwin) && !(arch(i386))) || os(freebsd)</literal>.
+ </para>
+ <para>The following tests are currently supported.</para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ <literal>os(</literal>
+ <replaceable>name</replaceable>
+ <literal>)</literal>
+ </term>
+ <listitem>
+ <para>Tests if the current operating system is
+ <replaceable>name</replaceable>. The argument is tested
+ against the result of calling
+ <literal>System.Info.os</literal> on the target system.
+ If both are the same, this test evaluates to true,
+ otherwise false.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>arch(</literal>
+ <replaceable>name</replaceable>
+ <literal>)</literal>
+ </term>
+ <listitem>
+ <para>Tests if the current architecture is
+ <replaceable>name</replaceable>. The argument is tested
+ against the result of calling
+ <literal>System.Info.arch</literal> on the target system.
+ If both are the same, this test evaluates to true,
+ otherwise false.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>impl(</literal>
+ <replaceable>compiler</replaceable>
+ <literal>)</literal>
+ </term>
+ <listitem>
+ <para>Tests for the configured compiler. An optional
+ version constraint may be specified (for example
+ <literal>impl(ghc >= 6.6.1)</literal>). If the
+ configured compiler is of the right type and matches the
+ version constraint, then this evaluates to true,
+ otherwise false.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>flag(</literal>
+ <replaceable>name</replaceable>
+ <literal>)</literal>
+ </term>
+ <listitem>
+ <para>Evaluates to the current assignment of the flag of
+ the given name. Flag names are case insensitive.
+ Testing for flags that have not been introduced with a
+ flag section is an error.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>true</literal>
+ </term>
+ <listitem>
+ <para>Always evaluates to true.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <literal>false</literal>
+ </term>
+ <listitem>
+ <para>Always evaluates to false.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ </sect4>
+ <sect4 id="prop-combine">
+ <title>Conditional Resolution</title>
+ <para>During the configuration phase, a flag assignment is
+ chosen (see <xref linkend="flag-control"/>), all
+ conditionals are evaluated, and the package description is
+ combined into a flat package descriptions. If property
+ descriptions occur both inside a conditional and outside
+ are combined, using the following rules.</para>
+ <itemizedlist>
+ <listitem>
+ <para>Boolean fields are combined using conjunction
+ (logical "and").</para>
+ </listitem>
+ <listitem>
+ <para>List fields are combined by appending the inner
+ items to the outer items, for example
+ <programlisting>Extensions: CPP
+if impl(ghc) || impl(hugs) {
+ Extensions: MultiParamTypeClasses
+}</programlisting>
+ when compiled using Hugs or GHC will be combined to
+ <programlisting>Extensions: CPP MultiParamTypeClasses</programlisting>
+ </para>
+ <para>Similarly, if two conditional sections appear at the
+ same nesting level, properties specified in the latter
+ will come after properties specified in the former.</para>
+ </listitem>
+ <listitem>
+ <para>All other fields must not be specified in ambiguous ways. For example
+ <programlisting>Main-is: Main.hs
+if flag(useothermain) {
+ Main-is: OtherMain.hs
+}</programlisting>
+ will lead to an error. Instead use
+ <programlisting>if flag(useothermain) {
+ Main-is: OtherMain.hs
+} else {
+ Main-is: Main.hs
+}</programlisting></para>
+ </listitem>
+ </itemizedlist>
+ </sect4>
+ </sect3>
hunk ./doc/Cabal.xml 1632
- from the compiler selected.</para>
+ from the compiler selected.</para>
hunk ./doc/Cabal.xml 1928
+ <sect3 id="flag-control">
+ <title>Controlling Flag Assignments</title>
+ <para>If a package descriptions specifies configuration flags
+ (see <xref linkend="configurations"/>) the package user can
+ control these in several ways. If none of the options below
+ are given, Cabal will try to find a flag assignment in the
+ following way.</para>
+ <itemizedlist>
+ <listitem>
+ <para>For each flag specified, it will assign its default
+ value, evaluate all conditions with this flag assignment,
+ and check if all dependencies can be satisfied. If this
+ check succeeded, the package will be configured with those
+ flag assignments.</para>
+ </listitem>
+ <listitem>
+ <para>If dependencies were missing, the last flag (as by
+ the order in which the flags were introduced in the
+ package description) is tried with its alternative value
+ and so on. This continues until either an assignment is
+ found where all dependencies can be satisfied, or all
+ possible flag assignments have been tried.</para>
+ </listitem>
+ </itemizedlist>
+ <para>If no suitable flag assignment could be found, the
+ configuration phase will fail and a list of missing
+ dependencies will be printed. Note that this resolution
+ process is exponential in the worst case (i.e., in the case
+ where dependencies cannot be satisfied). There are some
+ optimizations applied internally, but the overall complexity
+ remains unchanged.</para>
+
+ <para>Flag assignments can be controlled with the following
+ command line options.</para>
+ <variablelist>
+ <varlistentry>
+ <term><option>-f</option><replaceable>flagname</replaceable> or
+ <option>-f</option><literal>-</literal><replaceable>flagname</replaceable></term>
+ <listitem>
+ <para>Force the specified flag to
+ <literal>true</literal> or <literal>false</literal> (if
+ preceded with a <literal>-</literal>). Later
+ specifications for the same flags will override earlier,
+ i.e., specifying <literal>-fdebug -f-debug</literal> is
+ equivalent to <literal>-f-debug</literal></para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>--flags</option>=<replaceable>flagspecs</replaceable></term>
+ <listitem>
+ <para>Same as <option>-f</option>, but allows specifying
+ multiple flag assignments at once. The parameter is a
+ space-separated list of flag names (to force a flag to
+ <literal>true</literal>), optionally preceded by a
+ <literal>-</literal> (to force a flag to
+ <literal>false</literal>). For example,
+ <literal>--flags="debug -feature1 feature2"</literal> is
+ equivalent to <literal>-fdebug -f-feature1
+ -ffeature2</literal>.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </sect3>
+
+
hunk ./doc/Cabal.xml 2407
-
+
}
Context:
[FIX compilation with GHC 6.2.x
Simon Marlow <[EMAIL PROTECTED]>**20070801095523]
[Move the haddock code out into it's own module
Duncan Coutts <[EMAIL PROTECTED]>**20070731183410
It removes about 250 loc from Distribution.Simple
]
[-Wall police
Duncan Coutts <[EMAIL PROTECTED]>**20070731173626]
[Fix order of warnings.
Thomas Schilling <[EMAIL PROTECTED]>**20070730225311]
[Add line numbers to unknown fields error message.
Thomas Schilling <[EMAIL PROTECTED]>**20070730225256]
[Display a more helpful error message, when unknown fields are
Thomas Schilling <[EMAIL PROTECTED]>**20070730224026
noticed.
]
[Fix self-compile warnings.
Thomas Schilling <[EMAIL PROTECTED]>**20070730220537]
[Fix haddock markup
Ian Lynagh <[EMAIL PROTECTED]>**20070729233545
I haven't checked that it looks right, but it is now accepted by haddock.
]
[Pass ghc -package flags when using it as a C compiler in GHCMakefile
Ian Lynagh <[EMAIL PROTECTED]>**20070729152803
This means we get the CPP include directories included.
]
[Add a missing case in updateCfg
Ian Lynagh <[EMAIL PROTECTED]>**20070729105910]
[Resolve conflicts
Ian Lynagh <[EMAIL PROTECTED]>**20070729105854]
[Fix conflicts. Fix for changed argument to 'preprocessSources'.
Thomas Schilling <[EMAIL PROTECTED]>**20070728223322]
[Rename field.
Thomas Schilling <[EMAIL PROTECTED]>**20070728223102]
[Change HUnit module path to Test.HUnit (the default now).
Thomas Schilling <[EMAIL PROTECTED]>**20070728221453]
[Add note to 'clean' that it could be simpler, but for compatibility
Thomas Schilling <[EMAIL PROTECTED]>**20070728221342
reasons isn't (for now).
]
[Let sdist command run the preprocessors itself. This way we don't
Thomas Schilling <[EMAIL PROTECTED]>**20070728221237
have to put stuff into the source tree.
]
[Store resolved package description in local build info.
Thomas Schilling <[EMAIL PROTECTED]>**20070728221102
The clean and sdist commands need to use a flattened representation of
the original description. Note the notes for
flattenPackageDescription for some problems with this approach.
]
[Export 'flattenPackageDescription'.
Thomas Schilling <[EMAIL PROTECTED]>**20070728215155]
[Minor documentation fix.
Thomas Schilling <[EMAIL PROTECTED]>**20070728214859]
[Modify test case.
Thomas Schilling <[EMAIL PROTECTED]>**20070728214825]
[Add function 'flattenPackageDescription'.
Thomas Schilling <[EMAIL PROTECTED]>**20070728214746]
[Avoid reporting the same missing dependecy twice.
Thomas Schilling <[EMAIL PROTECTED]>**20070728214645]
[Add documentation
Thomas Schilling <[EMAIL PROTECTED]>**20070728214541]
[Add documentation
Thomas Schilling <[EMAIL PROTECTED]>**20070728214444]
[Add/Fix test cases
Thomas Schilling <[EMAIL PROTECTED]>**20070728214410]
[Minor. Moved some code.
Thomas Schilling <[EMAIL PROTECTED]>**20070719222541]
[Add function 'ignoreCondition'.
Thomas Schilling <[EMAIL PROTECTED]>**20070719222444]
[Re-enable and extend test case.
Thomas Schilling <[EMAIL PROTECTED]>**20070719222341]
[Filter duplicate dependencies.
Thomas Schilling <[EMAIL PROTECTED]>**20070719222233]
[Adopt new CondTree data structure.
Thomas Schilling <[EMAIL PROTECTED]>**20070719125305
'finalizePackageDescription' now also takes dependencies of
executables into account.
]
[Change CondTree data structure to something more flexible.
Thomas Schilling <[EMAIL PROTECTED]>**20070719124655
This also requires some interface changes.
]
[Add simpler representation of a .cabal file with conditions.
Thomas Schilling <[EMAIL PROTECTED]>**20070717203942]
[Preprocessor output never gets written back to the source dir.
Thomas Schilling <[EMAIL PROTECTED]>**20070717174026
'preprocessSources' now gets an additional flag to determine whether
to process all sources (for building) or only platform independent
ones (for sdist).
]
[Add resolved package description to 'LocalBuildInfo'.
Thomas Schilling <[EMAIL PROTECTED]>**20070716204325]
[Fix removed import by importing a required accessor only.
Thomas Schilling <[EMAIL PROTECTED]>**20070716204238]
[Add tags target to generate a tags file using 'hasktags'. (Unix only)
Thomas Schilling <[EMAIL PROTECTED]>**20070716203015]
[Rename 'PreparedPackageDescription' to 'GenericPackageDescription'
Thomas Schilling <[EMAIL PROTECTED]>**20070716200427]
[Remove unused dependency.
Thomas Schilling <[EMAIL PROTECTED]>**20070716200215]
[Move configured_cabal to 'dist' directory.
Thomas Schilling <[EMAIL PROTECTED]>**20070716154146]
[Bugfix by Ian Lynagh: Cabal can't have a Cabal-Version header; it breaks bootstrapping
Thomas Schilling <[EMAIL PROTECTED]>**20070716151535]
[Partial bugfix to allow traditional .cabal files without a library but
Thomas Schilling <[EMAIL PROTECTED]>**20070628112301
global build dependencies. The correct solution is to add global
dependencies to each executable and implement dependency resolution
for executables.
The current workaround is to add the dependencies to the library, but
disable building of the library.
]
[Take advantage of configurations to build Cabal itself and fix bootstrapping problem.
Thomas Schilling <[EMAIL PROTECTED]>**20070628081438]
[Re-add configurations module to .cabal file. (Got removed on update.)
Thomas Schilling <[EMAIL PROTECTED]>**20070623204706]
[Properly fix tests.
Thomas Schilling <[EMAIL PROTECTED]>**20070623203939]
[Disable (comment out) tests for now. Break due to changed interface.
Thomas Schilling <[EMAIL PROTECTED]>**20070623203121]
[Fix typo.
Thomas Schilling <[EMAIL PROTECTED]>**20070623202333]
[Add proper handling of configurations to configure command.
Thomas Schilling <[EMAIL PROTECTED]>**20070623202017]
[Fix warnings.
Thomas Schilling <[EMAIL PROTECTED]>**20070623201723]
[Adjust to new package reading interface.
Thomas Schilling <[EMAIL PROTECTED]>**20070623201546]
[Downcase flagnames. Re-add config flags (were removed due to update).
Thomas Schilling <[EMAIL PROTECTED]>**20070623201455]
[Fix warnings.
Thomas Schilling <[EMAIL PROTECTED]>**20070623201254]
[Fix warnings, add documentation and changes in response to some
Thomas Schilling <[EMAIL PROTECTED]>**20070623201135
interface changes.
]
[Make explicit that reading package descriptions isn't supported here, ATM.
Thomas Schilling <[EMAIL PROTECTED]>**20070623200701]
[Fixed warning
Thomas Schilling <[EMAIL PROTECTED]>**20070623200522]
[Fixed warnings, added documentation, and changed os and arch names to
Thomas Schilling <[EMAIL PROTECTED]>**20070623200453
simple strings.
]
[Add helpers for reading and writing the file to hold a configured cabal-file.
Thomas Schilling <[EMAIL PROTECTED]>**20070618195710]
[Add commandline support for specifying defaults for flags.
Thomas Schilling <[EMAIL PROTECTED]>**20070618195449]
[Compatibility parsing and working configurations.
Thomas Schilling <[EMAIL PROTECTED]>**20070618195329]
[Pretty printing of conditions and CondTrees. Non-dependency
Thomas Schilling <[EMAIL PROTECTED]>**20070614125031
information of CondTrees is now a modifier. Move CondTree resolution functionality.
]
[Prototypical configurations
Thomas Schilling <[EMAIL PROTECTED]>**20070613184332]
[add line numbers to all field times
Thomas Schilling <[EMAIL PROTECTED]>**20070613173548]
[add flag as a section
Thomas Schilling <[EMAIL PROTECTED]>**20070613172416]
[added docs
Thomas Schilling <[EMAIL PROTECTED]>**20070613172309]
[fixed typo
Thomas Schilling <[EMAIL PROTECTED]>**20070613172230]
[Abstracted variables out of conditions. Generalized simplification
Thomas Schilling <[EMAIL PROTECTED]>**20070613172114
function to accept an arbitrary partial assignment of these
variables.
]
[Added Configuration parsing and simplification.
Thomas Schilling <[EMAIL PROTECTED]>**20070529210344]
[Extended low-level parsing routines to also allow labelled blocks and if-blocks.
Thomas Schilling <[EMAIL PROTECTED]>**20070529205958]
[Added documentation.
Thomas Schilling <[EMAIL PROTECTED]>**20070528211221]
[Use the right output directory when building C sources for executables
Duncan Coutts <[EMAIL PROTECTED]>**20070726213309]
[Use our own GetOpt if __GLASGOW_HASKELL__ >= 606 only
Ian Lynagh <[EMAIL PROTECTED]>**20070724213112
Used to be if __GLASGOW_HASKELL__ >= 604, but the 6.4 branch had a bug
which looks likely to be the cause of GHC build failures we're seeing:
- procNextOpt (NonOpt x) RequireOrder = ([],x:rest,us,[])
+ procNextOpt (NonOpt x) RequireOrder = ([],x:rest,[],[])
]
[-Wall police
Duncan Coutts <[EMAIL PROTECTED]>**20070724172023]
[Update user guide about haddock --css --hyperlink-source --hscolour-css
Duncan Coutts <[EMAIL PROTECTED]>**20070724160742
The haddock --css flag is new. The old --hscolour=[path] flag got split
into two flags: --hyperlink-source and --hscolour-css=path
]
[Remove a couple bits of unused code and imports
Duncan Coutts <[EMAIL PROTECTED]>**20070724110732]
[use nhc-Options rather than deprecated nhc98-Options
Duncan Coutts <[EMAIL PROTECTED]>**20070724110703]
[Hugs build: track change to install-includes
Ross Paterson <[EMAIL PROTECTED]>**20070724101816]
[Rename --hscolour to --hyperlink-source and add haddock --css flag
Duncan Coutts <[EMAIL PROTECTED]>**20070723190026
So now --hyperlink-source controles wether or not we run hscolour and
get haddock to link to the sources. The new flag --hscolour-css can
be used to override the css file that hscolour uses.
Also, the new flag --css can override the css file that haddock uses.
]
[Merges from hscolour patch and make it work with haddock-0.8
Duncan Coutts <[EMAIL PROTECTED]>**20070723180602
Some minor changes due to changes since the hscolour patch was written.
Make it work with haddock-0.8 by using %{MODULE} rather than %{FILE}
and generate output file names to match (ie not using the original file
extension, just using the module name for the output file).
]
[HsColour support
Roberto Zunino <[EMAIL PROTECTED]>**20070530194747
Integration of Cabal, HsColour, and Haddock.
(Also fixes bug #102)
]
[Remove ContextStack extension
Ian Lynagh <[EMAIL PROTECTED]>**20070709132341
Seems to be based on GHC's -fcontext-stack flag, which takes an integer
argument.
]
[Remove InlinePhase extension
Ian Lynagh <[EMAIL PROTECTED]>**20070708172919
As far as I can tell
(a) The -finline-phase flag stopped actually being accepted by GHC
sometime between GHC 4.08.2 and GHC 5.04.3
(b) It took an Int argument
]
[Add KindSignatures extension
Ian Lynagh <[EMAIL PROTECTED]>**20070708120616]
[Add the MagicHash extension
Ian Lynagh <[EMAIL PROTECTED]>**20070708111043]
[TAG 2007-06-29
Ian Lynagh <[EMAIL PROTECTED]>**20070629112545]
Patch bundle hash:
1e224ac6fb247e65a9b01c31c0b1c62d2ed1fecb
_______________________________________________
cabal-devel mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cabal-devel
