Make is quitting with errors.
I'm still trying to troubleshoot this. Must be a missing package on my system, but the configure script seems to be not noticing.
At git rev https://github.com/geany/geany/commit/b524a58e12e85c94a32f64fb72615978b2628a...
``` Install Geany in : /usr/local Compiling Git revision : b524a58e Using GTK version : 3.24.5 Enable binary relocation : no Build with plugin support : yes Use (UNIX domain) socket support : yes Use virtual terminal support (VTE) : yes Build HTML documentation : yes Build PDF documentation : no Build API documentation : yes Generate GtkDoc header : no
Configuration is done OK. ``` [config.log](https://github.com/geany/geany/files/6588377/config.log)
``` Making all in po make[2]: Entering directory '/home/andy/src/Geany/geany/po' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/andy/src/Geany/geany/po' Making all in doc make[2]: Entering directory '/home/andy/src/Geany/geany/doc' GEN geany.html GEN hacking.html GEN Doxyfile.stamp Traceback (most recent call last): File "/usr/bin/rst2html", line 17, in <module> from docutils.core import publish_cmdline, default_description [config.log](https://github.com/geany/geany/files/6588376/config.log) Traceback (most recent call last): File "/usr/bin/rst2html", line 17, in <module> from docutils.core import publish_cmdline, default_description ModuleNotFoundError: No module named 'docutils' make[2]: *** [Makefile:832: geany.html] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [Makefile:835: hacking.html] Error 1 make[2]: Leaving directory '/home/andy/src/Geany/geany/doc' make[1]: *** [Makefile:599: all-recursive] Error 1 make[1]: Leaving directory '/home/andy/src/Geany/geany' make: *** [Makefile:483: all] Error 2 ```
I found the problem.
Recently I changed the python default from 2.7 to 3.7 using [update-alternatives].
I installed python3-docutils (Debian Buster) and now make completes successfully.
Though I wonder if the Geany configuration files need a little tweaking to find the problem before `make` is run. I don't know a better method of checking (I'm not at all familiar with python packages).
Configure checks for rst2html and finds it (shows in your config.log) but IIRC rst2html is part of docutils, so its usually impossible to have one without the other, so there is no specific test for docutils.
If you have an old rst2html installed configure would find it, but if rst2html is python 2/3 agnostic but other parts of docutils are Python 2/3 specific then it would run on your shiny new Python3 but you would get an error if an old docutils was installed, as has happened here.
Or to put it another way, you have rst2html as checked by configure, but it was a broken rst2html. I don't think its up to configure to check that every possible tool works right (except compilers), just that its exists. So I would call this not an error with Geany or even autotools, just your system was broken.
@elextr I think you are right. And not worth keeping this ticket open :)
Closed #2819.
Perhaps the check should be extended.
For the info, rst2html is not optional -- by default (so that distros don't think of leaving that out). The build dependency can be circumvented with --disable-gtkdoc-header.
What do you suggest that it check for? `rst2html` is the part of docutils Geany uses, and that is already tested for.
Looks like the discussion isn't over yet, so I'll reopen the ticket.
What do you suggest that it check for? `rst2html` is the part of docutils Geany uses, and that is already tested for.
It's checking that the file exists, but doesn't check that it works.
Among other things, configure checks to make sure the c compiler works, and that some functions can be found, and work, so checking for a *working* rst2html might not be inappropriate.
Reopened #2819.
Configure checks for different C compiler capabilities because their capabilities change every release and often software has to configure around missing features on old compilers or simply refuse if feature X isn't available.
It seems to me to be a complete waste of time testing that every tool "works" every time someone with a broken system has a problem (sorry @andy5995 not picking on you specifically) what next? doxygen, then cp maybe? and bash? `</end grouch>`
I think it just depends on how likely the case is to happen. There's probably not a lot of people foolishly breaking there python3-related packages like me.
Closed #2819.
github-comments@lists.geany.org