[Nut-upsdev] [nut-commits] svn commit r1557 - trunk

[Arnaud Quette]

2008/11/16 Arjen de Korte <nut+devel at de-korte.org>:
> Citeren Charles Lepple <clepple at gmail.com>:
>
>> With GNU software, the INSTALL file is typically boilerplate
>> information on how to invoke the ./configure script. Not sure if
>> there's a way around that.
>
> In that case, we may want to rename our existing INSTALL file, so that
> it doesn't get overwritten accidentally. At present, it contains far
> more detailed information, not only how to invoke ./configure (like
> the generated INSTALL does), but also how to install NUT on a system.
>
> Since running ./configure in many cases will be done by a packager,
> but installing the package on a system by the end-user, I would be in
> favor of reflecting this in the documentation as well. So INSTALL
> would be the what the GNU tools come up with and we would create a new
> file for end users on how to configure NUT on their system. At the
> moment we have information in both INSTALL and README, so merging that
> might be an option.

that suits me fine.
part of the thought about rewriting the doc were: too many redundancy,
hard to maintain, not friendly, not well structured, ...
README should be the new target, and be more concise.
In depth doc will be provided by the HTML User manual.
For 2.4, and the first step, we might consider README + some updated .txt...

>> We should distribute the other files you mentioned, but only in a
>> tarball, not in SVN. That should be handled automatically in 'make
>> dist'. It is annoying that the autoconf/autotools authors do not
>> provide a list of generated files, though.
>
> OK, that suits me fine. One question remains, how will the build
> slaves know that they need to generate these? Will this happen
> automatically? They seem to be choking on this now.

isn't buildbot already configured to fire an autoreconf at first?
can it handle build depends one way or another, or simply rely on
what's available on the system?

-- Arnaud