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

[Charles Lepple]

On Sun, Nov 16, 2008 at 10:25 AM, Arnaud Quette <aquette.dev at gmail.com> wrote:
> 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...

Maybe 'README' and 'README.packaging'?

>>> 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?

Old: autoreconf -v && ./configure

Reconfigured today at 14:40 UTC (shows up as '9:40 EDT' even though we
have switched back to EST; it's a bug in Buildbot that has been fixed
a while back).

New: autoreconf -v --install && ./configure

-- 
- Charles Lepple