From: Ramiro Polla <ramiro.polla@gmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v2] ffbuild/commonmak: Fix rebuild check with implicit rule chains
Date: Tue, 20 May 2025 22:28:39 +0200
Message-ID: <CALweWgBz+_1pS+iv+jRJ1uhzvOy63nK4wXdLGyb8wY8=oyxO8w@mail.gmail.com> (raw)
In-Reply-To: <DM8P223MB03658D88C40D392EE223E118BA9FA@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
On Tue, May 20, 2025 at 9:46 PM softworkz .
<softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> > Sent: Dienstag, 20. Mai 2025 21:36
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v2] ffbuild/commonmak: Fix rebuild check
> > with implicit rule chains
> > On Sun, May 18, 2025 at 8:30 AM softworkz <ffmpegagent@gmail.com> wrote:
> > > From: softworkz <softworkz@hotmail.com>
> > > When there's a chain of implicit rules, make treats files generated
> > > inside that chain as intermediate files. Those intermediate files are
> > > removed after completion of make. When make is run again, it normally
> > > determines the need for a rebuild by comparing the timestamps of the
> > > original source file and the final output of the chain and if still
> > > up-to-date, it doesn't rebuild, even when the intermediate files are
> > > not present. That makes sense of course - why would it delete them
> > > otherwise, it would end up in builds being never up-to-date.
> > > But this original by-the-book logic appeared to be broken and has been
> > > worked around by adding all intermediate files to the .SECONDARY
> > > special target, which required extra logic and issues with make clean.
> > >
> > > What broke the up-to-date checking is the dependency file generation.
> > > For the .c files generated by BIN2C the compile target created a .d
> > > file which indicated that the .ptx.o file has a dependency on the
> > > ptx.c file. And that dependency broke the normal make behavior with
> > > intermediate files.
> > >
> > > This patch compiles the BIN2C generated .c files without generating
> > > .d files. In turn the files do not longer need to be added to the
> > > .SECONDARY target in common.mak.
> > >
> > > When interested in those files for debugging, a line can be added to
> > > the corresponding Makefile like
> > >
> > > .SECONDARY: %.ptx.c %.ptx.gz
> > >
> > > Signed-off-by: softworkz <softworkz@hotmail.com>
> > > ---
> > > ffbuild/commonmak: Fix rebuild check with implicit rule chains
> > >
> > > When there's a chain of implicit rules, make treats files generated
> > > inside that chain as intermediate files. Those intermediate files are
> > > removed after completion of make. When make is run again, it normally
> > > determines the need for a rebuild by comparing the timestamps of the
> > > original source file and the final output of the chain and if still
> > > up-to-date, it doesn't rebuild, even when the intermediate files are not
> > > present. That makes sense of course - why would it delete them
> > > otherwise, it would end up in builds being never up-to-date. But this
> > > original by-the-book logic appeared to be broken and has been worked
> > > around by adding all intermediate files to the .SECONDARY special
> > > target, which required extra logic and issues with make clean.
> > >
> > > What broke the up-to-date checking is the dependency file generation.
> > > For the .c files generated by BIN2C the compile target created a .d file
> > > which indicated that the .ptx.o file has a dependency on the ptx.c file.
> > > And that dependency broke the normal make behavior with intermediate
> > > files.
> > >
> > > This patch compiles the BIN2C generated .c files without generating .d
> > > files. In turn the files do not longer need to be added to the
> > > .SECONDARY target in common.mak.
> > >
> > > When interested in those files for debugging, a line can be added to the
> > > corresponding Makefile like
> > >
> > > .SECONDARY: %.ptx.c %.ptx.gz
> > >
> > >
> > > V2
> > > ==
> > >
> > > * Fix MSVC build
> > > (use the universal command pattern)
> > >
> > > Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-
> > 80%2Fsoftworkz%2Fsubmit_commonmak-v2
> > > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-
> > 80/softworkz/submit_commonmak-v2
> > > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/80
> > >
> > > Range-diff vs v1:
> > >
> > > 1: e276f54ffc ! 1: f468ea2431 ffbuild/commonmak: Fix rebuild check with
> > implicit rule chains
> > > @@ ffbuild/common.mak: else
> > > endif
> > >
> > > +%.ptx.o: %.ptx.c
> > > -+ $(CC) $(CCFLAGS) -x c -c -o $@ $<
> > > ++ $(CC) $(CCFLAGS) $(CC_C) $(CC_O) $(patsubst
> > $(SRC_PATH)/%,$(SRC_LINK)/%,$<)
> > > +
> > > +
> > > # 1) Preprocess CSS to a minified version
> > > @@ ffbuild/common.mak: else # NO COMPRESSION
> > > endif
> > >
> > > +%.html.o: %.html.c
> > > -+ $(CC) $(CCFLAGS) -x c -c -o $@ $<
> > > ++ $(CC) $(CCFLAGS) $(CC_C) $(CC_O) $(patsubst
> > $(SRC_PATH)/%,$(SRC_LINK)/%,$<)
> > > +
> > > +%.css.o: %.css.c
> > > -+ $(CC) $(CCFLAGS) -x c -c -o $@ $<
> > > ++ $(CC) $(CCFLAGS) $(CC_C) $(CC_O) $(patsubst
> > $(SRC_PATH)/%,$(SRC_LINK)/%,$<)
> > > +
> > > +
> > > clean::
> > >
> > >
> > > ffbuild/common.mak | 15 ++++++++++++---
> > > 1 file changed, 12 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/ffbuild/common.mak b/ffbuild/common.mak
> > > index 0e1eb1f62b..d9462271d5 100644
> > > --- a/ffbuild/common.mak
> > > +++ b/ffbuild/common.mak
> > > @@ -139,6 +139,10 @@ else
> > > $(BIN2C) $(patsubst $(SRC_PATH)/%,$(SRC_LINK)/%,$<) $@ $(subst
> > .,_,$(basename $(notdir $@)))
> > > endif
> > >
> > > +%.ptx.o: %.ptx.c
> > > + $(CC) $(CCFLAGS) $(CC_C) $(CC_O) $(patsubst
> > $(SRC_PATH)/%,$(SRC_LINK)/%,$<)
> > > +
> > > +
> > > # 1) Preprocess CSS to a minified version
> > > %.css.min: %.css
> > > # Must start with a tab in the real Makefile
> > > @@ -177,6 +181,13 @@ else # NO COMPRESSION
> > > $(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
> > > endif
> > >
> > > +%.html.o: %.html.c
> > > + $(CC) $(CCFLAGS) $(CC_C) $(CC_O) $(patsubst
> > $(SRC_PATH)/%,$(SRC_LINK)/%,$<)
> > > +
> > > +%.css.o: %.css.c
> > > + $(CC) $(CCFLAGS) $(CC_C) $(CC_O) $(patsubst
> > $(SRC_PATH)/%,$(SRC_LINK)/%,$<)
> > > +
> >
> > I'm not a big fan of adding new targets with a stripped-down version
> > of the original rule. It seems like unnecessary duplication, and
> > increases the chance of divergence over time.
> >
> > Instead, I think it's cleaner to use target-specific variables to
> > disable a part of the original rule. For example, in this case, you
> > would disable the dependency generation for just those targets, and
> > end up with something like this:
> > %.html.o: CC_DEPFLAGS =
> > %.css.o: CC_DEPFLAGS =
>
> Hi Ramiro,
>
> I didn't know that one can do that. That's clearly a better way, then.
>
> What about the first line in the COMPILE macro:
>
> define COMPILE
> $(call $(1)DEP,$(1))
> $($(1)) $($(1)FLAGS) $($(2)) $($(1)_DEPFLAGS) $($(1)_C) $($(1)_O) $(patsubst $(SRC_PATH)/%,$(SRC_LINK)/%,$<)
> endef
>
> I haven't traced back what it actually does - is it harmless when
> it's executed in those cases where no dependency file is desired?
>
> If that's fine, I'd send an updated patch with your suggestion.
I had forgotten about that part. It's not triggered with gcc/clang,
but it seems to be triggered when using msvc. I don't have an msvc
setup ready, but I believe you do, right? You can then check with
"make V=1".
Ramiro
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2025-05-20 20:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-18 2:14 [FFmpeg-devel] [PATCH] " softworkz
2025-05-18 6:30 ` [FFmpeg-devel] [PATCH v2] " softworkz
2025-05-20 19:09 ` softworkz .
2025-05-20 19:36 ` Ramiro Polla
2025-05-20 19:46 ` softworkz .
2025-05-20 20:28 ` Ramiro Polla [this message]
2025-05-20 21:13 ` softworkz .
2025-05-20 21:51 ` softworkz .
2025-05-20 23:32 ` [FFmpeg-devel] [PATCH v3] " softworkz
2025-05-23 22:05 ` [FFmpeg-devel] [PATCH v4] " softworkz
2025-05-27 21:41 ` [FFmpeg-devel] [PATCH v5 0/2] " ffmpegagent
2025-05-27 21:41 ` [FFmpeg-devel] [PATCH v5 1/2] " softworkz
2025-05-27 21:41 ` [FFmpeg-devel] [PATCH v5 2/2] ffbuild/commonmak: Consolidate pattern rules for compression softworkz
2025-06-17 16:01 ` [FFmpeg-devel] [PATCH v6 0/2] ffbuild/commonmak: Fix rebuild check with implicit rule chains ffmpegagent
2025-06-17 16:01 ` [FFmpeg-devel] [PATCH v6 1/2] " softworkz
2025-06-17 16:01 ` [FFmpeg-devel] [PATCH v6 2/2] ffbuild/commonmak: Consolidate pattern rules for compression softworkz
2025-06-17 16:41 ` [FFmpeg-devel] [PATCH v6 0/2] ffbuild/commonmak: Fix rebuild check with implicit rule chains softworkz .
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALweWgBz+_1pS+iv+jRJ1uhzvOy63nK4wXdLGyb8wY8=oyxO8w@mail.gmail.com' \
--to=ramiro.polla@gmail.com \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git