RFC: fix #2501

[tkelman]

Build helpdb.jl instead of checking it in to repository.

In my local builds, there's a kinda funny race condition between the system image getting to base/help.jl vs the Sphinx build finishing, they happen at the same time with -j > 1. That could be fixed with a few more explicit makefile dependencies, but it's a little faster this way, and help.jl is near the end of the sysimg, well after inference which takes a good chunk of time. nevermind, not a race condition, helpdb.jl is a dependency of sys.o, not sys0.o. System image seems to build fine even without helpdb.jl present at all?

[tkelman]

I don't know enough about Python virtualenvs to figure out what's happening on appveyor https://ci.appveyor.com/project/tkelman/julia/build/1.0.619/job/ypr5i09d4kqvkcs8:

New python executable in julia-env\Scripts\python.exe
Installing setuptools, pip...done.
/bin/sh: /c/projects/julia/deps/julia-env/bin/activate: No such file or directory
make[2]: *** [/c/projects/julia/deps/julia-env/bin/sphinx-build] Error 1

Any ideas?

[tkelman]

Grr, Win32 Python you are awful and I hate you. Evidently activate and sphinx-build.exe end up in Scripts if you're using a Win32 Python, as opposed to bin for a posix Python. Anyone know the canonical way of determining whether or not a given Python is Win32?

[catawbasam]

http://stackoverflow.com/questions/1405913/how-do-i-determine-if-my-python-shell-is-executing-in-32bit-or-64bit-mode-on-os

looks relevant.

[tkelman]

@catawbasam thanks but I think 32 vs 64 bit shouldn't matter much as far as Sphinx is concerned. What I was referring to was whether the python executable is, say Cygwin-style, where conventions like /bin vs /Scripts match Unix systems, or Win32-style which is different because someone at some point felt /Scripts was a more Windows-y name than /bin.

edit: found when that was done, 4 days into virtualenv's history pypa/virtualenv@993ba13 "that seems to be the convention" grumble grumble

[tkelman]

Changing to RFC since I got it to work on AppVeyor. Should probably delete helpdb.jl, and maybe also $(build_docdir), in one of make clean or make cleanall. Thoughts?

[ViralBShah]

I think make cleanall should be the target to delete $(build_docdir) in.

Does building helpdb.jl get triggered when any file in doc/stdlib it depends on changes? It doesn't seem to be the case right now, but I may be missing something.

[tkelman]

Does building helpdb.jl get triggered when any file in doc/stdlib it depends on changes?

There is a dependency in doc/Makefile on stdlib/*.rst for the helpdb.jl target, so I would think so.

It doesn't seem to be the case right now, but I may be missing something.

Did you test this branch out and see it not rebuild when it should've? I admittedly should do more testing on this branch (and it needs a rebase) to get a feel for how well-behaved it is.

[tkelman]

Rebased and added @rm -f doc/helpdb.jl $(build_docdir)/helpdb.jl to make cleanall. Let's see what CI thinks about it. I somehow managed to lose the Windows Python /Scripts fix in my first rebase, whoops. Dug it up on Travis and put it back though.

[tkelman]

@jiahao any idea how to fix the unicode table warning? that would get pretty annoying to see in every CI log

[jiahao]

The Unicode table simply needs to be rebuilt on master. Done in 27d6c1d

I added a new doc Make target to simplify rebuilding this table (it has to be done every time someone changes latex_symbols.jl). Now you can run make -C doc unicode.

[tkelman]

closing this since it looks like helpdb.jl will be going away imminently