<div dir="ltr">agreed, cabal-install should definitely get support for doing this correctly added in. (since this is going to become a common activity for maintainers who's libs need extra things installed that the doc builders lack)<div>
<br></div><div>Any volunteers? </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 6, 2014 at 9:28 PM, Mateusz Kowalczyk <span dir="ltr"><<a href="mailto:fuuzetsu@fuuzetsu.co.uk" target="_blank">fuuzetsu@fuuzetsu.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 07/01/14 01:23, Peter Selinger wrote:<br>
> Thanks, that's even better!<br>
><br>
> However, I find that the --contents-location option to cabal haddock<br>
> does not work properly. Apparently it not only prevents index.html<br>
> from being built (which makes modest sense), but it also prevents<br>
> index-frames.html from being built (which does not). So in the frames<br>
> view, one of the frames will just say "Sorry, it's just not here".<br>
> That's not very nice. Also, if one loads the "/frames.html" URL<br>
> directly, it still points to the non-existing index.html, rather than<br>
> the one given by --contents-location. I think these are bugs.<br>
><br>
> For example, see<br>
> <a href="http://hackage.haskell.org/package/yi-monokai-0.1.1.1/docs/Yi-Style-Monokai.html" target="_blank">http://hackage.haskell.org/package/yi-monokai-0.1.1.1/docs/Yi-Style-Monokai.html</a><br>
> and click on "Frames".<br>
<br>
</div>Ah, I do not use frames so I did not notice.<br>
<div class="im"><br>
> One workaround is to run "cabal haddock" twice: first without the<br>
> --contents-location option, and then with it. Slightly annoying, but<br>
> it works. It has the disadvantage that if one goes directly to the<br>
> ".../frames.html" URL, one will still see the old index.html.<br>
><br>
> Another workaround is to omit the --contents-location option<br>
> altogether, and to manually create an index.html that is just a<br>
> forward to the correct location, i.e.:<br>
><br>
> <meta HTTP-EQUIV="REFRESH" content="0; url=<a href="http://hackage.haskell.org/package/newsynth-0.1.0.0" target="_blank">http://hackage.haskell.org/package/newsynth-0.1.0.0</a>"><br>
> If your browser does not take you there automatically, please go to<br>
> <a href=<a href="http://hackage.haskell.org/package/newsynth-0.1.0.0" target="_blank">http://hackage.haskell.org/package/newsynth-0.1.0.0</a>><a href="http://hackage.haskell.org/package/newsynth-0.1.0.0" target="_blank">http://hackage.haskell.org/package/newsynth-0.1.0.0</a></a>.<br>
><br>
> Only this last solution seems to do the correct thing all the time.<br>
> For an example, see<br>
> <a href="http://hackage.haskell.org/package/newsynth-0.1.0.0/docs/frames.html" target="_blank">http://hackage.haskell.org/package/newsynth-0.1.0.0/docs/frames.html</a><br>
><br>
> Your instructions have been *very* helpful. But it's a lot of details<br>
> and finnicky cabal directives to keep track of for doing this all the<br>
> time. I've turned your instructions into a Makefile to automate this<br>
> task; see attached. In principle, only the first two lines should need<br>
> to be customized. Then "make doc-upload" will build the documentation<br>
> and upload it correctly.<br>
<br>
</div>That looks very useful but I have a few questions about it:<br>
* Why a Makefile as opposed to a Bash script or something? I don't<br>
think there's a way to pass arguments into a Makefile like to Bash<br>
scripts, save for environmental variables. I'd much rather prefer a<br>
command line flag for a script in my PATH rather than having to change<br>
the file each time.<br>
<br>
* This file makes us change the top two lines (user and package name)<br>
and uses ‘read’ for everything else. Why not fully go with one way or<br>
the other? Personally, I'd prefer arguments rather than ‘read’ (much<br>
easier to repeat commands/script against) but it's up to personal taste.<br>
<br>
* Can we not grab to project name from the cabal file just like you do<br>
with version?<br>
<br>
* Your ‘--html-location’ has ‘$$pkg’ in it, how come? Is that some<br>
kind of escape?<br>
<br>
* Considering you seem to know what you're doing much more than I am,<br>
is there any way to detect cabal sandboxes?<br>
<br>
I'm trying your makefile now (running with make -f /tmp/Makefile<br>
doc-upload) and<br>
it's giving me an error:<br>
<br>
```<br>
[snip]<br>
Haddock coverage:<br>
100% ( 18 / 18) in 'Yi.Style.Monokai'<br>
Documentation created: dist/doc/html/yi-monokai/index.html<br>
rm -r yi-monokai-0.1.1.1-docs<br>
rm: cannot remove ‘yi-monokai-0.1.1.1-docs’: No such file or directory<br>
make: *** [yi-monokai-0.1.1.1-docs.tar.gz] Error 1<br>
```<br>
<br>
It works fine if I comment out the ‘rm -r’. Perhaps that should be<br>
allowed to fail somehow.<br>
<div class="im"><br>
> I know, Cabal somehow was supposed to make Makefiles obsolete. Alas.<br>
> Fortunately, the Makefile is only for the package maintainer, and not<br>
> for the package user.<br>
><br>
> -- Peter<br>
<br>
</div>I think that cabal-install should really have the option to do all<br>
this rather than have people write up scripts like this, resulting in<br>
trial and error.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Mateusz K.<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>
</div></div></blockquote></div><br></div>