Verbose modes for eCos makefiles

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Verbose modes for eCos makefiles

Sergei Gavrikov-4
Hi

I've written a few small patches to add a bit of sugar for eCos build
process when ``ecosconfig`` and ``make`` are used from command line.

Example:

  % ecosconfig new pid
  % ecosconfig tree
  % make
    GEN   mlt_arm_pid_ram.ldi
    GEN   mlt_arm_pid_rom.ldi
    GEN   mlt_arm_pid_ram.h
    GEN   mlt_arm_pid_rom.h
  headers finished
    GEN   ecos.mak
    GEN   arm.inc
    GEN   heapgeninc.tcl
    GEN   heaps.cxx
    CC    hal_misc.c
  ...
    CXX   errno.cxx
    AR    libtarget.a
    CC    vectors.S
    GEN   target.ld
  build finished

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
  ...

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).
  - ?


About ``make`` and ``make_objects`` rules in eCos config files (CDL).

Fortunately, it is not required to fix the lines which call any compiler
or generator. I did not use a function to wrap the calls and only added
1 "echo-line" by a condition per a "generator", e.g.:

  --- a/packages/hal/synth/arch/current/cdl/hal_synth.cdl
  +++ b/packages/hal/synth/arch/current/cdl/hal_synth.cdl
  @@ -65,6 +65,7 @@ cdl_package CYGPKG_HAL_SYNTH {

       make {
           <PREFIX>/lib/target.ld: <PACKAGE>/src/synth.ld
  +        $(if $(filter 1,$(V)),@echo "  GEN   $(notdir $@)")
           $(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH) $(ACTUAL_CFLAGS) -o $@ $<
           @echo $@ ": \\" > $(notdir $@).deps
           @tail -n +2 target.tmp >> $(notdir $@).deps


NOTE: May be you offer/know a better 1-liner. I've "invented" it,
      because it was not possible to use make's "ifeq/ifneq" there.

Thus, it seems to me we will not break eCos build process when we will
fix the eCos config files.

FYI: I already have the patches for arm/synth/i386/memalloc eCos config
files. Also a check for V-variable was added to eCos examples/Makefile.

Well, if you do not see any pitfalls in such a modernism I can send
the patches to eCos Bugzilla, otherwise, please forget it.

I'm sorry for this long post (in a fact, I could write, I would add a
few checks for "V" variable to eCos makefiles. Do you agree with it?


Sergei
Reply | Threaded
Open this post in threaded view
|

Re: Verbose modes for eCos makefiles

John Dallaway-2
Hi Sergei

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?

> 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.

Is your proposal based on another build system you have used?

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john
Reply | Threaded
Open this post in threaded view
|

Re: Verbose modes for eCos makefiles

Sergei Gavrikov-4
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
>