[bug #18335] Addition of $(math ...) functions

[Dave Korn]

Follow-up Comment #2, bug #18335 (project make):

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))

cheers,
  DaveK


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #18335] Addition of $(math ...) functions

[Paul D. Smith]

Follow-up Comment #3, bug #18335 (project make):

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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #18335] Addition of $(math ...) functions

[Kaz Kylheku]

Follow-up Comment #4, bug #18335 (project make):

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)) )

all:
echo "$(FOUR)"


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

That's what GNU make macros are for. With macros, you can get it down to
$(call 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 )) )
endef

X := 10
Y := 30

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

$ make
echo 40
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:

  target:
   case $@ in ) *.blah ...  
 spanning dozens of lines 
 with lots of nested if and while, and for 
   esac

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 ). It would be icing on the cake.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #18335] Addition of $(math ...) functions

[Paul D. Smith]

Follow-up Comment #5, bug #18335 (project make):

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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make