Don't 'multi-line' variables allow you to achieve your main goal?
-- i.e. What I would like to do is achieve a style in which the order of
variable and
rule declarations isn't relevant at all).
You could define a top-level makefile that either defines the multi-line
variables or
includes another file(s) that define target specific ones.
Then, when defining each rule you simply reference the requisite multi-line
rule(s).
I think this is more or less what Tim was suggesting.
Here's an example:
### BEGINNING OF MAKEFILE ###
define build_product1
include shared_vars1
include shared_vars2
product1:
@echo $(MESSAGE1)
$(MAKE) -f target1_mk rule_target1
@echo $(MESSAGE2)
$(MAKE) -f target2_mk rule_target2
# build more stuf...
# undef anything that might be redifined by another
# target
endef
$(foreach goal,$(MAKECMDGOALS), $(eval $(call $(addprefix build_,$(goal)))))
### END OF MAKEFILE ###
Here all the required variables are defined in the shared_vars1 and
shared_vars2.
I can call include either inside or outside the 'build_product1' variable
and the result
is the same.
Alternatively each one of target*_mk could include its own special set of
variables.
On Tue, May 2, 2017 at 6:08 AM, Tim Murphy <tnmur...@gmail.com> wrote:
> If your build gets big enough you'll start to get to the point where the
> single-process parse is longer than the parallel build so be a little
> careful about how many evals you use - I'm speaking from experience. It
> only matters if your build gets big though and if you use a single-makefile
> rather than submakes.
>
> There's always ninja if you decide you want to generate makefiles from
> some other language.
>
> Regards,
>
> Tim
>
>
>
> On 2 May 2017 at 09:03, Martin Dorey <martin.do...@hds.com> wrote:
>
>> I've had the same frustrations, though you've got further in some
>> directions than I have. It feels like we want to be writing in a slightly
>> higher level language. We could generate makefiles from this higher level
>> language, but make seems close to what we want, if we're careful. This
>> seems to be the crux of what we can't do:
>>
>> > So far as I can see there's no way to achieve late expansion of vars in
>> targets
>>
>> The way I do it is to abjure the usual syntax for defining rules. I put
>> the information in variables instead, then $(eval) the rules into existence
>> after all the variables are done. Having a single code site to intervene
>> in all rules has given me a number of other performance and robustness
>> benefits too.
>>
>> On May 2, 2017, at 02:35, Britton Kerin <britton.ke...@gmail.com> wrote:
>>
>> Hi guys, I tried this on help-make but was didn't get any response,
>> so I though I'd try again here. I'm interested in submitting patches to
>> implement something like this, but I don't want to waste my time if it's
>> a total non-starter. I'd like a --late-parse-rules (to parse all of rules
>> after variables) and maybe --order-independent to verify no
>> order-dependent
>> constructs in Makefile. Or something like that.
>>
>> Please let me know if it's a possibility. Here's the original post again:
>>
>> After a pretty large amount of Make I've concluded that one of the things
>> that
>> tends to make make confusing is the fact that it uses linear
>> order-dependent
>> code to express a DAG which isn't linear at all. A Makefile is just be a
>> database of facts about a DAG, so order should be strictly a matter of
>> style,
>> not semantics.
>>
>> One example problem area is with include, where it frequently turns out
>> to be
>> the case that a given include of e.g. generic_build_rules.mk has to be
>> included
>> somewhere in the middle of a Makefile, since some code needs to go before
>> the
>> include and other code after.
>>
>> What I would like to do is achieve a style in which the order of variable
>> and
>> rule declarations isn't relevant at all. Rules for coming close as far
>> as I
>> can see:
>>
>> 1. Never use simply expanded vars
>> 2. Never use if etc, instead use $(if
>> 3. Never use ?= (corollary to 2)
>> 4. Enable .SECONDEXPANSION, and always use $$(VAR) in depends to get lazy
>> eval
>>
>> Are the any non-obvious bad consequences to these (particularly 4)?
>>
>> The last part of the puzzle is what to do about targets themselves. So
>> far as
>> I can see there's no way to achieve late expansion of vars in targets.
>> So if
>> you have generic_build_rules.mk, and you want to introduce a
>> target-specific
>> variable for a rule with a variable in it's target in a Makefile that
>> includes
>> that file, you have an unavoidable order-dependency between the include
>> and the
>> target-specific variable declaration. Is there a way to avoid this that
>> I'm
>> missing?
>>
>> Static pattern rules are another sad case of inevitable order-dependence.
>> They're more robust and yield must less confusing error messages than
>> implicit
>> rules, so it's sad no to be able to use them in an order-independent
>> Makefile.
>>
>> Would it possible to have something like .SECONDEXPANSION that applied to
>> targets and static pattern lists as well (or instead)?
>>
>> This is an area I'd be willing to try to help with if it's deemed
>> possible.
>>
>> Thanks,
>> Britton
>>
>> _______________________________________________
>> Bug-make mailing list
>> Bug-make@gnu.org
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%
>> 2F%2Flists.gnu.org%2Fmailman%2Flistinfo%2Fbug-make&data=01%
>> 7C01%7Cmartin.dorey%40hds.com%7Cdb1b87c5c36242f75d6308d490c0
>> cce1%7C18791e1761594f52a8d4de814ca8284a%7C0&sdata=PjblbjCsTV
>> cU5oDKh8mBBf%2BSvjAmVEbJvOb9SucudqQ%3D&reserved=0
>>
>> _______________________________________________
>> Bug-make mailing list
>> Bug-make@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-make
>>
>
>
> _______________________________________________
> Bug-make mailing list
> Bug-make@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-make
>
>
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
