bugmake - Bugs: bug #18335, Addition of $(math ...) functions


bug #18335: Addition of $(math ...) functions

Submitter:  Jim Hanley <dgtlrift>
Submitted:  Tue 21 Nov 2006 01:47:25 PM UTC
Votes: 1
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  3.81 Operating System:  Any
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup

Mon 05 Oct 2009 10:39:43 PM UTC, comment #5: 

No one is suggesting integrating Guile just to provide math functions.  There are a lot of operations which are not covered by the current suite of make functions (take a look at the various enhancement requests, etc. for new ones) and I'm not interested in writing an entirely new procedural language in make.

There certainly would be some performance savings from an "embedded shell", but perhaps not as much as you'd expect since /bin/sh needs to still run programs such as sed, awk, etc. to do most of its work.  As well, while you might save an exec call per instance, even an embedded shell interpreter would have to do a lot of forking: that's just how the shell works.  Probably, to preserve current semantics, it would need to fork for every rule it ran.  On some systems forks are cheap, but definitely not all.

Guile is the standard embedded scripting language for GNU.  It also has a syntax that meshes well with make's syntax, which already relies on parens etc.  Having shell syntax embedded in a makefile involves a lot more escaping of parenthesis, dollar signs, etc.

And finally, as far as I'm aware there is no embeddable shell interpreter available anywhere, and I'm sure not interested in writing my own.

Paul D. Smith <psmith>
Group administrator
Mon 05 Oct 2009 07:56:36 PM UTC, comment #4: 

The make program does a lot of work by generating shell script fragments and running them. Not only are the lines of rule bodies shell scripts, but GNU makefiles make other uses of shell features. For instance, calling the find utility to locate targets and such.

Adding math functions to make is a false optimization, and a self-indulgent hack.

You can easily generate $(( expr )) shell syntax and have the shell evaluate it.

Look. Makefile to print two plus two:

.PHONY: all

FOUR := $(shell echo $$(( 2 + 2)) )

        echo "$(FOUR)"

And yes, it's clumsy to type $(shell echo $$(( <expr> )))
instead of just $(expr <expr>).

That's what GNU make macros are for. With macros, you can get it down to $(call expr, <expr>).

If that's too inconvenient, maybe you're stuffing way too much math into the Makefile and not enough of the normal stuff to make things.

.PHONY: all

define expr
$(shell echo $$(( $1 )) )

X := 10
Y := 30

        echo $(call expr, $(X) + $(Y))

$ make
echo 40

If you want to optimize make by moving computation out of sub-shells into the make process, this is a poor place to start, because it's not the common case.

You idiots want to put a Scheme interpreter into make?

Given that half of the make syntax is really shell syntax, which is farmed out to a sub-process, it would be a much better idea to combine make with a shell implementation.

That way, when make processes something like:

       case $@ in ) *.blah ... <complicateed shell script> \
         spanning dozens of lines \
         with lots of nested if and while, and for \

it could be interpreted without forking off a process. This would actually benefit the reams of makefiles which are already written.

Then $(shell ...) could be entirely built in, and, therefore so would the $(( expr )) syntax. At that point, you could implement a shortcut to access that syntax, like $(expr <expr>). It would be icing on the cake.

Kaz Kylheku <kkylheku>
Mon 27 Nov 2006 02:16:36 PM UTC, comment #3: 

My intention was to leave the math functions to the Guile integration.  I'm open to discussion on this point.

If we do decide to create a built-in math section for GNU make, I wouldn't want to see it using the kind of Lisp-like syntax described by Dave.  While I do agree that might be more consistent with make function style, I think it's unnecessarily complicated for the user to have to write it out like that.  I would prefer to see a new function $(expr ...) that takes a math expression and evaluates to the result of the expression... similar to the way the expr(1) program works in the shell.

Paul D. Smith <psmith>
Group administrator
Tue 21 Nov 2006 02:53:54 PM UTC, comment #2: 

Oh, BTW, I would suggest ...

 $(math $(VAL)+($(FOO)/4))

... that a lisp-like (non-reverse Polish) notation might be more consistent with the general style of make here:

$(plus $(VAL),$(divide $(FOO),4))


Dave Korn <davek>
Tue 21 Nov 2006 02:51:36 PM UTC, comment #1: 

  Funnily enough, I was volunteering to write code to move gmsl functions into native code in make itself just the other day:


  Ping Paul?  I could take on this one too, but it's all dependent on getting at least your in-theory consent to accepting such a series of patches.


Dave Korn <davek>
Tue 21 Nov 2006 01:47:25 PM UTC, original submission:  

I've been using a make function library that allows for math processing within a makefile (GMSL,) however, we use these fuctions on every rule and found that it slows the build chain by about 25%.

It would seem much more efficient to do the math processing native within make with some function like $(math $(VAL)+($(FOO)/4))

These functions could be used in all areas of a build from formating text to dynamic creation of linker scripts.

Jim Hanley <dgtlrift>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by kkylheku (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)

    There is 1 vote so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2006-11-22 preynold Carbon-Copy- Added preynold
    2006-11-21 davek Carbon-Copy- Added davek
    2006-11-21 dgtlrift Carbon-Copy- Added dgtlrift

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code