On Mon, 2014-01-27 at 09:59 -0800, Mark Brown wrote:
> First, let me request that you include the question posed to you,
> in your Reply responses in this email sequence.
This list, like almost all free software (and most technical public)
mailing lists, prefers trimmed interleaved formats, and discourages
top-posting. I leave in the parts of the previous email which are
relevant to the response I provide, and cut out the rest. If you need
to go back and look at previous messages every email to this list is
archived in numerous locations available across the web.
> 1) I think my question was explicit.
You may think so but it manifestly was not, since I provided an answer
to exactly the question you asked, and that was not the answer you
wanted.
> A method for an existing Makefile to test for .FEATURES capabilities
> when it is downloaded to a random linux or Windows make environment
> and existed.
> The Makefile itself when e.g "make <target>" is selected, should be
> able to precede execution of any target with a check of .FEATURES
> to verify the make environment into which it is downloaded.
> Give an example of .FEATURES display/echo in an existing Makefile.,
> both v 3.80 and 4.00 .
I already showed "an example of .FEATURES display/echo in an existing
Makefile."
As for the new request: checking is simple, but you don't say what you
want to do as a result of the check. What do you want to do if a
feature is present? What do you want to do if a feature is not present?
It's hard to give an example with no detail.
In the interests of moving forward, here's some make code you can put in
a makefile (not as part of a recipe; this is make syntax) which will
cause it to exit with an error when the makefile is parsed if this
version of make doesn't support the else-if construct:
ifneq ($(filter else-if,$(.FEATURES)),else-if)
$(error Version $(MAKE_VERSION) does not support else-if)
endif
Note the error function was introduced in GNU make 3.78 (released in
1999) so if you get a version older than that this won't fail.
> 2) Also, please answer the other question posed:
> ---------------------------------------------------------------------------------------------------
> I also want to know if there is a debug mode within make
> in which the Makefile filename and Line Number
> (some Makefiles are huge and distributed over several subordinate
> Makefiles)
> is matched to each automatic variable evaluation within a Target
> evaluation.
> ---------------------------------------------------------------------------------------------------
In GNU make 4.0 the --trace option was introduced. From the NEWS file:
* New command line option: --trace enables tracing of targets. When enabled
the recipe to be invoked is printed even if it would otherwise be suppressed
by .SILENT or a "@" prefix character. Also before each recipe is run the
makefile name and linenumber where it was defined are shown as well as the
prerequisites that caused the target to be considered out of date.
As for automatic variables, the values of those variables are (IMO)
pretty clear by looking at the recipe line in the makefile versus the
output that make prints, and/or just examining the target and
prerequisites.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
