Skip to content

Switch to makefile-based doc build. #9513

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Dec 3, 2017
Merged

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Oct 22, 2017

PR Summary

My own attempt at switching to make html for docs build.

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

Copy link
Member

@jklymak jklymak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to work on my machine. I checked the options that were documented, and they seemed to work. I also checked the built docs and they look fine, though of course I didn't go down each tree.

doc/README.txt Outdated
Matplotlib documentation
========================


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to duplicate documenting_mpl.rst Can all of this just be removed and replaced by reference?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup, fixed


.. note::

* You'll need a minimal working LaTeX distribution for many examples to run.
* `Graphviz <http://www.graphviz.org/Download.php>`_ is not a python package, and needs
* `Graphviz <http://www.graphviz.org/Download.php>`_ is not a python package, and needs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unnecessary change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed, dunno how the spare space got there

@@ -54,7 +54,7 @@ temporarily comment out the include and toctree glob; re-instate these after a
release. Finally, make sure that the docs build cleanly ::

pushd doc
python make.py html latex -n 16
make html latexpdf -n$(nproc)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

O=-n$(nproc)? Currently, this will build html and latexpdf in parallel, but I'm not sure Sphinx will like two runs occurring in parallel.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooops, I didn't check this one. Good eye: that doesn't run at all on my machine.

Glad someone more knowledgeable is reviewing!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you only fixed the one below that didn't have this comment. 😛

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

try again...

doc/make.bat Outdated
goto end

:help
%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS%
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't you need to check for sphinx build before running this too?

Copy link
Contributor Author

@anntzer anntzer Nov 16, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be reported to upstream but I fixed it locally.
(can you do it?)

@anntzer
Copy link
Contributor Author

anntzer commented Nov 16, 2017

Comments addressed in force-pushed commit. Thanks for the review.

@anntzer anntzer force-pushed the make-docs branch 2 times, most recently from 7e8ccbc to 3438f84 Compare November 17, 2017 00:02
@anntzer
Copy link
Contributor Author

anntzer commented Nov 17, 2017

rebased after the merge of #9311

doc/Makefile Outdated
#

# You can set these variables from the command line.
SPHINXOPTS =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we default to -W?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would much prefer not: when building locally I can easily check from the log whether the build failed, but I'd rather not have the build (which can be quite lengthy) fail halfway, fix one error, restart a build, wait another 5min, fix the next error, etc. (Well I know --allowsphinxwarnings, or, on the new system, how to override O=; but I think it's not the most new-contributor friendly way to do it...)
(xref sphinx-doc/sphinx#3627)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The CI runs with it so new contributors are going to have to deal with the failures one way or the other and getting them locally by default seems nicer than having to go through CI

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Warnings are perfectly well printed without -W as well, the only effects of -W are that 1) the build stops after the first failure (not so nice for new contribs) and 2) the return status is nonzero in that case (relevant for CI, not so much for new contribs).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see both sides, but I guess I think it'd be more confusing to have it build locally and then fail on CI. OTOH it'd be great to have the warning switch very clearly documented so knowledgable users can run that way and then clean all their errors in one compile.

Besides, the current behaviour is to fail on warning by default.

@anntzer
Copy link
Contributor Author

anntzer commented Nov 23, 2017

Minor edit to use make -Cdoc ... instead on pushd/popd in the release guide.

@QuLogic
Copy link
Member

QuLogic commented Dec 1, 2017

Seems to need a rebase.

@anntzer
Copy link
Contributor Author

anntzer commented Dec 1, 2017

fixed

@tacaswell
Copy link
Member

I prefer to default to fail-on-warning, but will not block the PR over it.

@anntzer
Copy link
Contributor Author

anntzer commented Dec 2, 2017

changed to -W by default

@@ -1,228 +0,0 @@
#!/usr/bin/env python
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, this all looks great to me, and it works, and the tests pass, so I think its good to go. But do we need to remove make.py? Someone may have a fancy script that uses it for something and want to keep it around, maybe with a big warning at the beginning that its going away soon?

The converse of that argument is that it might be confusing to have both.

I don't really care, but was just trying to think of what could go wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we ever made any guarantees as to backcompatibility of tooling (and wouldn't want to do so either).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even I think we don't need to worry about this too much. The downstream packagers (debian, fedora, etc) will need to adapt their build scripts, but it is clearly documented what to change it too.

@tacaswell tacaswell merged commit 5392f2e into matplotlib:master Dec 3, 2017
@tacaswell
Copy link
Member

Thanks @anntzer

@jklymak
Copy link
Member

jklymak commented Dec 3, 2017

Yay!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants