On Fri, Jun 08, 2018 at 03:47:14AM +0200, Guillem Jover wrote: > On Tue, 2018-06-05 at 18:32:21 +0200, Adam Borowski wrote: > > Here's a patch to turn on colorized diagnostics via dpkg-buildflags if > > DEB_BUILD_OPTIONS includes "color". [...] > > To read such a log, you print it to a terminal, less -R, ansi2html or so on. > > I hope you don't intend for this to be the default in the future, as I > expect it might wreak havoc. :)
Havoc that causes FTBFS: not with any not thoroughly insane build system. To get a failure, a package would need to either parse gcc's output (which changes so often) or have weird assumptions about build flags (which would break if you change similar options). Havoc that causes garbage in logs: yes, unless the tool that reads build logs understands color. Thus, even though I do wish to request "color" to be enabled on buildds when/if #875439 is done, the option still wouldn't be the default to avoid breaking custom build setups we don't control. Out of ~2% packages that output color already even though they shouldn't, the vast majority don't do so from gcc (usually java or some test suite); one example of hard-coded -fdiagnostics-color=always: https://buildd.debian.org/status/fetch.php?pkg=seafile-client&arch=amd64&ver=6.1.8-1&stamp=1527948413&raw=0 > > I'm not sure what to do with LDFLAGS: currently dpkg-buildflags gives > > options like -g -O2 only to ${LANG}FLAGS, these are supposed to be given > > when linking as gcc fails to do some optimizations otherwise (especially > > with LTO), but some packages pass LDFLAGS only. Should we add > > -fdiagnostics-color=always there as well? This would be redundant but > > harmless for properly written makefiles. > > I think using a flag here is also a bit suboptimal, and it clutters the > compiler flags. But I don't see any other way to force colors for gcc > and clang. The presence of GCC_COLORS envvar enables at most auto mode, > and clang does not seem to support any envvar. :/ I agree: a flag that affects output rather than compilation should use an env var; most programs with conditional color indeed use env vars (without any standardization...). It would be probably good to ask gcc's upstream to do so -- but that wouldn't happen until gcc 9 or 10. > So, thanks for the patch! It's missing an update to the man page > though. Not sure where to put it in: the man page talks mostly about feature flags; the only generic one is "noopt" in another section. > About the option name, I'd probably use "colors", but that > does not really describe its nature, which is to force them, perhaps > "colors-forced" or "colors-always" but that's a bit long. This is kind of a bike shedding, but no other DEB_BUILD_OPTIONS is in plural, even if more pluralizable than "color". As for "-forced" or "-always", most package building comes via a wrapper that redirects build logs somewhere, thus piping is an implementation detail that doesn't interest the user -- I think that'd make "-forced" puzzling. For this reason, I'd stick with a short name. > I'd probably also force DPKG_COLORS=always from dpkg-buildpackage if > the option is set. dpkg-buildpackage you say? I was planning to ask to include env vars in debhelper, as the vast majority of packages use debhelper, and not all build entry points go through dpkg-buildpackage -- but then, if you do incremental attempts by running debian/rules build directly, you're almost always on a terminal. Thus, setting them in dpkg-buildpackage might indeed be better. As for env vars themselves, they tend to be tool-specific. One standardization effort I've seen uses CLICOLOR_FORCE=1: https://bixense.com/clicolors/ which is supported by cmake and waf, and requested inclusion elsewhere (including gcc and clang). The name is goofy (apparently comes from OSX), but does what we want. Thus, having dpkg-buildpackage be the tool that set CLICOLOR_FORCE=1 and DPKG_COLORS=always sounds like a good idea. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄⠀⠀⠀⠀ (funeral doom metal).
