aboutsummaryrefslogtreecommitdiff
path: root/doc/manual/bugs.xml
diff options
context:
space:
mode:
authorEelco Dolstra <e.dolstra@tudelft.nl>2003-11-26 12:30:16 +0000
committerEelco Dolstra <e.dolstra@tudelft.nl>2003-11-26 12:30:16 +0000
commitf6a30ab264506ca966180666dff45310d176659d (patch)
tree147f661bb236e40bbe5c858b04117cb295b8ddf4 /doc/manual/bugs.xml
parent2a4bac5459f42764b39ac70f906f5dd3330a3ac5 (diff)
* Updates.
Diffstat (limited to 'doc/manual/bugs.xml')
-rw-r--r--doc/manual/bugs.xml39
1 files changed, 24 insertions, 15 deletions
diff --git a/doc/manual/bugs.xml b/doc/manual/bugs.xml
index 548ce1cab..fcb69c364 100644
--- a/doc/manual/bugs.xml
+++ b/doc/manual/bugs.xml
@@ -1,34 +1,43 @@
<appendix>
- <title>Bugs</title>
+ <title>Bugs / To-Do</title>
<itemizedlist>
<listitem>
<para>
- Nix should automatically recover the Berkeley DB database.
+ Nix should automatically remove Berkeley DB logfiles.
</para>
</listitem>
<listitem>
<para>
- Nix should automatically remove Berkeley DB logfiles.
+ Unify the concepts of successors and substitutes into a general notion
+ of <emphasis>equivalent expressions</emphasis>. Expressions are
+ equivalent if they have the same target paths with the same
+ identifiers. However, even though they are functionally equivalent,
+ they may differ stronly with respect to their <emphasis>performance
+ characteristics</emphasis>. For example, realising a slice is more
+ efficient that realising the derivation from which that slice was
+ produced. On the other hand, distributing sources may be more
+ efficient (storage- or bandwidth-wise) than distributing binaries. So
+ we need to be able to attach weigths or priorities or performance
+ annotations to expressions; Nix can then choose the most efficient
+ expression dependent on the context.
</para>
</listitem>
<listitem>
<para>
- Unify the concepts of successors and substitutes into a general notion
- of <emphasis>equivalent expressions</emphasis>. Expressions are
- equivalent if they have the same target paths with the same
- identifiers. However, even though they are functionally equivalent,
- they may differ stronly with respect to their <emphasis>performance
- characteristics</emphasis>. For example, realising a slice is more
- efficient that realising the derivation from which that slice was
- produced. On the other hand, distributing sources may be more
- efficient (storage- or bandwidth-wise) than distributing binaries. So
- we need to be able to attach weigths or priorities or performance
- annotations to expressions; Nix can then choose the most efficient
- expression dependent on the context.
+ <emphasis>Build management.</emphasis> In principle it is already
+ possible to do build management using Nix (by writing builders that
+ perform appropriate build steps), but the Nix expression language is
+ not yet powerful enough to make this pleasant (?). The language should
+ be extended with features from the <ulink
+ url='http://www.cs.uu.nl/~eelco/maak/'>Maak build manager</ulink>.
+ Another interesting idea is to write a <command>make</command>
+ implementation that uses Nix as a back-end to support <ulink
+ url='http://www.research.att.com/~bs/bs_faq.html#legacy'>legacy</ulink>
+ build files.
</para>
</listitem>