Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User manual: expand pathnames based on configure parameters #152

Open
clepple opened this issue Sep 10, 2014 · 5 comments
Open

User manual: expand pathnames based on configure parameters #152

clepple opened this issue Sep 10, 2014 · 5 comments

Comments

@clepple
Copy link
Member

clepple commented Sep 10, 2014

http://article.gmane.org/gmane.comp.monitoring.nut.user/8680 items 1 and 2

@aquette
Copy link
Member

aquette commented Sep 12, 2014

Right, this is one of the last long-run-issue, where I had no simple solution.

Current situation:

  • all paths are expressed hard-coded using the default /usr/local/ups prefix
  • we already have a big NOTE at the beginning of INSTALL.nut:
    https://github.com/networkupstools/nut/blob/master/INSTALL.nut#L23
    which is turned into HTML:
    http://www.networkupstools.org/docs/user-manual.chunked/ar01s05.html
  • we have nothing in the Configuration chapter,
  • most of all, nothing at the most suitable place (the occurrences)
  • the useful plain text files are not optimized for direct distribution, due to the various asciidoc macros and optimization (comments, anchors, ...). I'm considering, since the beginning, the plain text file generation of Asciidoc, again limited to the useful files.

Early ideas:
I was thinking about spawning a '.in' for each files that includes some paths, and using AC vars (@CONFPATH@ and friends). That's suitable when reading the local docs (i.e. on the computer), but still unsuitable when reading the one from the NUT website

I propose to:

  • apply the '.in' files creation
  • make an Appendix (separate file), containing the note on path, and listing the various installation paths used on distro
  • make a 'path' macro, and replace all existing path occurrences
  • generate the "useful plain text files"

There are still point that remains unclear, such as the list of "useful plain text file', if we should add a 'docs/src' to cleanup the distributed source files, ...

zykh added a commit to zykh/nut that referenced this issue Sep 28, 2014
zykh added a commit to zykh/nut-website that referenced this issue Sep 28, 2014
zykh added a commit to zykh/nut that referenced this issue Sep 28, 2014
@zykh
Copy link
Contributor

zykh commented Sep 28, 2014

We could create a separate .in file filled with AsciiDoc attributes (defaults overwritten with the ones set at configure-time always but when requested to do differently, e.g. for the website; these defaults would work also as fallback values when at configure-time some paths/settings are not given, e.g. --without-udev-dir) and include it wherever we need them:

paths-settings

@clepple clepple changed the title User manual: explain that paths are default, and will be different for distributions User manual: expand pathnames based on configure parameters Jan 2, 2015
@clepple
Copy link
Member Author

clepple commented Jan 2, 2015

I changed the title of the issue because we already have a statement in INSTALL.nut that paths will be different for distributions. We should still revisit the AsciiDoc attributes at some point.

@clepple clepple mentioned this issue Mar 14, 2015
@clepple
Copy link
Member Author

clepple commented Mar 4, 2017

Related to #401 ?

@aquette
Copy link
Member

aquette commented Mar 13, 2017

Indeed related to #401 @clepple.
The solution is in-between @zykh asciidoc attributes and some generic statements on the paths that are different across the various OS, already existing but not fully applied everywhere, as per #401 ...

jimklimov added a commit to jimklimov/nut that referenced this issue Nov 16, 2021
…re-emp002

Fix regression on Eaton EMP002 temperature reading (SNMP)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants