Re: [PATCH 1/2] Trivial correction on document

[Martin Dorey]

My native English speaker intuition says that "if it were" and "if it was" are 
both available there.  https://english.stackexchange.com/a/146382 cites 
Huddleston and Pullum's grammar in agreement.  Other answers suggest the "were" 
form is getting rarer, so maybe it's a good idea to change it, even though it 
was right before.

I just couldn't see the "that that" problem with a line break in between them 
on my phone screen until a non-native speaker pointed it out.  Doh.

On Jun 20, 2017, at 21:14, Cao jin 
mailto:caoj.f...@cn.fujitsu.com>> wrote:

---
doc/make.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/make.texi b/doc/make.texi
index dfa4454..343927b 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -1831,7 +1831,7 @@ more recent than it.
@item
How to update the file @file{foo.o}: by running @code{cc} as stated.
The recipe does not explicitly mention @file{defs.h}, but we presume
-that @file{foo.c} includes it, and that that is why @file{defs.h} was
+that @file{foo.c} includes it, and that is why @file{defs.h} was
added to the prerequisites.
@end itemize
@end ifnottex
@@ -10861,7 +10861,7 @@ into a Guile string and provided as the result of the 
procedure.
@item gmk-eval
@findex gmk-eval
This procedure takes a single argument which is converted into a
-string.  The string is evaluated by @code{make} as if it were a
+string.  The string is evaluated by @code{make} as if it was a
makefile.  This is the same capability available via the @code{eval}
function (@pxref{Eval Function}).  The result of the @code{gmk-eval}
procedure is always the empty string.
--
2.1.0




___
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%7Ced5b6211411e4b2878dc08d4b85c03ef%7C18791e1761594f52a8d4de814ca8284a%7C0&sdata=WeHYB9LMF3RbDODG0tgIqH5gil43n4PmnzTDcog2JaA%3D&reserved=0
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[PATCH 0/2] trivial correction on doc

[Cao jin]

Feel free to massage the commit message if they are not good.

Cao jin (2):
  Trivial correction on document
  Consistent variable name make less confusion

 doc/make.texi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.1.0




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

[PATCH 1/2] Trivial correction on document

[Cao jin]

---
 doc/make.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/make.texi b/doc/make.texi
index dfa4454..343927b 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -1831,7 +1831,7 @@ more recent than it.
 @item
 How to update the file @file{foo.o}: by running @code{cc} as stated.
 The recipe does not explicitly mention @file{defs.h}, but we presume
-that @file{foo.c} includes it, and that that is why @file{defs.h} was
+that @file{foo.c} includes it, and that is why @file{defs.h} was
 added to the prerequisites.
 @end itemize
 @end ifnottex
@@ -10861,7 +10861,7 @@ into a Guile string and provided as the result of the 
procedure.
 @item gmk-eval
 @findex gmk-eval
 This procedure takes a single argument which is converted into a
-string.  The string is evaluated by @code{make} as if it were a
+string.  The string is evaluated by @code{make} as if it was a
 makefile.  This is the same capability available via the @code{eval}
 function (@pxref{Eval Function}).  The result of the @code{gmk-eval}
 procedure is always the empty string.
-- 
2.1.0




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

[PATCH 2/2] Consistent variable name make less confusion

[Cao jin]

In chapter 8.7 "The `call' Function" of `info make`, there is inconsistent
variable name between example and description as following:


  This macro simply reverses its arguments:

 reverse = $(2) $(1)

 foo = $(call reverse,a,b)

Here FOO will contain `b a'.


Using "FOO" in both part for consistency.
---
 doc/make.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/make.texi b/doc/make.texi
index 343927b..589dd53 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -7651,7 +7651,7 @@ This macro simply reverses its arguments:
 @smallexample
 reverse = $(2) $(1)
 
-foo = $(call reverse,a,b)
+@var{foo} = $(call reverse,a,b)
 @end smallexample
 
 @noindent
-- 
2.1.0




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

Re: [bug #51269] Reusing data from targets for prerequisites

[Paul Smith]

On Tue, 2017-06-20 at 17:18 +0200, SF Markus Elfring wrote:
> I guess that it will be noticed once more that implicit rules will work
> in an other way than static pattern rules.

It's important to realize that even though the unfortunate choice of
naming implies otherwise, static pattern rules are in all ways
_explicit_ rules.  They are not and should never be considered implicit
rules.

A static pattern rule is merely a shorthand for writing a bunch of
explicit rules.  So this:

  OBJS = foo.o bar.o biz.o baz.o

  $(OBJS): %.o : %.c
  $(CC) $(CFLAGS) -c -o $@ $<

is in every way equivalent (to make) to writing this:

  foo.o : foo.c
  $(CC) $(CFLAGS) -c -o $@ $<
  bar.o : bar.c
  $(CC) $(CFLAGS) -c -o $@ $<
  biz.o : biz.c
  $(CC) $(CFLAGS) -c -o $@ $<
  baz.o : baz.c
  $(CC) $(CFLAGS) -c -o $@ $<


In fact once make has finished parsing the static pattern rule, there is
no difference between them in its internal structures.  You can,
actually, run "make -p" and you will see all the rules broken out rather
than displayed as a static pattern rule.

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

Re: Checking application of dependencies from make rules without recipes

[Paul Smith]

On Tue, 2017-06-20 at 14:19 +0200, SF Markus Elfring wrote:
> > This applies only to implicit rules, not explicit rules.
> > > Can an explicit make rule also be cancelled anyhow?
> > No.
> 
> Thanks for this clarification.
> 
> This distinction has got important consequences on how the different
> make rule types can and should be ordered relative to each other.

I don't see why it makes a difference in how rule types should be
ordered (I assume that by "ordered" you mean which rules are defined
first in the makefile).

Regardless of the order in which rules appear, an explicit rule is
always used to build a target if it exists.

Only if an explicit rule does not exist will an implicit rule search be
performed.

This is true regardless of whether the explicit rule comes before or
after the implicit rule when parsing the makefile.

Remember that make parses everything in all the makefiles first,
constructing a set of internal data structures representing all the
rules defined in all the makefiles and all of their explicit
relationships, _before_ it tries to build any target.  So by the time
make is ready to build its first target, it already knows everything
defined anywhere in the makefile.

Makefiles are not like the shell or other interpreted languages where
commands are executed as they are parsed.

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

Re: Checking application of dependencies from make rules without recipes

[SF Markus Elfring]

>> How much can make scripts help to manage (optional) programming
>> interface descriptions?
> 
> Are you asking, how can a makefile represent a prerequisite which may be
> built, but is not required to be built and it's not an error if it
> cannot be built?

How do you think about the following approach to determine which source
files can be tried to compile even when interface descriptions are
(temporarily or intentionally) not available?


source_dir::=$(abs_top_srcdir)/$(TARGET)/
ml_sources::=$(addprefix $(source_dir),$(SRC))
mli_sources::=$(wildcard $(source_dir)*.mli)
modules_without_mli::=$(filter-out $(basename $(mli_sources)),$(basename 
$(ml_sources)))
$(info modules_without_mli)
$(info $(sort $(modules_without_mli)))

$(modules_without_mli): %.cmo: %.ml
$$(OCAMLC_CMD) -c $$<


Unfortunately, corresponding messages seem to indicate that my knowledge
and understanding is still incomplete for the application of
static pattern rules.


elfring@Sonne:~/Projekte/Coccinelle/20160205/parsing_c> LANG=C make 
--no-builtin-rules V=1
modules_without_mli
/home/elfring/Projekte/Coccinelle/20160205/parsing_c/ast_c …
…
Makefile:145: target 
'/home/elfring/Projekte/Coccinelle/20160205/parsing_c/ast_c' doesn't match the 
target pattern
…
Makefile:149: warning: overriding recipe for target 
'/home/elfring/Projekte/Coccinelle/20160205/parsing_c/token_c'
Makefile:146: warning: ignoring old recipe for target 
'/home/elfring/Projekte/Coccinelle/20160205/parsing_c/token_c'
…

Regards,
Markus

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

Re: Unlink failure on abort

[Eli Zaretskii]

> Date: Sun, 18 Jun 2017 17:42:51 +0300
> From: Eli Zaretskii 
> Cc: alex...@gmail.com, bug-make@gnu.org
> 
> > I think the problem is that reap_children() is called after 
> > delete_child_targets, so the child jobs can still run
> > while make is trying to delete.
> > 
> > Maybe delete_targets should become part of reap_children (it cannot be 
> > called after reap, because at this
> > point you don't have the target info anymore).
> > 
> > What do you say?
> 
> I will let Paul to chime in and comment about that.  Failing that, I
> will push your changes after trying them on my box here.

Paul, could you please comment on Orgad's proposal above?

TIA

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

Re: [bug #51269] Reusing data from targets for prerequisites

[SF Markus Elfring]

>> * Can it eventually happen that dependencies will not be resolved if
>>   target names do not contain the percent character?
> 
> I can't remember, but a simple experiment should answer that !

I guess that it will be noticed once more that implicit rules will work
in an other way than static pattern rules.
Does the support for placeholder syntax differ there just by the software
design which was intended?


>> * Can another link help in the section “How patterns match” of the
>>   documentation?
> 
> Be specific: to which page (give its URL) do you consider adding a link,
> to where, using which part of the page's text as anchor.

https://www.gnu.org/software/make/manual/html_node/Pattern-Match.html

Are you interested in a better connection between manual sections?


>> I am also interested in data processing for several fields from
>> targets (and not only a single “%” as the usual placeholder).  Will it
>> make sense to capture any more data into corresponding variables?
> 
> There's little point going beyond basic substitution unless we go for
> full regex-based matching and replacement,
> OBJ = $(SRC:s!(.*)/srcroot/(.*)\.c!$1/buildroot/$2.o!)
> or similar, and I doubt make shall aim for that any time soon.

How are the chances to support regular expressions by the make programming
language without invoking external shell commands?

Would you like to use named capturing groups?

Regards,
Markus

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

[bug #51278] Support for the specification of special build properties together with each make rule

[Markus Elfring]

URL:
  

 Summary: Support for the specification of special build
properties together with each make rule
 Project: make
Submitted by: elfring
Submitted on: Tue 20 Jun 2017 03:30:32 PM CEST
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.2.1
Operating System: Any
   Fixed Release: None
   Triage Status: None

___

Details:

Special built-in target names
 are
provided by the make software. Some of them have got special consequences on
the handling of prerequisites and targets.
* .PHONY
* .SUFFIXES
* .INTERMEDIATE
* .SECONDEXPANSION

Such names provide an interface for the specification of additional software
build properties which did not fit into traditional syntax for make rules.
I imagine that it can also become useful to specify desired extra build
settings in front of each rule directly without repeating (special) target
names.
How do you think about to add such a possibility?




___

Reply to this item at:

  

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


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

Re: Checking application of dependencies from make rules without recipes

[SF Markus Elfring]

> This applies only to implicit rules, not explicit rules.
> 
>> Can an explicit make rule also be cancelled anyhow?
> 
> No.

Thanks for this clarification.


This distinction has got important consequences on how the different
make rule types can and should be ordered relative to each other.
Would you like to point any further details out for the combination
(or distribution) of make rules with the same targets?

Regards,
Markus

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

Re: Checking application of dependencies from make rules without recipes

[Paul Smith]

On Tue, 2017-06-20 at 08:28 +0200, SF Markus Elfring wrote:
> The wording “… override a built-in implicit rule (or one you have
> defined yourself) …”might need another clarification.  Does the
> distinction with explicit make rules result in special consequences
> here?
> https://www.gnu.org/software/make/manual/html_node/Makefile-Contents.html#index-explicit-rule_002c-definition-of

The phrase "or one you have defined yourself" modifies the previous
"implicit rule", so it means "or an implicit rule you have defined
yourself".

This applies only to implicit rules, not explicit rules.

> Can an explicit make rule also be cancelled anyhow?

No.

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

Re: [bug #51269] Reusing data from targets for prerequisites

[SF Markus Elfring]

>> Would it make sense to allow that another special syntax will denote
>> additional placeholders (similar to the handling of the percent character)?
> 
> Take a look at
> https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
> 
> It may enable what you want already.

This functionality fits to my advanced software build needs partly.


I find the section “Static pattern rules versus implicit rules” also interesting
in the documentation.
https://www.gnu.org/software/make/manual/html_node/Static-versus-Implicit.html

But it seems that another important detail is missing in this comparison.

* How do you choose the desired pre-requirements?

* Which file names would you specify for the parameter “prereq-patterns”?

Regards,
Markus

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

Re: [bug #51269] Reusing data from targets for prerequisites

[Edward Welbourne]

Markus Elfring (20 June 2017 11:43)
> I got another software development concern for such an use case.
>
> * Can it eventually happen that dependencies will not be resolved if
>   target names do not contain the percent character?

I can't remember, but a simple experiment should answer that !

> * Should the determination of prefixes and suffixes just work here?

Not sure what you mean there, but all the usual automatic variables work
as ever.

> * Can another link help in the section “How patterns match” of the
>   documentation?

Be specific: to which page (give its URL) do you consider adding a link,
to where, using which part of the page's text as anchor.

>> Otherwise, give a specific example of what it is you can't do with
>> the existing syntax.

> I am also interested in data processing for several fields from
> targets (and not only a single “%” as the usual placeholder).  Will it
> make sense to capture any more data into corresponding variables?

There's little point going beyond basic substitution unless we go for
full regex-based matching and replacement,
OBJ = $(SRC:s!(.*)/srcroot/(.*)\.c!$1/buildroot/$2.o!)
or similar, and I doubt make shall aim for that any time soon.

Eddy.

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

Re: [bug #51269] Reusing data from targets for prerequisites

[SF Markus Elfring]

>> Would it make sense to allow that another special syntax will denote
>> additional placeholders (similar to the handling of the percent character)?
> 
> Take a look at
> https://www.gnu.org/software/make/manual/html_node/Static-Usage.html

Thanks for your link.


> It may enable what you want already.

The provided example looks promising.

bigoutput littleoutput : %output : text.g
generate text.g -$* > $@


I got another software development concern for such an use case.

* Can it eventually happen that dependencies will not be resolved if target 
names
  do not contain the percent character?

* Should the determination of prefixes and suffixes just work here?

* Can another link help in the section “How patterns match” of the 
documentation?


> Otherwise, give a specific example of what it is you can't do
> with the existing syntax.

I am also interested in data processing for several fields from targets
(and not only a single “%” as the usual placeholder).
Will it make sense to capture any more data into corresponding variables?

Regards,
Markus

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

Re: [bug #51269] Reusing data from targets for prerequisites

[Edward Welbourne]

Markus Elfring (19 June 2017 19:34):
> The documentation contains the following information:
> “…
> It’s very important that you recognize the limited scope in which automatic
> variable values are available: they only have values within the recipe.
> …”
>
> How are the chances to adjust this software restriction?
>
> I would appreciate if parts from target names can also be occasionally reused
> for prerequisite specifications.
> Would it make sense to allow that another special syntax will denote
> additional placeholders (similar to the handling of the percent character)?

Take a look at
https://www.gnu.org/software/make/manual/html_node/Static-Usage.html

It may enable what you want already.  Otherwise, give a specific example
of what it is you can't do with the existing syntax.

Eddy.

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