#247 man: manpages/docbook.xsl support for base.dir

output: manpages
closed-fixed
XSL (399)
5
2006-05-08
2005-03-25
denisb
No

Please add support for the standard base.dir parameter
as in html/param.xsl.

Discussion

    • labels: 321174 -->
    • milestone: 448120 -->
     
    • assigned_to: nobody --> xmldoc
    • labels: --> 637321
     
    • summary: manpages/docbook.xsl support for base.dir --> man: manpages/docbook.xsl support for base.dir
     
    • labels: 637321 -->
     
    • labels: --> XSL
    • milestone: --> output: manpages
     
  • Logged In: YES
    user_id=118135

     
    • status: open --> closed-fixed
     
  • Logged In: YES
    user_id=118135

    A change for this issue has been added to the current codebase.
    Please test the change with the latest snapshot from:

    http://docbook.sourceforge.net/snapshots/

     
  • denisb
    denisb
    2006-04-16

    • status: closed-fixed --> closed-rejected
     
  • denisb
    denisb
    2006-04-16

    Logged In: YES
    user_id=431345

    I downloaded and tested docbook-xsl-snapshot.zip.

    First, there was a cascade of errors starting with:
    "Error at xsl:with-param on line 289 of
    file:/home/papasan/testbaseid/doc/doctool/xsl/docbookxsl/common/refentry.xsl:
    Variable refname has not been declared. "

    This seems like an obvious error: several templates are
    missing <xsl:param name="refname"/> declarations at the top.

    After I added the missing params, the test failed again:

    java $BUILDROOT/doc/sources/reference/refman.xml \ $XMLDOC/doctool/xsl/docbookxsl/manpages/docbook.xsl \ base.dir=test/

    The output was created in man/man1 instead of test.

    However, I found the man.base.dir parameter, which did work
    as I thought base.dir was supposed to work. I assume that's
    your intention and that base.dir is not used with manpages.

    Thanks very much for your work; hope this response is
    sufficient to fix the problem.

     
  • Logged In: YES
    user_id=118135

    Hi Denis,

    Thanks for the follow-up and for catching the problem
    with the missing param declarations (the reason I
    missed them is that xsltproc does not report them as
    errors or even emit warnings about them being missing).

    I have added the declarations where they had been lacking.
    If possible, please test again with the latest snapshot.
    If you find problems, please move this issue back to
    Status=Open and Resolution=Rejected, and I will try to
    get the probem(s) fixed asap.

    About the base.dir param name, as you discovered, it's
    not supported. In its place is man.base.dir, which
    controls the name of the top-level output dir, and
    man.subdirs.enabled, which is just a boolean and controls
    whether or not manN subdirs are created under the top-
    level output dir. By default, the value of man.base.dir
    is "man", and the value of man.subdirs.enabled is 1,
    so you get man/manN output.

    I will document the new params for the 1.70.0 release.
    Be aware that I may change the names before the next
    release. If I do, they will probably be
    man.output.base.dir and man.output.subdirs.enabled

    Thanks again,

    --Mike

     
    • status: closed-rejected --> pending-fixed
     
  • denisb
    denisb
    2006-04-16

    Logged In: YES
    user_id=431345

    Downloaded and tested docbook-xsl-snapshot.zip, using
    man.base.dir. Works as advertised. Thanks!

     
  • denisb
    denisb
    2006-04-16

    • status: pending-fixed --> open-fixed
     
  • Daniel Leidert
    Daniel Leidert
    2006-04-22

    Logged In: YES
    user_id=1102637

    Is there any possibility to set man.base.dir intially to ''?
    The current solution breaks with a lot of my Makefiles,
    because the manpages are now inside man/* and not inside the
    current directory and I have to define an extra stylesheet
    to say: No, don't use another directory than '.' and don't
    output the manpages to man/man$section. AFAIK no other
    stylesheet makes use of a subdirectory as initial output
    directory. It is further something, which should be handled
    by the installation process and not by the make process. In
    general: Ditto for the initial man.base.dir value.

    Regards, Daniel

     
  • Logged In: YES
    user_id=118135

    A change for this issue has been added to the current codebase.
    Please test the change with the latest snapshot from:

    http://docbook.sourceforge.net/snapshots/

     
    • status: open-fixed --> pending-fixed
     
  • Logged In: YES
    user_id=118135

    I added a new boolean param, man.output.in.separate.dir,
    and set it to zero by default.

    I also changed names of the others to man.output.base.dir
    and man.output.subdirs.enabled.

    In general, I personally think it's a bad idea to have
    the default value of string-valued params to be empty.
    The problem with it is, it gives users no guidance about
    what the value of the param should be. For example, in
    case of man.output.base.dir, if I were to make the default
    of that be an empty string, I am certain that many users
    would set it to a directory name without the trailing
    slash, instead of with that trailing slash, as the
    stylesheets expect.

    So in cases like this, I almost always create a simple
    boolean for flipping the behavior on and off. Users can
    then adjust the values for associated string-valued params
    after turning that on.

     
  • Logged In: YES
    user_id=118135

    I added a new boolean param, man.output.in.separate.dir,
    and set it to zero by default.

    I also changed names of the others to man.output.base.dir
    and man.output.subdirs.enabled.

    In general, I personally think it's a bad idea to have
    the default value of string-valued params to be empty.
    The problem with it is, it gives users no guidance about
    what the value of the param should be. For example, in
    case of man.output.base.dir, if I were to make the default
    of that be an empty string, I am certain that many users
    would set it to a directory name without the trailing
    slash, instead of with that trailing slash, as the
    stylesheets expect.

    So in cases like this, I almost always create a simple
    boolean for flipping the behavior on and off. Users can
    then adjust the values for associated string-valued params
    after turning that on.

     
  • Logged In: YES
    user_id=118135

    A change for this issue has been added to the current codebase.
    Please test the change with the latest snapshot from:

    http://docbook.sourceforge.net/snapshots/

     
  • Logged In: YES
    user_id=1312539

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
    • status: pending-fixed --> closed-fixed