PATCH: SBU method change and bc removal.

Dan Nicholson dbn.lists at gmail.com
Thu May 24 11:01:50 PDT 2007


On 5/24/07, Ag. D. Hatzimanikas <a.hatzim at gmail.com> wrote:
>
> So, it's not possible to store in a variable the abstraction:
> $end - $start
> and take the total seconds of the build while we are doing the
> calculations, can't we?
> That's why I had to write it in the log file first.

You can, you just have to chain the commands together or otherwise run
things in a dedicated subshell. Each make command starts a separate
$SHELL process. But,

target:
    do something && do something else

will go in a single shell since that would be interpreted as a single
command. Or, you can make one long command by just chaining commands
with \.

target:
    set -e; \
    do something; \
    do something else

Here's an example.

$ cat Makefile
foo:
        echo $$$$; echo $$$$
        echo $$$$
        echo $$$$
        start=`date +%s.%N`; \
        sleep 2; \
        end=`date +%s.%N`; \
        perl -e "printf \"%.3f\n\", ( $$end - $$start )"
$ make
echo $$; echo $$
12464
12464
echo $$
12465
echo $$
12466
start=`date +%s.%N`; \
        sleep 2; \
        end=`date +%s.%N`; \
        perl -e "printf \"%.3f\n\", ( $end - $start )"
2.003

The main purpose of using the { } or ( ) in a Makefile is for
redirecting output from multiple commands. Something like:

bar:
        @set -e; \
        { ls; uptime; barf; } > logfile 2>&1

There's a bit of excessive subshelling going on in jhalfs. I may try
to clean this up one of these days.

> > One other thing to think about is that we lose resolution when we just
> > use whole seconds. But, that can be recovered if we use the %N
> > modifier from date.
>
> Does really matters? We are talking about nanoseconds, anyway it's not
> that difficult if you would like to do that.
> The difficult thing these is to win the Spurs and Duncan these days. :)

Right. The nanoseconds don't matter. But tenths of seconds might. In
that case, you can just drop the printf modifier to %.1f or something.

We'll see if the Jazz can come back at home. I don't think they've
lost a game at home yet in the playoffs. I told you the Spurs would be
tough to beat, right? :)

> > But, the same thing could be done with time and a proper TIMEFORMAT
> > variable. So, I think that the using perl instead of bc is a win.
> > Using perl instead of time doesn't really gain anything, though.
> > I'd originally written that, it was because we were trying to figure
> > out how to use dash, which doesn't have a time builtin. But, just
> > forcing bash makes things easier.
>
> This approach is shell agnostic, doesn't depends in Bash internal variables
> like time and so on, and so could be adopted by other shells which is my
> desire also.

True. There are other places in jhalfs where bash is expected, but it
probably doesn't make sense to force bash when another solution is
possible.

> The gain in time is negligible. I've finished one build now with this method,
> and after a check it seems that it takes the same time. Actually it's
> that close, see:
>
>                                 [gcc-pass1]
> Patched Jhalfs : Build time is: 26 minutes and 2 seconds
> Un-patched     : Build time is: 26 minutes and 35 seconds
> or for  [glibc] is exactly the same.
> Build time is:  16 minutes and 27 seconds
> Build time is:  16 minutes and 27 seconds

Looks good.

--
Dan



More information about the alfs-discuss mailing list