From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31707 invoked by alias); 22 Aug 2011 08:47:45 -0000 Received: (qmail 31697 invoked by uid 22791); 22 Aug 2011 08:47:44 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-fx0-f49.google.com (HELO mail-fx0-f49.google.com) (209.85.161.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 22 Aug 2011 08:47:27 +0000 Received: by fxd20 with SMTP id 20so4111372fxd.36 for ; Mon, 22 Aug 2011 01:47:25 -0700 (PDT) Received: by 10.223.17.141 with SMTP id s13mr3353443faa.29.1314002845334; Mon, 22 Aug 2011 01:47:25 -0700 (PDT) Received: from sg-pc.belvok.com ([86.57.137.251]) by mx.google.com with ESMTPS id p4sm3660241fah.25.2011.08.22.01.47.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 01:47:22 -0700 (PDT) Date: Mon, 22 Aug 2011 08:47:00 -0000 From: Sergei Gavrikov To: John Dallaway cc: eCos Developers Subject: Re: Verbose modes for eCos makefiles In-Reply-To: <4E516D64.8000403@dallaway.org.uk> Message-ID: References: <4E516D64.8000403@dallaway.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463803648-1034857994-1314002844=:10862" X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2011-08/txt/msg00006.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463803648-1034857994-1314002844=:10862 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Content-length: 4429 On Sun, 21 Aug 2011, John Dallaway wrote: > Hi Sergei Hi John, > Sergei Gavrikov wrote: > > > It was added a few checks for "V" variable (a verbose level) in eCos > > ``rules.mak`` file and the level of the verbosity is set in a top most > > eCos ``makefile`` (which is auto-generated). The level of verbosity can > > be set from a command line as ``make V=x`` where "x" can be set to 0, 1, > > or 2) > > > > V=0 - silent build (it is equal to a call ``make --silent``) > > V=1 - "semi-silence", when ``make`` outputs a kind of work is > > doing now > > V=2 - full output (it is equal to "old" call of ``make``) > > > > Default level is 1 (semi-silence). IMHO, it is right value and it is no > > need to type ``make V=1`` every time. > > > > Pros (V=1): > > > > - He/she will be know what is running. > > - He/she will be know/learn an order the build process. > > - He/she will see any warnings and possible they will sent us the > > patches to fix it :-) > > > > % make tests > > ... > > CC strtoul.c > > LINK strtoul > > CC memchr.c > > /home/sg/repo/ecos-hg/packages/language/c/libc/string/current/tests/memchr.c: In function ‘main’: > > /home/sg/repo/ecos-hg/packages/language/c/libc/string/current/tests/memchr.c:107: warning: assignment discards qualifiers from pointer target type > > LINK memchr > > ... > > I can appreciate that the "semi-silent" output you are proposing makes > warning messages stand out more clearly, but this appears to be the only > benefit. The existing output already indicates what is running and the > order of the build process. Have I missed something? You are right, it is only benefit (it only added a pretty printing for V=1 choice). Besides I've changed my view since that my post about default verbose level and now I think that nothing has not to been changed from default behaviors, thus, default make outputs for ``make`` and ``make -s`` must not been touched. So, I corrected my patch already (set V=2 by default). > > Cons: > > > > - It is needed to re-built ``ecosconfig`` to get it working. > > > > NOTE: Only a few lines were added to only one source > > host/tools/configtool/common/common/build.cxx > > > > - Very few people work with command-line and they need to know about > > V=x (V=2). > > - eCos ConfigTool (may be "semi-silence" is odd for it, not tested). > > I would also be concerned about the processing overhead on Cygwin hosts > and the possiblility of unexpected output when using multiple eCos > repositories or older eCos host tools. Ah! You are right again. I missed the main thing (compatibility with old tools and repositories (== rules.mak)), however, when I did set value of V to 2 by default, nothing won't change if we will just type "make"). Of course, the checks of "V" variable in every build rule can waste a bit of time, but, output of the long lines in a terminal also takes a time (but, I did not check time penalty). > Is your proposal based on another build system you have used? No. I used GNU make. In my patch the configtool's build.cxx "included" an 1-line *not forced* inclusion to an auto-generated eCos top-level makefile: -include make.mak and "generated" that ``make.mak'' which is # eCos makefile # This is a generated file - do not edit export V := $(if $(findstring s,$(MAKEFLAGS)),0,2) ifneq (,$(or $(filter 0,$(V)),$(filter 1,$(V)))) .SILENT: endif On top of eCos ``rules.mak'' I added # NOTE: default level of verbosity is 2 (full output). V ?= $(if $(findstring s,$(MAKEFLAGS)),0,2) ifneq (,$(or $(filter 0,$(V)),$(filter 1,$(V)))) .SILENT: endif and fixed (added the checks) there for every build rule, e.g. %.o.d : %.c ... ifeq ($(V),1) @echo " CC $(notdir $<)" endif etc. This is almost all. But, I must confess that full patch requires to add many small, however, trivial fixes to eCos config files which uses "make" and "make_object" rules: % grep -rl --include=*.cdl 'make.*{' $ECOS_REPOSITORY 155 This fact and your "Cons." has beaten my small "benefit" :-) and I'm totally agreed with your concern now. So, John, I want to say thank you for your time on thinking about and I must be more accurate with "feature" requests which would break things. Sergei > John Dallaway > eCos maintainer > http://www.dallaway.org.uk/john > ---1463803648-1034857994-1314002844=:10862--