<div dir="ltr">To be honest I think that's a much bigger hack than what I originally proposed. The point of the sub/super compiler CompilerId change is that both parts can have their own version range. For example GHCJS is currently at version 0.1.0, GHC at 7.6. While currently GHCJS can only be built against HEAD, that could change in the future (we used to have a version compatible with both 7.4 and 7.6), and one could want checks like this:<div>
<br></div><div>impl(ghcjs >= 0.1) && impl(ghc < 7.10)</div><div><br></div><div>I think this could also come in handy with Roman's haskell-suite compiler flavour, which makes it easy to make customized compilers. If you make something based on GHC it would be useful to be able to specify that, so you can support packages that depend on impl(ghc) checks. With this CompilerId change, that can be implemented for the HaskellSuite flavour by just giving the user a way to specify the compiler name/version.</div>
<div><br></div><div>If there's a way to achieve this without changing CompilerId, that would be great. As for the CompilerId change itself:</div><div><br></div><div>There are 11 packages on hackage that appear to use the CompilerId constructor (archlinux, cab, cabal-debian, cabal-db, cabal2nix, cabal-ghci, cabal-install-bundle, cblrepo, ghc-mod, hackport, hoogle)</div>
<div><br></div><div>I'd be happy to send all of them a pull req. For other projects (not on hackage), I think that with some comments/Haddock the CompilerId type they can be quickly guided towards the right change (usually ignoring the field or adding Nothing)</div>
<div><br></div><div>luite</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 26, 2013 at 3:39 PM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Lets change the implementation of `impl` itself then to have ghc ==<br>
ghcjs = True. This way the special casing is at least localized and<br>
not all users of the CompilerId data type need to care. Are there any<br>
other such checks that need to be adjusted?<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Aug 26, 2013 at 7:39 AM, Dag Odenhall <<a href="mailto:dag.odenhall@gmail.com">dag.odenhall@gmail.com</a>> wrote:<br>
> I definitely think impl(ghc) should cover GHCJS, as it effectively just is a<br>
> GHC backend (even if not part of GHC). Doing otherwise would be a bit like<br>
> having impl(ghc) be false when compiling with -fllvm IMHO. The value of<br>
> GHCJS is that it's supposed to be able to compile most existing packages<br>
> as-is.<br>
><br>
> Just my two cents. :-)<br>
><br>
><br>
><br>
> On Sun, Aug 25, 2013 at 6:53 PM, Luite Stegeman <<a href="mailto:stegeman@gmail.com">stegeman@gmail.com</a>> wrote:<br>
>><br>
>><br>
>>> I think we should definitely fix the packages, not put a hack in Cabal.<br>
>><br>
>><br>
>> In the latest hackage archive, there are 462 packages that use the<br>
>> impl(ghc) flag, including lots of very common packages. For example binary:<br>
>><br>
>> if impl(ghc >= 7.2.1)<br>
>> cpp-options: -DGENERICS<br>
>> other-modules: Data.Binary.Generic<br>
>> if impl(ghc <= 7.6)<br>
>> -- prior to ghc-7.4 generics lived in ghc-prim<br>
>> build-depends: ghc-prim<br>
>><br>
>> Is there a generic way to do this without impl ghc checks? Otherwise all<br>
>> these impl(ghc >= x) flag checks have to be changed to impl(ghc >= x) ||<br>
>> impl(ghcjs >= y), not something I'd be looking forward to...<br>
>><br>
>> Also I personally don't really see it as a hack (of course I'm biased<br>
>> since I've been using it for a while). It just allows you to specify that<br>
>> "compiler x is based on compiler y", so that unless explicitly queried<br>
>> otherwise you can assume that flags for 'y' hold for 'x'.<br>
>><br>
>> luite<br>
>><br>
>> _______________________________________________<br>
>> cabal-devel mailing list<br>
>> <a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/cabal-devel" target="_blank">http://www.haskell.org/mailman/listinfo/cabal-devel</a><br>
>><br>
><br>
</div></div></blockquote></div><br></div>