On Mon, Jan 04, 2010 at 07:29:51PM -0500, Gaetan Nadon wrote: > > Let's see if we can communicate what this macro does. > > # XORG_WITH_XMLTO > # ------------------- > # Minimum version: 1.5.0 > # > # Check for the availability of xmlto, a front-end to the xsl toolchain. > # Set output variable XMLTO to the full path of the xmlto program found. > # Allows user to override the value for XMLTO > # Define an Automake conditional HAVE_XMLTO > # Provide a feature "--with-xmlto" where values can be: > # auto: set HAVE_XMLTO=1 if xmlto program is present > # yes: set HAVE_XMLTO=1 if xmlto program is present > # no: set HAVE_XMLTO=0 > # > ]) # XORG_WITH_XMLTO > > > I am wondering if we need the AC_ARG_VAR to supply a path to xmlto. I > noticed only document kind of tools have this (e.g. asciidic, groff). > All other tools in the toolchain (a total of about 32) are expected to > be properly installed and in the PATH.
I have no idea on this. Iirc the autoconf documentation recommends that AC_ARG_VAR is used with any variable used by AC_PATH_PROG, and this is how it is currently done in exiting uses cmlt. > > The value of the XMLTO variable should not be unset when user says "no". > The path to the tool and the decision of not using are separate issues. > It's normal to have xmlto and not wanting to build the documentation. > The Automake HAVE_XMLTO conditional is the variable to use for this > decision, not a blank tool path. In addition, automake caches the value > of XMLTO, so there could be trouble ahead. If I understand things correclty, unsetting XMLTO is only local to the configure script. It may be a bad coding trick to tell that we want to ignore its value, but it won't affect the value seen by make later on. > > Next I'll check the candidate users of this macro to test if it's really > "generic" and useful. There is also the asciidoc in libXi which seems > very similar to xmlto in usage. > Thanks a lot for your help on this. I'm really not an expert in autotools, So my initial patch was really just a Draft to start the discussion. -- Matthieu Herrb _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
