On 5/24/07, Ag. D. Hatzimanikas <[EMAIL PROTECTED]> 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
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
