Uh, oh, more bikeshed color questions. Let's try to find answers that follow some principle ... ;-)
* Jack Kelly wrote on Wed, Sep 23, 2009 at 04:12:06AM CEST: > On Wed, Sep 23, 2009 at 8:37 AM, Jack Kelly wrote: > > On Wed, Sep 23, 2009 at 6:42 AM, Ralf Wildenhues wrote: > >> * Jack Kelly wrote on Tue, Sep 22, 2009 at 04:33:27AM CEST: > >>> + * automake.in (define_verbose_tagvar): increase spacing to 12 to > >>> + accommodate MAKEINFOHTML. > >> > >> Ugh, that's very ugly, because it will make it very difficult to align > >> the target name with the abbreviation used for the command, when the > >> build is rushing by. I found 6 to be close to the maximum tolerable > >> length. Can we either agree to create unaligned output, or abbreviate > >> MAKEINFOHTML somehow? > > > > Can we go to 8? If we have 8, I can change this to `INFOHTML' and it > > means `MAKEINFO' is still OK. > > Another thought: There's currently 2 spaces of padding that are > unconditionally output. If we cut those when the tag is more than 6 > characters long, the output would look like: > > MAKEINFO foo.info > CC bar.o > CCLD bar > > which would look OK but keep the 6 character limit on tags. What are > your thoughts? I don't mind lowering to one space between tag and target. I would like to keep the two-space indentation of each line, for greppability: Currently, most automake-generated rules that echo commands use exactly one leading space in normal verbose mode, which provides you with a way to 'grep -v' them from e.g., 'make -s' output. So now how if two spaces stand for kernel-style tag lines. (Never mind the fact that parallel BSD make will eat leading white space.) What if you just give up the alignment of the target for tags longer than 6 characters? Too ugly shed color? Or we go to 8, that might still be tolerable, maybe let's see an example build. And yes, my argumentation isn't very strong, either way. Thanks, Ralf
