Mitch Capper wrote: > *Build colorization* > The build-aux compile/ar-lib debug/colorization patching is hacky and > non-standard. While I have found it quite useful to just be able to turn > an ENV var on to have debug logging probably should be done as a parameter > instead. Downside of a parameter is I need to modify existing build > scripts to pass it, vs ENV vars a user can control. As for the > colorization it colorizes if you define random ENV Vars (but only when in > debug mode as otherwise it doesn't print anything anyway). In addition, > to avoid duplicating lines of code I add the colorization to all commands > then in debug mode print them, and for the actual execution just regex > strip out the ansi sequences. Not the best way to go. Still the > colorization really makes build output far easier to understand and debug > what is going on: > [image: image.png]
The 'compile' and 'ar-lib' scripts are maintained in Automake. Therefore proposed improvements to them should be directed to bug-automake; but you can CC bug-gnulib because the expertise regarding portability and Windows platforms is more here than on bug-automake. One thought, though: The 'compile' and 'ar-lib' scripts are only used on native Windows. If there is an improvement to be made to the logs of a build — and I agree that highlighting the target of a compilation line, like in your screenshot, is useful —, we should think about making the improvement available to users on all platforms. Whether this involves changes in GNU Make or GNU Automake, remains to be seen and discussed. Bruno
