bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-tar] Monthly backup doesn't expand files, but which are in the


From: Steffen Nurpmeso
Subject: Re: [Bug-tar] Monthly backup doesn't expand files, but which are in the archive
Date: Wed, 31 Aug 2016 13:19:31 +0200
User-agent: s-nail v14.8.10-326-gd22910a

Guten Morgen.

Joerg Schilling <address@hidden> wrote:
 |Steffen Nurpmeso <address@hidden> wrote:
 |>|Even though smake is much older than gmake, I planned to let it die \
 |>|in 1997 but 
 |>
 |> No, please don't.  It is fast and if you provide an .y inference
 |> rule it rocks it.
 |
 |I know that it is fast ;-)
 |It needs 8x less CPU time that GNU make and 10x less CPU time that \
 |SunPro make
 |if I let it run on an up-to-date schilytools tree.
 |
 |Which rule are you missing?
 |It this not sufficient:
 |
 |#       Yacc language
 |.y:

This is an old problem of smake -- i thought i mentioned it
before?  Imagine a makefile

  ${cat} > ${makefile} << \!
  .SUFFIXES: .o .c .x .y
  .c.o:
        $(CC) -I./ $(XINCS) $(CFLAGS) -c $(<)
  .c.x:
        $(CC) -I./ $(XINCS) -E $(<) > $(@)
  .c:
        $(CC) -I./ $(XINCS) $(CFLAGS) $(LDFLAGS) -o $(@) $(<) $(XLIBS)
  !

If i drop the .y .SUFFIXES (note we need no target) then the
following happens

  **********
  ***  . "inline" functions ... 
  *** test program is
  #include <config.h>
  static inline int ilf(int i){return ++i;}
  int main(void){return ilf(-1);}
  *** results are
  smake: Recursion in default rule for '././___tmp130107.y.y.y.y.y.y.y.y'.
  ...yacc  ././___tmp130107.y.y.y.y.y.y.y.y;mv y.tab.c 
././___tmp130107.y.y.y.y.y.y.y.c
  /usr/bin/bison: ././___tmp130107.y.y.y.y.y.y.y.y: cannot open: No such file 
or directory
  smake: Operation not permitted. *** Code 1 from command line for target 
'././___tmp130107.y.y.y.y.y.y.y.c'.
  smake: Couldn't make '././___tmp130107'.
  smake: Leaving  'smake'[1] from directory '/home/sdaoden/src/nail.git'
  smake: Default commandline target: '././___tmp130107'
  smake: Doing                       exit(1)
  *** no

  ..
 |If you like to add builtin rules, just edit /opt/schily/lib/defaults.smk
 |and report your enhancements.

That is too sophisticated for me.. but mainly: it is non-portable.
And i don't need it, in fact.

 |>|willing to change smake.

I like and use it as-is, really.  I have updated your toolchain
the first time since my main machine died, and there was an
immense amount of changes!  So..., i just keep on using it
(again).

 |> My problem was that i had to diversify my makefile because we now
 |> need -lrt on Solaris (for nanosleep(2)), also for
 ..
 |> result used $(<) in a non-inference rule, which smake didn't like.
 |> (Maybe gmake(1) would have complained with .POSIX, but which
 |> i don't use because gmake v3.81 bails for it.)
 ..
 |$< is a dynamic macro that is only defined with inference rules.
 |
 |SunPro make and GNU make expand it to something not documented with \
 |explicit 
 |rules but they use different algorithms. The result is identical for \
 |aprox. 80% 
 |of the cases by chance only. 
 |
 |For this reason, smake warns you that you are using a non-portable \
 |makefile.

This is kind of schizophrenic since the software i maintain
diverges freely without giving notes on that.  But i am thankful
for such portability -- not only against standard text -- notes,
which help to avoid problems at first!
You know, being afraid of portability glitches etc. i didn't use
predefined makefiles at all in the past, but instead used perl to
generate (a) makefile(s) with complete targets, no inference
rules, no special variables.

 |>|If you know of statements in STARvsGNUTAR that are no longer true (the \
 ..
 |> Ooooooh.  Puuuuuh.  I feel it, i feel it ... there is a burnout
 |> syndrome lingering on the horizon.  ._.
 ..
 |If you feel better, please try to send a list.

Already as a young kid i admired the story of the Thermopylae.
(One reason i didn't watch Hollywood billionaires acting, btw.)
I now feel, i am prepared, to withstand -- almost the very same!
Ciao.

--steffen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]