* [Buildroot] [PATCHv3] package/ccache: do not force colored diagnostics
2017-02-12 13:30 [Buildroot] [PATCHv3] package/ccache: do not force colored diagnostics Yann E. MORIN
@ 2017-02-12 13:34 ` Thomas Petazzoni
2017-02-12 13:37 ` Yann E. MORIN
2017-02-12 13:34 ` Baruch Siach
2017-02-12 21:39 ` Arnout Vandecappelle
2 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2017-02-12 13:34 UTC (permalink / raw)
To: buildroot
Hello,
On Sun, 12 Feb 2017 14:30:27 +0100, Yann E. MORIN wrote:
> +# Further patch ccache if either the host or target compilers is
compilers -> compiler (I believe, though I'm not an expert in english
grammar)
> +# too old to support colored output diagnostics.
> +ifneq ($(BR2_HOST_GCC_AT_LEAST_4_9)$(BR2_TOOLCHAIN_GCC_AT_LEAST_4_9),yy)
> +define CCACHE_NO_GCC_COLORS
> + sed -i '/if (getenv("GCC_COLORS")/,+3d' $(@D)/ccache.c
Using $(SED) not possible here?
> +endef
> +
> +#HOST_CCACHE_POST_PATCH_HOOKS += CCACHE_NO_GCC_COLORS
Line commented? :-)
Other than that, looks good to me.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread* [Buildroot] [PATCHv3] package/ccache: do not force colored diagnostics
2017-02-12 13:34 ` Thomas Petazzoni
@ 2017-02-12 13:37 ` Yann E. MORIN
0 siblings, 0 replies; 6+ messages in thread
From: Yann E. MORIN @ 2017-02-12 13:37 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2017-02-12 14:34 +0100, Thomas Petazzoni spake thusly:
> On Sun, 12 Feb 2017 14:30:27 +0100, Yann E. MORIN wrote:
[--SNIP--]
> > +# too old to support colored output diagnostics.
> > +ifneq ($(BR2_HOST_GCC_AT_LEAST_4_9)$(BR2_TOOLCHAIN_GCC_AT_LEAST_4_9),yy)
> > +define CCACHE_NO_GCC_COLORS
> > + sed -i '/if (getenv("GCC_COLORS")/,+3d' $(@D)/ccache.c
>
> Using $(SED) not possible here?
I did as was done in the other macro, above.
> > +endef
> > +
> > +#HOST_CCACHE_POST_PATCH_HOOKS += CCACHE_NO_GCC_COLORS
>
> Line commented? :-)
Meh, I again forgot to commit --ammend
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [PATCHv3] package/ccache: do not force colored diagnostics
2017-02-12 13:30 [Buildroot] [PATCHv3] package/ccache: do not force colored diagnostics Yann E. MORIN
2017-02-12 13:34 ` Thomas Petazzoni
@ 2017-02-12 13:34 ` Baruch Siach
2017-02-12 21:39 ` Arnout Vandecappelle
2 siblings, 0 replies; 6+ messages in thread
From: Baruch Siach @ 2017-02-12 13:34 UTC (permalink / raw)
To: buildroot
Hi Yann,
On Sun, Feb 12, 2017 at 02:30:27PM +0100, Yann E. MORIN wrote:
> When GCC_COLORS is set, ccache passes '-fdiagnostics-color' to GCC but
> this flag requires GCC v4.9 or later. Older versions complain about the
> unrecognized command line option.
>
> We could override GCC_COLORS in the environment, but this would not be
> enough since some packages may call directly $(CC) or $(HOSTCC) (like
> makedevs do, as spotted by Thomas).
>
> Since we use the same ccache build for both host and target, we disable
> that behaviour when either the host or target compiler is tool old to
> support this, at the cost of nol onger colorising output diagnostics for
> the one that is recent enough.
>
> Reported-by: Carlos Santos <casantos@datacom.ind.br>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> ---
> Changes v2 -> v2: (Yann)
> - drop the environment variable override (Yann)
> - directly patch ccache (Thomas)
>
> Changes v1->v2 (Carlos)
> Fix indentation, use positive logic and improve the commit message,
> acording to comments from Thomas Petazzoni and Yann E. MORIN.
> ---
> package/ccache/ccache.mk | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/package/ccache/ccache.mk b/package/ccache/ccache.mk
> index f174a5d..a4c2d9f 100644
> --- a/package/ccache/ccache.mk
> +++ b/package/ccache/ccache.mk
> @@ -35,6 +35,16 @@ endef
>
> HOST_CCACHE_POST_PATCH_HOOKS += HOST_CCACHE_PATCH_CONFIGURATION
>
> +# Further patch ccache if either the host or target compilers is
> +# too old to support colored output diagnostics.
> +ifneq ($(BR2_HOST_GCC_AT_LEAST_4_9)$(BR2_TOOLCHAIN_GCC_AT_LEAST_4_9),yy)
> +define CCACHE_NO_GCC_COLORS
> + sed -i '/if (getenv("GCC_COLORS")/,+3d' $(@D)/ccache.c
> +endef
> +
> +#HOST_CCACHE_POST_PATCH_HOOKS += CCACHE_NO_GCC_COLORS
Are you sure?
> +endif
> +
> define HOST_CCACHE_MAKE_CACHE_DIR
> mkdir -p $(BR_CACHE_DIR)
> endef
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 6+ messages in thread* [Buildroot] [PATCHv3] package/ccache: do not force colored diagnostics
2017-02-12 13:30 [Buildroot] [PATCHv3] package/ccache: do not force colored diagnostics Yann E. MORIN
2017-02-12 13:34 ` Thomas Petazzoni
2017-02-12 13:34 ` Baruch Siach
@ 2017-02-12 21:39 ` Arnout Vandecappelle
2017-02-13 16:09 ` Yann E. MORIN
2 siblings, 1 reply; 6+ messages in thread
From: Arnout Vandecappelle @ 2017-02-12 21:39 UTC (permalink / raw)
To: buildroot
On 12-02-17 14:30, Yann E. MORIN wrote:
> When GCC_COLORS is set, ccache passes '-fdiagnostics-color' to GCC but
> this flag requires GCC v4.9 or later. Older versions complain about the
> unrecognized command line option.
>
> We could override GCC_COLORS in the environment, but this would not be
> enough since some packages may call directly $(CC) or $(HOSTCC) (like
> makedevs do, as spotted by Thomas).
>
> Since we use the same ccache build for both host and target, we disable
> that behaviour when either the host or target compiler is tool old to
> support this, at the cost of nol onger colorising output diagnostics for
> the one that is recent enough.
Actually, if the user sets GCC_COLORS in his environment while his host
compiler is too old to support that option, then he's just plain stupid, no?
But anyway, I would tend to say, let's simplify things and do a global
"unexport GCC_COLORS" like we already do for a few other options. IMHO
colourized output is not so useful in Buildroot context. A global unexport is a
lot simpler.
Regards,
Arnout
>
> Reported-by: Carlos Santos <casantos@datacom.ind.br>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> ---
> Changes v2 -> v2: (Yann)
> - drop the environment variable override (Yann)
> - directly patch ccache (Thomas)
>
> Changes v1->v2 (Carlos)
> Fix indentation, use positive logic and improve the commit message,
> acording to comments from Thomas Petazzoni and Yann E. MORIN.
> ---
> package/ccache/ccache.mk | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/package/ccache/ccache.mk b/package/ccache/ccache.mk
> index f174a5d..a4c2d9f 100644
> --- a/package/ccache/ccache.mk
> +++ b/package/ccache/ccache.mk
> @@ -35,6 +35,16 @@ endef
>
> HOST_CCACHE_POST_PATCH_HOOKS += HOST_CCACHE_PATCH_CONFIGURATION
>
> +# Further patch ccache if either the host or target compilers is
> +# too old to support colored output diagnostics.
> +ifneq ($(BR2_HOST_GCC_AT_LEAST_4_9)$(BR2_TOOLCHAIN_GCC_AT_LEAST_4_9),yy)
> +define CCACHE_NO_GCC_COLORS
> + sed -i '/if (getenv("GCC_COLORS")/,+3d' $(@D)/ccache.c
> +endef
> +
> +#HOST_CCACHE_POST_PATCH_HOOKS += CCACHE_NO_GCC_COLORS
> +endif
> +
> define HOST_CCACHE_MAKE_CACHE_DIR
> mkdir -p $(BR_CACHE_DIR)
> endef
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 6+ messages in thread* [Buildroot] [PATCHv3] package/ccache: do not force colored diagnostics
2017-02-12 21:39 ` Arnout Vandecappelle
@ 2017-02-13 16:09 ` Yann E. MORIN
0 siblings, 0 replies; 6+ messages in thread
From: Yann E. MORIN @ 2017-02-13 16:09 UTC (permalink / raw)
To: buildroot
Arnout, All,
On 2017-02-12 22:39 +0100, Arnout Vandecappelle spake thusly:
> On 12-02-17 14:30, Yann E. MORIN wrote:
> > When GCC_COLORS is set, ccache passes '-fdiagnostics-color' to GCC but
> > this flag requires GCC v4.9 or later. Older versions complain about the
> > unrecognized command line option.
> >
> > We could override GCC_COLORS in the environment, but this would not be
> > enough since some packages may call directly $(CC) or $(HOSTCC) (like
> > makedevs do, as spotted by Thomas).
> >
> > Since we use the same ccache build for both host and target, we disable
> > that behaviour when either the host or target compiler is tool old to
> > support this, at the cost of nol onger colorising output diagnostics for
> > the one that is recent enough.
>
> Actually, if the user sets GCC_COLORS in his environment while his host
> compiler is too old to support that option, then he's just plain stupid, no?
>
> But anyway, I would tend to say, let's simplify things and do a global
> "unexport GCC_COLORS" like we already do for a few other options. IMHO
> colourized output is not so useful in Buildroot context. A global unexport is a
> lot simpler.
I agree, too.
Although I could well see that someone is actively developping a package
(with an FOO_OVERRIDE_SRCDIR) and would be interested in having the
colors for that package. In which case they could add a local override
for this specific package, a-la:
FOO_MAKE_ENV += GCC_COLORS=blabla
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 6+ messages in thread