On Mon, 2018-12-03 at 13:36 +0100, Marcin Kasperski wrote: > > > I tried using the following snippet: > > > > > > OUTPUT/something : > > > mkdir -p OUTPUT > > > $(file > $@, something) > > > (…) > > > > That's the defined behaviour. > > All variables are evaluated and all functions called before any > > commands are run. > > It's the result of that evaluation that is the text of the commands > > to be run, after all. > > 1. The fact that second line is evaluated, and has it's functions > called before first line is run, is not that obvious. > 2. The behaviour of this very example is extremely confusing. > 3. … and it makes $(file) almost useless in recipes (it can't be used > to append something to file generated by command, it can't be used to > read file generated by command, it can't be coordinated with anything > done by recipe in general) > > Abstractly speaking: $(file) is syntactically similar to make > functions, but in fact it has absolutely different behaviour (other > make functions are mostly idempotent and functional, $(file) is all > about side effects). So handling it in the same way is not > necessarily > good idea. In particular $(file >) doesn't calculate and return > anything, it's not the function and will never be.
This is incorrect. file is treated exactly like every other function. It does expand: it expands to the empty string. It is certainly not the only function which is all about side-effects. There are other functions that work the same way: eval, info, and the conditionals (sometimes). shell is all about side-effects. Etc. Having file behave differently than all the other expansions would be confusing and isn't justified IMO. See my response in Savannah for ways to deal with file expansion rules. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
