On 10/26/06, <b class="gmail_sendername">Duncan Coutts</b> <<a href="mailto:duncan.coutts@worc.ox.ac.uk">duncan.coutts@worc.ox.ac.uk</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, 2006-10-25 at 22:19 -0500, Brian Smith wrote:<br>> * What happens when multiple configurations apply?:<br>><br>> Configuration: True<br>> Build-depends: foo-1.0<br>><br>> Configuration: True
<br>> Build-depends: foo-1.0<br>><br>> I think that if more than one condition applies, then configuration<br>> should fail with an error.<br><br>I think it's important that mutliple configurations can apply at once.
<br>So then the question is how do we interpret additions to fields, eg do<br>we interpret them as sets or multi-sets. I think we'll have to say that<br>the order in which the flags are added is undefined (eg for things like
<br>cc-options).</blockquote><div><br>It is important that builds be reproducible predictably, so I do not think it is a good idea to introduce undefined behavior. I think this will be made clearer when some real examples are created.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> * You mentioned the case where a using(x) expression conflicts with a<br>
> build-depends:<br>> Configuration: using(foo = 1.0)<br>> Build-depends: foo = 2.0<br>> It seems to me that:<br>> using(foo = x) == !(available foo > x),<br>> using(foo > x) == (available foo > x),
<br>> using(foo < x) == !(available foo >= x),<br>> because of Cabal's "use the latest available version" policy.<br><br>They're not the same. If the latest versions of each package do not<br>
satisfy the constraints then Cabal may have to pick different versions<br>and then the above do not hold.</blockquote><div><br>But, they are pretty close to the same. The feature causes multiple difficulties. Do you have a real-world motivating example for it, that cannot easily be replaced by adding a flag and using available(x)? I propose that it be left out. Then the whole design becomes much simpler, doesn't it? In particular, no backtracking or non-trivial constraint solving is needed.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Additionally, there's no reason why Cabal should not be extended to<br>allow users to build against older versions of libs they have installed,
<br>eg for testing purposes or because they know only the older version is<br>available on some site where they intend to deploy.</blockquote><div><br>They can do this already with your configuration mechanism:<br><br> Build-depends: foo >=
2.0, bar >= 3.0<br><br> flag: minimum-versions<br> Synopsis: Choose the minimum version number of all packages<br> Description: This is useful to test that the minimum version<br> constraints in the package description are correct.
<br> default: False<br>
<br> configuration: flag(minimum-versions)<br> Build-Depends: foo = 2.0, bar = 3.0<br><br>In the presence of flags and configurations, I do not think Cabal will be able to provide a feature to do this automatically. For example:
<br><br>If you want to extend Cabal to allow the user to specify a specific version of a package on the command-line, again, I think this should be done with flags. But, this requires that you allow non-boolean flags. Incidentally, if os(), and arch() were non-boolean flags, you would not need special syntax for them.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> If all usages of using(x) can be replaced with available(f(x)), then<br>
> I think it would be better to just get rid of using(x) and allow<br>> available(x) in both fexp's and cexp's, for consistency. However, I<br>> know that you do not want to do that, because you don't want<br>> available(x) allowed in cexp's. As you noted previously in the thread,
<br>> using(x) seems to cause a lot of complications--is it really<br>> necessary? I think your example of using(x) is easily rewritten to not<br>> require it:<br><br>But even if using is equal to some available expression in normal
<br>circumstances, there's still a reason for using rather than available,<br>which is that using is less expressive. It doesn't allow packages to<br>automatically pick up dependencies merely because they're available in<br>
the environment. This is one of the main points of the design. Anything<br>like that has to go via a flag, which is then controllable by the user<br>or package manager.</blockquote><div><br>I agree with you, and that is partly why I am suggesting that using(x) is not good--it exposes (most of) the functionality of available(x) in exactly the context you do not want that functionality exposed. But, mostly, I just think it would be better to make the design simpler if possible.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> * Your example used [ os(windows) ]. However, the value for<br>> System.Info.os
is usually "mingw32" or "cygwin" (or similar) on<br>> Windows. I think that the os() and arch() values should be consistent<br>> with System.Info whenever possible.<br><br>You're probably right, though that in it self needs resolving since
<br>people do need reliable tests for being on windows.<br>(os(mingw32) || os(mingw64) || os (cygwin)) starts to get a little<br>unwieldy.</blockquote><div><br>I agree--I wish System.Info.os worked differently, actually. But, there are apparently some people (not me) that use Haskell on Cygwin, and they need to be able to detect it, because
e.g. Posix and Readline are available on Cygwin but not Mingw. Maybe os(x) should be either "mingw" or "cygwin"?<br><br>- Brian<br></div><br></div>