[bug #59490] target may not be remade if prerequisite has no recipe

[Greg Minshall]

URL:
  

 Summary: target may not be remade if prerequisite has no
recipe
 Project: make
Submitted by: minshall
Submitted on: Fri 20 Nov 2020 06:52:47 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.3
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

i have a feeling this is already known, and maybe accepted, behavior, but it
seems wrong, non-intuitive, to me.

if i have a dependency chain like
++
b1: a1
  touch b1
  touch c1
c1: b1
d1: c1
  touch d1
--

then, if b1 needs to be re-made, d1 will *not* be remade, even though c1's
prerequisite b1 is out of date.

if i change to 'c1: b1;', it works.

i find the behavior surprising, and i would think worthy of changing.  (i'm
guessing this is an optimization?)

with the attached Makefile, a 'make test' will show failure (or, success,
should it succeed).




___

File Attachments:


---
Date: Fri 20 Nov 2020 06:52:47 AM UTC  Name: Makefile  Size: 2KiB   By:
minshall
make test


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59490] target may not be remade if prerequisite has no recipe

[Greg Minshall]

Follow-up Comment #1, bug #59490 (project make):

though maybe it's not so simple?  e.g., if b is remade, but c doesn't change,
then probably d shouldn't change.

i guess my naive hope/expectation is that b will be remade, then c's date/time
will be compared with that of d to decided if d should be remade.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59490] target may not be remade if prerequisite has no recipe

[Greg Minshall]

Follow-up Comment #5, bug #59490 (project make):

thanks, both.

i apologize for my posted question being incomplete!

i'm very sympathetic to this:
> However, your makefile is lying to make; it says that the
> recipe for b1 builds just b1, but in fact it also builds c1
> "behind make's back".
(as, in general, i'd rather be a truth-teller).

i guess for public release, i had better not rely on "&:", until >= 4.3
make(1) become widely distributed.

thanks, by the way, for the fact that (afaict) if i have

b1 c1 &: a1
   
d1: c1
   

but, in a run,  is run, b1 changes, but c1 is *not* changed, then
d1 is *not* remade.

cheers.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #62228] prerequisite based on input file created during processing not created, but no error

[Greg Minshall]

URL:
  

 Summary: prerequisite based on input file created during
processing not created, but no error
 Project: make
Submitted by: minshall
Submitted on: Tue 29 Mar 2022 04:38:56 AM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.3
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

hi.  sorry.  i'm not sure if this is a bug.

in the makefile below, the initial condition should be that ./outputs is
empty, but ./inputs includes a file ./inputs/a.input.  the main goal causes
./inputs/b.input to be created.  a pattern rule should convert
./inputs/%.input to ./outputs/%.output.  and, the sub-goal `processoutputs`
has as prerequisites `${OUTFILES}`, created by text-munging of the files
(then) in ./inputs.  so, when this goal is executed, that includes
./outputs/b.output.  but, ./outputs/b.output is *not* created (which seems
consistent with verbiage in the info pages), *and*, no error is generated
saying "no rule to make ./outputs/b.output..." (or, words to that effect).

the fact that `${OUTFILES}`, when the `diff` command is invoked, includes
./outputs/b.output makes me wonder if there is a bug here?

(but, i'm guessing that dependencies are built when the makefile is read, then
not updated?)

cheers.


INDIR = ./inputs
OUTDIR = ./outputs

INFILES = $(notdir $(shell ls ${INDIR}/*.input))
INFILESASOUT = $(INFILES:.input=.output)
OUTFILES = $(addprefix ${OUTDIR}/,$(notdir ${INFILESASOUT}))
NEWIN = ${INDIR}/b.input
NEWOUT = ${OUTDIR}/b.output

${OUTDIR}/%.output: ${INDIR}/%.input
echo creating $(notdir $@)
cp -p $< $@

.PHONY: all setup processoutputs something clean

all: setup something processoutputs

setup:
@for dir in ${OUTDIR} ${INDIR}; do \
if [ ! -e $${dir} ]; then mkdir $${dir}; fi \
done
@if [[ -f ${NEWIN} ]]; then \
echo error: "${NEWIN} exists -- run \`make clean\`"; \
exit 1; \
fi

# this wants, as dependency,
processoutputs: ${OUTFILES}
@diff <(for i in ${OUTFILES}; do echo $$i; done) <(ls ${OUTDIR}/*)

something:
@touch ${NEWIN}

clean:
@-rm -f ${OUTFILES}
@-rm -f ${NEWIN}







___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: [bug #62228] prerequisite based on input file created during processing not created, but no error

[Greg Minshall]

Eddy,

thanks very much for the reply.  and, for the hints (on better use of
make functions).

>> something:
>>  @touch ${NEWIN}

> It is generally good to let make know what files a rule creates, rather
> than creating files as a side-effect of making a phony target.

i guess this is the key.  in my actual application, the "something" rule
is a "git pull", which updates the file system with files about which my
Makefile has no knowledge (other than that, e.g., they end in ".input").
i guess the "right" solution for me is to do a sub-make at that point,
to make the files in the pattern rules based on the then-current
contents of the file system.

i don't know if it would be worth issuing a warning that a variable used
in determining the dependencies at make startup had changed its value.
i guess it's not even clear when one would re-expand such variables to
check.  maybe at the end of a run (success or failure?) one might
re-expand variables and re-build the dependency graph, and then compare
the second graph with the original, reporting any discrepancies.  but,
again, i've no idea if this issue comes up enough to make that effort
worth the while (or, even, whether one should expect such an approach to
even work, after all the random makefile processing up to that point).

again, thanks for the reply.  and, the tool!

cheers, Greg

Re: [bug #62228] prerequisite based on input file created during processing not created, but no error

[Greg Minshall]

Eddy,

thanks again.  yes, one should re-read manuals.  and, remember what one
reads!

> I confess I don't see how a sub-make would really help there.  I
> generally do my git changes separately from invoking make - and, even
> then, incremental builds sometimes require (at least) a purge of
> generated dependency files, to force their recreation, since
> interdependencies can all too easily have changed - indeed, whole
> subdirectories may have been renamed, which is way outside what I would
> expect make to cope with.  Perhaps others on this list have guidance on
> that.

see the makefile-prime below.  the "all:" target is as before.  the
"allx:" target runs a sub-make when creating a new input file (outside
of make's knowledge).  that sub-make creates the required "output"
files.  then, the "main" make continues to run, to a (presumably)
successful conclusion.  this works for *my* app.  (though,
aesthetically, whether to run the sub-make in "something:" or in
"processoutputs:" isn't clear; sort of i prefer the latter.)

cheers, Greg

INDIR = ./inputs
OUTDIR = ./outputs

INFILES = $(notdir $(shell ls ${INDIR}/*.input))
INFILESASOUT = $(INFILES:.input=.output)
OUTFILES = $(addprefix ${OUTDIR}/,$(notdir ${INFILESASOUT}))
NEWIN = ${INDIR}/b.input
NEWOUT = ${OUTDIR}/b.output

${OUTDIR}/%.output: ${INDIR}/%.input
echo creating $(notdir $@)
cp -p $< $@

.PHONY: all setup processoutputs something clean

all: setup something processoutputs

allx: setup something1 processoutputs

setup:
@for dir in ${OUTDIR} ${INDIR}; do \
if [ ! -e $${dir} ]; then mkdir $${dir}; fi \
done
@if [[ -f ${NEWIN} ]]; then \
echo error: "${NEWIN} exists -- run \`make clean\`"; \
exit 1; \
fi

# this wants, as dependency,
processoutputs: ${OUTFILES}
@diff <(for i in ${OUTFILES}; do echo $$i; done) <(ls ${OUTDIR}/*)

outfiles: ${OUTFILES}

something:
@touch ${NEWIN}

something1:
@touch ${NEWIN}
make --no-print-directory outfiles

clean:
@-rm -f ${OUTFILES}
@-rm -f ${NEWIN}

[bug #62228] prerequisite based on input file created during processing not created, but no error

[Greg Minshall]

Follow-up Comment #2, bug #62228 (project make):

thanks!


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #64886] order-only prerequisite on a .PHONY line makes prerequisite "unmakeable"

[Greg Minshall]

URL:
  <https://savannah.gnu.org/bugs/?64886>

 Summary: order-only prerequisite on a .PHONY line makes
prerequisite "unmakeable"
   Group: make
   Submitter: minshall
   Submitted: Sun 12 Nov 2023 05:13:16 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4.1
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sun 12 Nov 2023 05:13:16 PM UTC By: Greg Minshall 
a buggy makefile can lead to odd behavior (surprise, surprise).

in this case, a target defined (erroneously) as an "order-only" prerequisite
on a .PHONY line, seems to prevent make from ever wanting to create that
target.

given this as a makefile (and, an empty `file.el`, but no `file.elc`):

%.elc: %.el
${EMACS} -f batch-byte-compile $<

.PHONY: all | file.elc
all:
echo all


then


% make file.elc
make: Nothing to be done for 'file.elc'.


(again, `file.elc` does not exist.)  

apologies if this isn't a bug.

if there's no reason to allow order-only prerequisites on a `.PHONY` line,
maybe this construction should cause make to emit an error message?

cheers.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64886>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64886] order-only prerequisite on a .PHONY line makes prerequisite "unmakeable"

[Greg Minshall]

Follow-up Comment #3, bug #64886 (project make):

hi.  thanks for the responses.  no, i'm not claiming that the behavior is
different with or without the "|" (i.e., order-only or not).

i guess only issue might be, "should .PHONY: give an error for order-only
pre-requisites?".  i can't think of a reason such a pre-requisite would make
any sense (i.e., wouldn't be a mistake by the user).  but, i'm not that up on,
e.g., order-only.

and, maybe there's not really a way to detect the condition ".PHONY: +
order-only".  in which case, the current behavior probably stays.

again, thanks.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/