From: Sergei Gavrikov <sergei.gavrikov@gmail.com>
To: John Dallaway <john@dallaway.org.uk>
Cc: eCos Developers <ecos-devel@ecos.sourceware.org>
Subject: Re: Verbose modes for eCos makefiles
Date: Mon, 22 Aug 2011 08:47:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.00.1108220945410.10862@sg-pc.belvok.com> (raw)
In-Reply-To: <4E516D64.8000403@dallaway.org.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4435 bytes --]
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
>
prev parent reply other threads:[~2011-08-22 8:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-13 13:17 Sergei Gavrikov
2011-08-21 20:41 ` John Dallaway
2011-08-22 8:47 ` Sergei Gavrikov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.1108220945410.10862@sg-pc.belvok.com \
--to=sergei.gavrikov@gmail.com \
--cc=ecos-devel@ecos.sourceware.org \
--cc=john@dallaway.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).