On Fri, Jun 14, 2019 at 2:58 AM David A. Wheeler <address@hidden> wrote:
>
> On Thu, 13 Jun 2019 18:18:15 +0100, Tim Murphy <address@hidden> wrote:
> > builtin functions can check their arguments to some extent. Interesting to
> > wonder if user defined ones can.
> > we don't even have $(equals) or a way to know the number of arguments that
> > were supplied or any mathematical operations with which to compare. So when
> > something is called wongly it charges on to the end, evaluating blindly to
> > who knows what and we can spend hours trying to tease out the cause of a
> > missing compiler option .... but.....we are focused on the saving of a tiny
> > bit of typing.
>
> It's not the typing, it's the reading. When 20% of the lines makes a user-defined
> function call (my situation), simplifying the function call matters.
>
> Equals and math operations can be implemented using $(shell ...).
> If you think more are needed, that sounds like a proposal, go ahead and make it.
> There's no conflict between this syntax proposal & adding more built-in functions.
No but as you can imagine, changes in syntax generate debate since we're all going to end up reading the next set of botched makefiles that the guy learning make has strung together in some exciting new misunderstanding for us to fix.
This is a matter of cost of
native functions vs $(shell ...) .
$(shell) is a big problem but it gets used because it seems like the only way to deal with the shortage of builtin functions. There is a way to build new builtin functions now and dynamically load them. Pity that doesn't seem to have been noticed much.
Linux kernel build system highly exploits recursive building.
So, I avoid using $(shell ...) in the recursively-invoked Makefiles.
--
Best Regards
Masahiro Yamada