headers
Joerg Sonnenberger | 2 Apr 2011 03:28
Picon

Hashing support for make

Hi all,
the attached patch implements the :th modifier. It is intended to cut
down the output for MKREPRO=yes. This reduces the amount of IO for
verbose builds and also avoids copying data, so it should over all be at
least performance neutral.

The hash function is Murmurhash3, choosen because it is compact, fast and
relatively collision resistent.

Joerg
Attachment (hash.diff): text/x-diff, 5244 bytes
Permalink | Reply | 1 comment |
headers
David Holland | 2 Apr 2011 05:54
Picon

Re: Hashing support for make

On Sat, Apr 02, 2011 at 03:28:36AM +0200, Joerg Sonnenberger wrote:
 > the attached patch implements the :th modifier. It is intended to cut
 > down the output for MKREPRO=yes. This reduces the amount of IO for
 > verbose builds and also avoids copying data, so it should over all be at
 > least performance neutral.

Other than the name of the modifier, I like it.

As for the name of the modifier, how about just "hash"? While ~all of
the existing modifiers are cryptic, they're the names of operations
and transforms, and I think it's generally better for them to be like
function names than like sed commands.

Changing old ones is problematic, but I think ideally new ones should
be words.

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 0 comments |
headers
Joerg Sonnenberger | 6 Apr 2011 03:00
Picon

Moving to --sysroot=$D for compiler invocations

Hi all,
attached is a patch to clean up some issues with the --sysroot support
in our GCC patches. It also changes the infrastructure to switch to
using --sysroot=$D instead of the combination of -B, -nostdinc,
-isystem, -nostdlib, -L, -Wl,-rpath etc. This makes it a lot cleaner and
easire to integrate other modern compiler drivers.

There is one down side: it currently breaks PCC. I'm working on that
separately, but PCC already has issues with the use of two -B options,
so I don't consider this a show stopper.

Joerg
Attachment (src.diff): text/x-diff, 15 KiB
Permalink | Reply | 0 comments |
headers
der Mouse | 8 Apr 2011 18:54

make(1) variable expansion inconsistency

Quite some time back, I wrote about problems building some software
because make(1) was overriding Makefile-set variables with
command-line-set variables only sometimes.

This is all on 4.0.1.

I believe I know when the "sometimes" is.  Consider this Makefile:

	V = makefile
	foo: xyz-${V}
	F:= xyz-${V}
	bar: ${F}
	xyz-cmd: .PHONY
		echo building xyz-cmd
	xyz-makefile: .PHONY
		echo building xyz-makefile

Now, consider "make V=cmd foo" and "make V=cmd bar".  They should be
identical, right?

Nope.

% make V=cmd foo
echo building xyz-cmd
building xyz-cmd
% make V=cmd bar
echo building xyz-makefile
building xyz-makefile
%
(Continue reading)

Permalink | Reply | 6 comments |
headers
der Mouse | 8 Apr 2011 20:57

Re: make(1) variable expansion inconsistency

A little while ago, I wrote (of make(1)) that

> It appears that variable expansion on dependency lines allows
> command-line settings to override Makefile settings, but that
> variable expansion when doing a var:=value setting doesn't.

PR now filed: toolchain/44844.  It includes the fix I'm using.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 0 comments |
headers
Joerg Sonnenberger | 8 Apr 2011 21:17
Picon

Re: make(1) variable expansion inconsistency

On Fri, Apr 08, 2011 at 12:54:47PM -0400, der Mouse wrote:
> Now, consider "make V=cmd foo" and "make V=cmd bar".  They should be
> identical, right?

$ nbmake-amd64 V=cmd bar
echo building xyz-cmd
building xyz-cmd

Works for me on current. I doubt anyone cares about fixes for bugs
specific to netbsd-4's make...

Joerg
Permalink | Reply | 3 comments |
headers
der Mouse | 8 Apr 2011 21:45

Re: make(1) variable expansion inconsistency

> Works for me on current.  I doubt anyone cares about fixes for bugs
> specific to netbsd-4's make...

Last I heard, NetBSD still supported 4.x (and will until 6.0 comes out).

Is my understanding wrong?

Or does NetBSD no longer care about bugfixes for supported software?

Or what?

(Your jump from "not present on current" to "specific to netbsd-4"
leads to an incorrect conclusion as well as being logically invalid.
The bug _isn't_ specific to netbsd-4's make; it appears in 1.4T and
probably everything in between, quite likely even some other BSD-family
makes.  But all this is a side note.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 2 comments |
headers
Simon J. Gerraty | 9 Apr 2011 01:34

make: time stamps

In my build at work, we like to have timestamps at various places,
to help track where all the time is going.
This is currently done by running date(1), but it would be more
efficient to do it from make itself.
The patch below adds :tL (localtime) and :tU (UTC) as modifiers to cause
us to treat the current value as a fmt string for strftime.

So:

$ bmake -r -V '${The time is %c:L:tU}' -V '${Which is %Y-%m-%d %T %Z:L:tL}'
The time is Fri Apr  8 23:31:01 2011
Which is 2011-04-08 16:31:01 PDT
or
TIME_FMT=' <at>  %s [%Y-%m-%d %T]'
bmake -V '${TIME_FMT:tL}'                               <
 <at>  1302305562 [2011-04-08 16:32:42]

Index: var.c
===================================================================
RCS file: /cvs/juniper/src/buildtools/bmake/var.c,v
retrieving revision 1.37
diff -u -p -r1.37 var.c
--- var.c	7 Mar 2011 17:22:18 -0000	1.37
+++ var.c	8 Apr 2011 23:21:53 -0000
 <at>  <at>  -2291,6 +2291,21  <at>  <at>  VarChangeCase(char *str, int upper)
    return Buf_Destroy(&buf, FALSE);
 }

+static char *
+VarStrftime(const char *fmt, int zulu)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Simon J. Gerraty | 9 Apr 2011 07:05

Re: make(1) variable expansion inconsistency

der Mouse writes:
>Last I heard, NetBSD still supported 4.x (and will until 6.0 comes out).

Whether that is so or not, is probably irrelevant in this case.

4.x's make(1) is clearly adequate for building 4.x

Anyone who wants more, can easily either build -current make,
or bmake (basically the same thing).

--sjg
Permalink | Reply | 0 comments |
headers
David Holland | 9 Apr 2011 09:36
Picon

Re: make: time stamps

On Fri, Apr 08, 2011 at 04:34:44PM -0700, Simon J. Gerraty wrote:
 > In my build at work, we like to have timestamps at various places,
 > to help track where all the time is going.
 > This is currently done by running date(1), but it would be more
 > efficient to do it from make itself.
 > The patch below adds :tL (localtime) and :tU (UTC) as modifiers to cause
 > us to treat the current value as a fmt string for strftime.

Once again: how about using words as the modifier names?

(thus, :localtime and :gmtime)

 > $ bmake -r -V '${The time is %c:L:tU}' -V '${Which is %Y-%m-%d %T %Z:L:tL}'

that is, to be honest, really ugly. :-(

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 2 comments |

Gmane