cmake-utils.eclass: set default of CMAKE_VERBOSE=1
 

# @ECLASS-VARIABLE: CMAKE_VERBOSE
# @DESCRIPTION:
# Set to enable verbose messages during compilation.

By default this is deactivated which is inconvenient imo and results in
pastes having minimum information.
I have to tell users every time to recompile with CMAKE_VERBOSE=1 so
that I have proper information on what is going on.

Are there any arguments against this being default?

cmake-utils.eclass: set default of CMAKE_VERBOSE=1
 

Am Freitag, 4. Mai 2012, 18:30:10 schrieb hasufell:
> # @ECLASS-VARIABLE: CMAKE_VERBOSE
> # @DESCRIPTION:
> # Set to enable verbose messages during compilation.
>
> By default this is deactivated which is inconvenient imo and results in
> pastes having minimum information.
> I have to tell users every time to recompile with CMAKE_VERBOSE=1 so
> that I have proper information on what is going on.
>
> Are there any arguments against this being default?

In 95-99% of the build failures we get in kde herd the information is
sufficient. So from my point of view the current behaviour is good.

Greetings

--
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

cmake-utils.eclass: set default of CMAKE_VERBOSE=1
 

On 05/04/2012 08:00 PM, Johannes Huber wrote:
> Am Freitag, 4. Mai 2012, 18:30:10 schrieb hasufell:
>> # @ECLASS-VARIABLE: CMAKE_VERBOSE # @DESCRIPTION: # Set to enable
>> verbose messages during compilation.
>>
>> By default this is deactivated which is inconvenient imo and
>> results in pastes having minimum information. I have to tell
>> users every time to recompile with CMAKE_VERBOSE=1 so that I have
>> proper information on what is going on.
>>
>> Are there any arguments against this being default?
>
> In 95-99% of the build failures we get in kde herd the information
> is sufficient. So from my point of view the current behaviour is
> good.
>
> Greetings
>

I think that as an argument pro CMAKE_VERBOSE=1 because that would
cover 100% instead of 95-99.

cmake-utils.eclass: set default of CMAKE_VERBOSE=1
 

On Fri, May 4, 2012 at 2:29 PM, hasufell <hasufell@gentoo.org> wrote:
> On 05/04/2012 08:00 PM, Johannes Huber wrote:
>> Am Freitag, 4. Mai 2012, 18:30:10 schrieb hasufell:
>>> # @ECLASS-VARIABLE: CMAKE_VERBOSE # @DESCRIPTION: # Set to enable
>>> verbose messages during compilation.
>>>
>>> By default this is deactivated which is inconvenient imo and
>>> results in pastes having minimum information. I have to tell
>>> users every time to recompile with CMAKE_VERBOSE=1 so that I have
>>> proper information on what is going on.
>>>
>>> Are there any arguments against this being default?
>>
>> In 95-99% of the build failures we get in kde herd the information
>> is sufficient. So from my point of view the current behaviour is
>> good.
>>
>> Greetings
>>
>
> I think that as an argument pro CMAKE_VERBOSE=1 because that would
> cover 100% instead of 95-99.
>

I only maintain a couple of cmake-based ebuilds, but I find having the
full compiler command line useful. Without it, I have to guess at what
was actually run.

cmake-utils.eclass: set default of CMAKE_VERBOSE=1
 

Am Freitag, 4. Mai 2012, 14:41:42 schrieb Mike Gilbert:
> On Fri, May 4, 2012 at 2:29 PM, hasufell <hasufell@gentoo.org> wrote:
> > On 05/04/2012 08:00 PM, Johannes Huber wrote:
> >> Am Freitag, 4. Mai 2012, 18:30:10 schrieb hasufell:
> >>> # @ECLASS-VARIABLE: CMAKE_VERBOSE # @DESCRIPTION: # Set to enable
> >>> verbose messages during compilation.
> >>>
> >>> By default this is deactivated which is inconvenient imo and
> >>> results in pastes having minimum information. I have to tell
> >>> users every time to recompile with CMAKE_VERBOSE=1 so that I have
> >>> proper information on what is going on.
> >>>
> >>> Are there any arguments against this being default?
> >>
> >> In 95-99% of the build failures we get in kde herd the information
> >> is sufficient. So from my point of view the current behaviour is
> >> good.
> >>
> >> Greetings
> >
> > I think that as an argument pro CMAKE_VERBOSE=1 because that would
> > cover 100% instead of 95-99.
>
> I only maintain a couple of cmake-based ebuilds, but I find having the
> full compiler command line useful. Without it, I have to guess at what
> was actually run.

How about bump docs for that use case? For example
http://www.gentoo.org/proj/en/qa/backtraces.xml

Cheers
--
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

cmake-utils.eclass: set default of CMAKE_VERBOSE=1
 

On Fri, May 4, 2012 at 3:25 PM, Johannes Huber <johu@gentoo.org> wrote:
> Am Freitag, 4. Mai 2012, 14:41:42 schrieb Mike Gilbert:
>> On Fri, May 4, 2012 at 2:29 PM, hasufell <hasufell@gentoo.org> wrote:
>> > On 05/04/2012 08:00 PM, Johannes Huber wrote:
>> >> Am Freitag, 4. Mai 2012, 18:30:10 schrieb hasufell:
>> >>> # @ECLASS-VARIABLE: CMAKE_VERBOSE # @DESCRIPTION: # Set to enable
>> >>> verbose messages during compilation.
>> >>>
>> >>> By default this is deactivated which is inconvenient imo and
>> >>> results in pastes having minimum information. I have to tell
>> >>> users every time to recompile with CMAKE_VERBOSE=1 so that I have
>> >>> proper information on what is going on.
>> >>>
>> >>> Are there any arguments against this being default?
>> >>
>> >> In 95-99% of the build failures we get in kde herd the information
>> >> is sufficient. So from my point of view the current behaviour is
>> >> good.
>> >>
>> >> Greetings
>> >
>> > I think that as an argument pro CMAKE_VERBOSE=1 because that would
>> > cover 100% instead of 95-99.
>>
>> I only maintain a couple of cmake-based ebuilds, but I find having the
>> full compiler command line useful. Without it, I have to guess at what
>> was actually run.
>
> How about bump docs for that use case? For example
> http://www.gentoo.org/proj/en/qa/backtraces.xml
>

As far as I can tell, such documentation is largely ignored unless
users are pointed to it by a comment on a bug. It would be nice to
avoid having to wait for the user to respond with the updated build
log.

cmake-utils.eclass: set default of CMAKE_VERBOSE=1
 

On 04.05.2012 18:30, hasufell wrote:
> # @ECLASS-VARIABLE: CMAKE_VERBOSE
> # @DESCRIPTION:
> # Set to enable verbose messages during compilation.
>
> By default this is deactivated which is inconvenient imo and results in
> pastes having minimum information.
> I have to tell users every time to recompile with CMAKE_VERBOSE=1 so
> that I have proper information on what is going on.
>
> Are there any arguments against this being default?
>
Hi,
It's been discussed previously here [1]
with nack from cmake-utils.eclass maintainers and general conclusion
that's too "expensive" to write to stdout :/
If you're gonna make it happen this time, I'll owe you a beer...
Cheers,
Kacper

[1]
http://archives.gentoo.org/gentoo-dev/msg_1b58b577fde07f7735ae6b9eb34885be.xml

cmake-utils.eclass: set default of CMAKE_VERBOSE=1
 

On 05/05/2012 12:49 AM, Kacper Kowalik wrote:
> On 04.05.2012 18:30, hasufell wrote:
>> # @ECLASS-VARIABLE: CMAKE_VERBOSE
>> # @DESCRIPTION:
>> # Set to enable verbose messages during compilation.
>>
>> By default this is deactivated which is inconvenient imo and results in
>> pastes having minimum information.
>> I have to tell users every time to recompile with CMAKE_VERBOSE=1 so
>> that I have proper information on what is going on.
>>
>> Are there any arguments against this being default?
>>
> Hi,
> It's been discussed previously here [1]
> with nack from cmake-utils.eclass maintainers and general conclusion
> that's too "expensive" to write to stdout :/
> If you're gonna make it happen this time, I'll owe you a beer...
> Cheers,
> Kacper
>
> [1]
> http://archives.gentoo.org/gentoo-dev/msg_1b58b577fde07f7735ae6b9eb34885be.xml

They should probably be using the emerge --quiet-build option if they're
concerned about the expense of build output going to the console.

Anyway, it seems like verbose would be a good default, with an option to
override it for people who enjoy watching build output scroll by in
their spare time.
--
Thanks,
Zac

cmake-utils.eclass: set default of CMAKE_VERBOSE=1
 

El sáb, 05-05-2012 a las 09:49 +0200, Kacper Kowalik escribió:
> On 04.05.2012 18:30, hasufell wrote:
> > # @ECLASS-VARIABLE: CMAKE_VERBOSE
> > # @DESCRIPTION:
> > # Set to enable verbose messages during compilation.
> >
> > By default this is deactivated which is inconvenient imo and results in
> > pastes having minimum information.
> > I have to tell users every time to recompile with CMAKE_VERBOSE=1 so
> > that I have proper information on what is going on.
> >
> > Are there any arguments against this being default?
> >
> Hi,
> It's been discussed previously here [1]
> with nack from cmake-utils.eclass maintainers and general conclusion
> that's too "expensive" to write to stdout :/
> If you're gonna make it happen this time, I'll owe you a beer...
> Cheers,
> Kacper
>
> [1]
> http://archives.gentoo.org/gentoo-dev/msg_1b58b577fde07f7735ae6b9eb34885be.xml
>

That would be a good step to get
https://bugs.gentoo.org/show_bug.cgi?id=384193

implemented some day ;)

cmake-utils.eclass: set default of CMAKE_VERBOSE=1
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/04/2012 09:37 PM, Mike Gilbert wrote:
> On Fri, May 4, 2012 at 3:25 PM, Johannes Huber <johu@gentoo.org>
> wrote:
>> Am Freitag, 4. Mai 2012, 14:41:42 schrieb Mike Gilbert:
>>> On Fri, May 4, 2012 at 2:29 PM, hasufell <hasufell@gentoo.org>
>>> wrote:
>>>>
>>>> I think that as an argument pro CMAKE_VERBOSE=1 because that
>>>> would cover 100% instead of 95-99.
++

There was a similar rumor about VERBOSE=1 V=1 and the (`emerge -j 2`
induced emerge `--quiet-build`).

But build.log files will get larger and bugzie has this 1MB upload limit.
"File: Enter the path to the file on your computer (1000 KB limit)
(or paste text as attachment)."

We should add an hint to atach compressed build logs (or raise this
limit).

> It would be nice to avoid having to wait for the user to respond
> with the updated build log.

Which may take ages and lead to "RESO/NEEDINFO". Not good.

Greetings,

Michael

- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+k+g8ACgkQknrdDGLu8JDmMAEAi8vT95lr5K 2DkgxZUThy/Yh5
IgfVEVqpm+A3vcBgSZwA/A756k6/WVrJwh2lADr8Sly7hbOpoXYkTkHRO9iu/OVc
=cJST
-----END PGP SIGNATURE-----