GNOME Bugzilla – Bug 606718
Could not create search results directory 'html/search/search'
Last modified: 2010-02-25 17:44:08 UTC
[forwarded from http://bugs.debian.org/564338] introduced with 1.6.2: > make[2]: Entering directory `/build/user-shogun_0.9.1-1-amd64-wEzN_c/shogun-0.9.1/src/octave_modular' > c++ -fPIC -g -O2 -g -Wall -Wno-unused-parameter -Wformat -Wformat-security -Wimplicit -Wparentheses -Wshadow -Wno-deprecated -O2 -pthread -DSWIG_TYPE_TABLE=shogun -DLINUX -DHAVE_POWL -DHAVE_SQRTL -DHAVE_LOG2 -DHAVE_ATLAS -DHAVE_LAPACK -DUSE_GLPK -DUSE_LZO -DUSE_GZIP -DUSE_LZMA -DHAVE_LARGEFILE -DUSE_SHORTREAL_KERNELCACHE -DUSE_HMMPARALLELSTRUCTURES -DUSE_HMMPARALLEL -DUSE_BIGSTATES -DUSE_HMMCACHE -DUSE_REFERENCE_COUNTING -DGPL -DHAVE_DOXYGEN -DHAVE_OCTAVE -DOCTAVE_APIVERSION=37 -DSWIG_TYPE_TABLE=shogun -DLINUX -DHAVE_POWL -DHAVE_SQRTL -DHAVE_LOG2 -DHAVE_ATLAS -DHAVE_LAPACK -DUSE_GLPK -DUSE_LZO -DUSE_GZIP -DUSE_LZMA -DHAVE_LARGEFILE -DUSE_SHORTREAL_KERNELCACHE -DUSE_HMMPARALLELSTRUCTURES -DUSE_HMMPARALLEL -DUSE_BIGSTATES -DUSE_HMMCACHE -DUSE_REFERENCE_COUNTING -DGPL -DHAVE_DOXYGEN -DHAVE_OCTAVE -DOCTAVE_APIVERSION=37 -c -I. -I.. -I. -I.. -I../libshogun -I/usr/include/octave-3.2.3 -I/usr/include -o sg_print_functions.cpp.o sg_print_functions.cpp > doxygen Structure.doxy > Could not create search results directory 'html/search/search' > python2.5 ../.doxy2swig.py --quiet --no-function-definition \ > Structure/doxygen_xml/index.xml Structure_doxygen.i > Traceback (most recent call last): > File "../.doxy2swig.py", line 450, in <module> > main() > File "../.doxy2swig.py", line 446, in main > convert(args[0], args[1], not options.func_def, options.quiet) > File "../.doxy2swig.py", line 424, in convert > p = Doxy2SWIG(input, include_function_definition, quiet) > File "../.doxy2swig.py", line 70, in __init__ > f = my_open_read(src) > File "../.doxy2swig.py", line 44, in my_open_read > return open(source) > IOError: [Errno 2] No such file or directory: 'Structure/doxygen_xml/index.xml' > make[2]: *** [Structure_doxygen.i] Error 1 doxygen Kernel.doxy Could not create search results directory 'html/search/search' $ cat Kernel.doxy INPUT = ../shogun/kernel OUTPUT_DIRECTORY = Kernel XML_OUTPUT = doxygen_xml CREATE_SUBDIRS = NO OUTPUT_LANGUAGE = English FILE_PATTERNS = *.h RECURSIVE = YES EXCLUDE_PATTERNS = */.svn/* *_wrap.h GENERATE_HTML = NO GENERATE_LATEX = NO GENERATE_XML = YES ENABLE_PREPROCESSING = YES VERBATIM_HEADERS = NO QUIET = YES When one adds SEARCHENGINE = NO it works nicely.
I confirm that (from 1.6.2) I have got this message using Boost Quickbook Doxygen toolchain, and that adding <doxygen:param>SEARCHENGINE=NO means that the message no longer appears in the log. But my docs still do not build correctly for reasons unclear, and perhaps unconnected. The above is also reported at: Bug#564338 "Could not create search results directory 'html/search/search'" http://tinyurl.com/yledok9
I think setting GENERATE_HTML = NO SEARCHENGINE = YES is causing this. Please let me know if this is indeed the case for your particular configuration. I'll fix this in the next subversion update.
Previously I did not specify either. Specifying SEARCHENGINE = NO caused the error message to 'go away' but I got no output (from Boost autodoc function which feeds parameters to Doxygen and uses the output XML - in a way that I don't understand - and don't get an doxyfile saved automatically). Has the GENERATE_HTML and/or GENERATE_XML default changed so that I *must* specify GENERATE_HTML=NO and SEARCHENGINE=NO? (This is a showstopper for all Boost Doxygen usage so I have reverted to 1.6.1 and recommended others to do the same for now).
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.6.3. Please verify if this is indeed the case. Reopen the bug if you think it is not fixed and please include any additional information that you think can be relevant.
This problem disappears with 1.6.3 and the Boost Quickbook autodoc Doxygen toolchain now builds correctly for me (without passing <doxygen:param>SEARCHENGINE=NO). Thanks.