Nut upsdev - Oct 2010 - [nut-commits] svn commit r2610 - branches/silent_build

Citeren Arnaud Quette <aquette op alioth.debian.org>:
> Log:
> Optionaly enable silent build rules, using AM_SILENT_RULES, only if  
> it's supported (requires automake 1.11)
Why do we need a new branch for this? As far as I can see, only the  
below lines are really needed
> +dnl Currently, we only (force) enable silent rules if available
> +dnl Verbose mode can be turned on using "--disable-silent-rules"
> +m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
Since the above first checks if this is available and then enables it,  
I don't see where this might lead to portability concerns. Even it if  
does, we already provide an option to disable this. So instead of  
creating a new branch, it probably requires just a few lines in the  
UPGRADING file (or equivalent) to mention the changed behavior and  
what can be done if it breaks compilation.

Best regards, Arjen
-- 
Please keep list traffic on the list (off-list replies will be rejected)

2010/10/25 Arjen de Korte <nut+devel at de-korte.org <nut%2Bdevel at
de-korte.org>
>
> Citeren Arnaud Quette <aquette at alioth.debian.org>:
>
>
>  Log:
>> Optionaly enable silent build rules, using AM_SILENT_RULES, only if
it's
>> supported (requires automake 1.11)
>>
>
> Why do we need a new branch for this? As far as I can see, only the below
> lines are really needed

mostly for testing on other systems and non gmake targets, while waiting for
systems that have not entered the buildbot ring.
and there are some more lines underway...

 +dnl Currently, we only (force) enable silent rules if
available
>> +dnl Verbose mode can be turned on using
"--disable-silent-rules"
>> +m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
>>
>
> Since the above first checks if this is available and then enables it, I
> don't see where this might lead to portability concerns. Even it if
does, we
> already provide an option to disable this. So instead of creating a new
> branch, it probably requires just a few lines in the UPGRADING file (or
> equivalent) to mention the changed behavior and what can be done if it
> breaks compilation.
>
ATM, this is still theory, and also why I choose this approach. But as told,
I'd like to have some proofs before putting it in the trunk.

this will be part of the remaining things, along with a reference in
configure.txt and some more testing around silencing other things (like the
copy, python / perl calls, asciidoc, ...) using AM_V_GEN.
this shouldn't last more than a week...

cheers,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20101025/bcfe0d7a/attachment.htm>

On Oct 25, 2010, at 3:25 AM, Arjen de Korte wrote:
> Citeren Arnaud Quette <aquette at alioth.debian.org>:
>
>> Log:
>> Optionaly enable silent build rules, using AM_SILENT_RULES, only if  
>> it's supported (requires automake 1.11)
>
> Why do we need a new branch for this? As far as I can see, only the  
> below lines are really needed
Since a number of the other Buildbot slaves were breaking in  
interesting ways, I asked Arnaud to put that change on a branch to  
keep things separate. Merging that branch back in shouldn't be a  
problem.

We might want to keep the silent option off for Buildbot compilation  
because it hides a lot of the flags - that might make it harder to  
figure out things like the "overlinking" problem.