GNOME Bugzilla – Bug 738553
configure is unnecessarily needy
Last modified: 2015-04-27 20:39:05 UTC
gtk-doc is unnecessarily needy and restrictive in its build, which is frustrating for those who tried to get away with --disable-gtk-doc flags in other packages. To get this to configure, I delete the as_fn_error statements in configure and nothing bad happened - yet!. I have to manually set this up in mingw, so if it needs to be there say where and how, please. new output: checking for DocBook XML DTD V4.3 in XML catalog... not found checking for DocBook XSL Stylesheets in XML catalog... not found . . gtk-doc was configured with the following options: ================================================== configure: ** Python based tools enabled, using /e/python27/python configure: SGML support disabled, no jade processor available configure: XML PDF support disabled, no dblatex or fop available configure: ** Syntax highlighting of examples enabled, using /bin/vim configure: ** Building regression tests configure: Debug tracing disabled configure: Debug tracing disabled configure: ** Documentation enabled ..... Other than that ... looks like a winner!
Sorry I don't follow. What exactly did you delete in which file? Can you add this as a patch? I only see "as_fn_error", but that is generated code.
Hi, I did not have gtk-doc going, I dont have an XML system set up and I dont know where to put these things if I can download them. I am making gtk-doc out of necessity, required for some other library I need to satisfy yet another ... the configure was stopping because it tried to find something I didn't have, or didn't have in the right place. Ultimately the build succeeded anyway. To get around the configure stop, I made the single change: 12159c12159,12160 < as_fn_error $? "could not find DocBook XML DTD V4.3 in XML catalog" "$LINENO" 5 --- > # { $as_echo $? "could not find DocBook XML DTD V4.3 in XML catalog" "$LINENO" >&5 > # $as_echo $? "could not find DocBook XML DTD V4.3 in XML catalog" "$LINENO" >&6} 12177c12178 < as_fn_error $? "could not find DocBook XSL Stylesheets in XML catalog" "$LINENO" 5 --- > # as_fn_error $? "could not find DocBook XSL Stylesheets in XML catalog" "$LINENO" 5 so the resulting run was, I got the complaints but it went through.
You mean despite --disable-gtk-doc, it was looking for "DocBook XML DTD V4.3 in XML catalog" and stuff and it failed as they are not present?
Or are you trying to actually build gtk-doc. You can definitely build it without the XML stuff, it just won't work then.
Greg, can you please respond? Thanks.
Sorry for the lapse, it wasn't clear you wanted to proceed with me much further. I wanted to make gtk-doc after the --disable-gtk-doc flag wasn't recognized in an attempt to build another library in a chain of dependencies. Ultimately, as I recall, I put that effort aside in favor of ready-built mingw libraries in the msys2 distribution. Today I've re-loaded gtk-doc-1.21, run "make distclean", and tried ../configure from sub-directories using msys2/msys64(mingw64), and two separate installations of mingw/msys (mingw32) - D and E. For unknown reasons only the last installation got past the a.exe test to the above XML stoppage: checking for XML catalog... /usr/local/share/xml/catalog checking for xmlcatalog... /local32/bin/xmlcatalog checking for DocBook XML DTD V4.3 in XML catalog... not found configure: error: could not find DocBook XML DTD V4.3 in XML catalog $ ls /usr/local/share/xml catalog jade-1.2.1 xml-4.3 $ ls /usr/local/share/xml/xml-4.3 ChangeLog catalog.xml dbhierx.mod docbook.cat htmltblx.mod README dbcentx.mod dbnotnx.mod docbookx.dtd soextblx.dtd calstblx.dtd dbgenent.mod dbpoolx.mod ent ================== OK so I've done what I could, to try and configure XML, and it isn't working - at least from the perspective of the configure script. So my plan was, make *any* sort of gtk-doc installation that will *look* like gtk-doc is installed, so that downstream checks will not fail even if the "--disable-gtk-doc" switch is broken. At this point where gtk-doc can't latch into XML, I (the user) need to be instructed to how XML needs to appear - the error message says it could not find XML DTD V4.3, *Where does it look?* The error stop gives me no clue as to what steps are needed for a remedy. rtfm, ok so where is that? If gtk-doc can be built without XML, albeit useless, can the XML connection be inserted afterwards? If I'm willing to accept a broken documentation system, can I use gtk-doc files as placeholders until I've sorted out the other issues?
Greg, this is where the check is implemented: https://git.gnome.org/browse/gtk-doc/tree/m4/gtkdoc_jh_path_xml_catalog.m4 As you have /usr/local/share/xml/catalog we need to check two things: 1) do you have the env-var XDG_DATA_DIRS set and if so does it contain /usr/local/share? 2) can you manually run $ xmlcatalog /usr/local/share/xml/catalog '-//OASIS//DTD DocBook XML V4.3//EN' for me I'd run like this and get the result below: $ xmlcatalog /etc/xml/catalog '-//OASIS//DTD DocBook XML V4.3//EN' file:///usr/share/xml/docbook/schema/dtd/4.3/docbookx.dtd I would prefer to not skip over the XML check as that'd unexpected for users who want docs to be built. If you don't care about the docs, it'd be easier to use --disable-gtkdoc.
Specific answers to your queries are below this, which has more of my own conjecture. The section in the M4 that you reference: if test -z "$XDG_DATA_DIRS"; then dnl if we have no XDG_DATA_DIRS, use the default jh_xml_catalog_searchdirs="/etc:/usr/local/share:/usr/share" else jh_xml_catalog_searchdirs="/etc:$XDG_DATA_DIRS" fi Apparently my search (for a catalog) should have succeeded because share/xml/catalog existed. So presumably XDG_DATA_DIRS is not relevant. The stuff inside the catalog (see below output of "head -40") looks like it might work in some context: should this be working with an MSYS shell? Are there contented MSYS users using XML, and what am I missing? I Notice MSYS replaced "//" with "/" and stuck the NTFS path to / at the begining of the catalog search string. (In reply to comment #7) > Greg, this is where the check is implemented: > https://git.gnome.org/browse/gtk-doc/tree/m4/gtkdoc_jh_path_xml_catalog.m4 Thank you > As you have /usr/local/share/xml/catalog we need to check two things: > 1) do you have the env-var XDG_DATA_DIRS set and if so does it contain > /usr/local/share? It is not set. > 2) can you manually run > $ xmlcatalog /usr/local/share/xml/catalog '-//OASIS//DTD DocBook XML V4.3//EN' greg@Homerw7 ~ $ xmlcatalog /usr/local/share/xml/catalog '-//OASIS//DTD DocBook XML V4.3//EN' No entry for PUBLIC -/E:/mingw/msys/1.0/OASIS/DTD DocBook XML V4.3/EN > for me I'd run like this and get the result below: > $ xmlcatalog /etc/xml/catalog '-//OASIS//DTD DocBook XML V4.3//EN' > file:///usr/share/xml/docbook/schema/dtd/4.3/docbookx.dtd mine were put in xml/xml-4.3: greg@Homerw7 ~ $ ls /usr/local/share/xml/xml-4.3 ChangeLog calstblx.dtd dbcentx.mod dbhierx.mod dbpoolx.mod docbookx.dtd htmltblx.mod README catalog.xml dbgenent.mod dbnotnx.mod docbook.cat ent soextblx.dtd greg@Homerw7 ~ $ head -40 /e/mingw/msys/1.0/local/share/xml/catalog -- ...................................................................... -- -- Catalog data for DocBook XML V4.3 .................................... -- -- File docbook.cat ..................................................... -- -- Please direct all questions, bug reports, or suggestions for changes to the docbook@lists.oasis-open.org mailing list. For more information, see http://www.oasis-open.org/. -- -- This is the catalog data file for DocBook XML V4.3. It is provided as a convenience in building your own catalog files. You need not use the filenames listed here, and need not use the filename method of identifying storage objects at all. See the documentation for detailed information on the files associated with the DocBook DTD. See SGML Open Technical Resolution 9401 for detailed information on supplying and using catalog data. -- -- ...................................................................... -- -- DocBook driver file .................................................. -- PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "docbookx.dtd" -- ...................................................................... -- -- DocBook modules ...................................................... -- PUBLIC "-//OASIS//DTD DocBook CALS Table Model V4.3//EN" "calstblx.dtd" PUBLIC "-//OASIS//DTD XML Exchange Table Model 19990315//EN" "soextblx.dtd" PUBLIC "-//OASIS//ELEMENTS DocBook Information Pool V4.3//EN" "dbpoolx.mod" PUBLIC "-//OASIS//ELEMENTS DocBook Document Hierarchy V4.3//EN" "dbhierx.mod" PUBLIC "-//OASIS//ENTITIES DocBook Additional General Entities V4.3//EN"
This looks like a portability issue regarding MSYS and xmlcatalogs to me. Can you try to talk to people on IRC, e.g. #gnome-hackers and see if they have some ideas?
Ping?
Sorry I missed #9. As I say in the title, "configure is unnecessarily needy", i.e., it requires some setup of XML, which has to be -just right- to pass the testing hurdles. I suppose the complaint should be leveled against XML for not being easy and solid enough, then again that extends to anything that would try to stand on such a shaky foundation. Again as I say, I just tried to get gtk-doc up because other libraries (which I am also disinterested in) couldn't easily ignore the lack of a gtk-doc presence, i.e. --disable-gtk-doc option created its own bugs somewhere else.
To keep you informed - "SGML support" will be dropped from 1.23, its optional already anyway.
Just to update you of my own situation, I found a bug in my windows setup that interacts with new editions of configure; some installation had set PATH_SEPARATOR=";" in the window's user environment (I suspect emacs but haven't investigated). And MSYS inherits this. Recent configures allow the env value to supercede the actual value. This was only detected because it goes looking for adequate support tools, which I have but which the algorithm misses because it is looking at a $PATH with ":" separators (appropriate for MSYS) thinking they should be ";". I don't know if it applied here but the first symptom is to get a "could not find a suitable EGREP" error.
Thanks for letting me know. Does that mean that the xml setup is now discovered propertly?