ffbuild/commonmak: Fix rebuild check with implicit rule chains

[softworkz]

V2

• Fix MSVC build
  (use the universal command pattern)

V3

• Skip dependency generation by clearing CC_DEPS instead
  (as suggested by Ramiro - thanks!)

V4

• Always keep .ptx files (as suggested by Timo - thanks)
  Tested all scenarios:
  • .ptx.c and .ptx.gz still get deleted (as intermediates)
  • repeated make shows "up-to-date"
  • removing a .ptx file does not cause a rebuild
    (it's still an intermediate, but an "intermediate to keep")
  • but changing a .ptx does (in case of dev/debugging)
  • changed .cu files always rebuild of course

V5

• First patch remains unchanged
• Added second patch to clean up and consolidate the rules around compression

V6

• Rebased
• Confirmed that it also resolves MSVC-CLang compilation
  (as reported by Kasper Michalow - thanks!)

V7

• As the log line about intermediate file deletion ("RM ....") didn't find much love, this version uses the workaround via the .SECONDARY special make target to prevent intermediate file deletion

V8

• Resubmit due to Patchwork outage

.

[softworkz]

/submit

[ffmpeg-codebot]

Submitted as pull.80.ffstaging.FFmpeg.1747534468635.ffmpegagent@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-80/softworkz/submit_commonmak-v1

To fetch this version to local tag pr-ffstaging-80/softworkz/submit_commonmak-v1:

git fetch --no-tags https://github.com/ffstaging/FFmpeg tag pr-ffstaging-80/softworkz/submit_commonmak-v1

[softworkz]

/submit

[ffmpeg-codebot]

Submitted as pull.80.v2.ffstaging.FFmpeg.1747549830700.ffmpegagent@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-80/softworkz/submit_commonmak-v2

To fetch this version to local tag pr-ffstaging-80/softworkz/submit_commonmak-v2:

git fetch --no-tags https://github.com/ffstaging/FFmpeg tag pr-ffstaging-80/softworkz/submit_commonmak-v2

[ffmpeg-codebot]

On the FFmpeg mailing list, "softworkz ." wrote (reply to this):

> -----Original Message-----
> From: softworkz <ffmpegagent@gmail.com>
> Sent: Sonntag, 18. Mai 2025 08:31
> To: ffmpeg-devel@ffmpeg.org
> Cc: softworkz <softworkz@hotmail.com>; softworkz <softworkz@hotmail.com>
> Subject: [PATCH v2] ffbuild/commonmak: Fix rebuild check with implicit rule
> chains
> 
> 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)/%,$<)
> +
> +
>  clean::
>  	$(RM) $(BIN2CEXE) $(CLEANSUFFIXES:%=ffbuild/%)
> 
> @@ -228,11 +239,9 @@ ALLHEADERS := $(subst $(SRC_DIR)/,$(SUBDIR),$(wildcard
> $(SRC_DIR)/*.h $(SRC_DIR)
>  SKIPHEADERS += $(ARCH_HEADERS:%=$(ARCH)/%) $(SKIPHEADERS-)
>  SKIPHEADERS := $(SKIPHEADERS:%=$(SUBDIR)%)
>  HOBJS        = $(filter-out $(SKIPHEADERS:.h=.h.o),$(ALLHEADERS:.h=.h.o))
> -PTXOBJS      = $(filter %.ptx.o,$(OBJS))
> -RESOURCEOBJS = $(filter %.css.o %.html.o,$(OBJS))
>  $(HOBJS):     CCFLAGS += $(CFLAGS_HEADERS)
>  checkheaders: $(HOBJS)
> -.SECONDARY:   $(HOBJS:.o=.c) $(PTXOBJS:.o=.c) $(PTXOBJS:.o=.gz)
> $(PTXOBJS:.o=) $(RESOURCEOBJS:.o=.c) $(RESOURCEOBJS:%.css.o=%.css.min)
> $(RESOURCEOBJS:%.css.o=%.css.min.gz) $(RESOURCEOBJS:%.html.o=%.html.gz)
> $(RESOURCEOBJS:.o=)
> +.SECONDARY:   $(HOBJS:.o=.c)
> 
>  alltools: $(TOOLS)
> 
> 
> base-commit: eb6dc952cbd479bf43673af9ca0bc83f37f8f329
> --


I just realized that I forgot to mention the specific problem that this
is addressing: Andreas and James had discovered that the up-to-date check
doesn't work properly - in a way that when you run make after make again,
it wants to rebuild the .o files from the BIN2C-generated .c files.

This patch fixes this by making it work in the way it is intended by make.
(https://www.gnu.org/software/make/manual/html_node/Chained-Rules.html) 

sw





_______________________________________________
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".

[ffmpeg-codebot]

On the FFmpeg mailing list, Ramiro Polla wrote (reply to this):

Hi,

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 =

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".

[ffmpeg-codebot]

On the FFmpeg mailing list, "softworkz ." wrote (reply to this):

> -----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
> 
> Hi,
> 
> 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.

Thank you
sw
_______________________________________________
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".

[ffmpeg-codebot]

On the FFmpeg mailing list, Ramiro Polla wrote (reply to this):

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".

[ffmpeg-codebot]

On the FFmpeg mailing list, "softworkz ." wrote (reply to this):

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> Sent: Dienstag, 20. Mai 2025 22:29
> 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 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?

My local MSVC setup is using vcxproj projects, it's not makefile driven,
but I have the other ways as well. Though, I love to have it off the table
and running elsewhere. I made the V=1 change and also added a second 
make after make to check:

https://dev.azure.com/githubsync/ffmpeg/_build/results?buildId=89332&view=logs


BTW, it's public, just create a PR on https://github.com/ffstaging/FFmpeg
and you get 6 CI builds which are the same like on Patchwork.
(nobody needs to use that submission thing, just close the PR right after)


Best,
sw
_______________________________________________
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".

[softworkz]

/submit

[ffmpeg-codebot]

Submitted as pull.80.v3.ffstaging.FFmpeg.1747783977790.ffmpegagent@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-80/softworkz/submit_commonmak-v3

To fetch this version to local tag pr-ffstaging-80/softworkz/submit_commonmak-v3:

git fetch --no-tags https://github.com/ffstaging/FFmpeg tag pr-ffstaging-80/softworkz/submit_commonmak-v3

[softworkz]

/submit

[ffmpeg-codebot]

Submitted as pull.80.v4.ffstaging.FFmpeg.1748037922309.ffmpegagent@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-80/softworkz/submit_commonmak-v4

To fetch this version to local tag pr-ffstaging-80/softworkz/submit_commonmak-v4:

git fetch --no-tags https://github.com/ffstaging/FFmpeg tag pr-ffstaging-80/softworkz/submit_commonmak-v4

[softworkz]

/submit

[ffmpeg-codebot]

Submitted as pull.80.v5.ffstaging.FFmpeg.1748382088.ffmpegagent@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-80/softworkz/submit_commonmak-v5

To fetch this version to local tag pr-ffstaging-80/softworkz/submit_commonmak-v5:

git fetch --no-tags https://github.com/ffstaging/FFmpeg tag pr-ffstaging-80/softworkz/submit_commonmak-v5

[softworkz]

/submit

[ffmpeg-codebot]

Submitted as pull.80.v6.ffstaging.FFmpeg.1750176111.ffmpegagent@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-80/softworkz/submit_commonmak-v6

To fetch this version to local tag pr-ffstaging-80/softworkz/submit_commonmak-v6:

git fetch --no-tags https://github.com/ffstaging/FFmpeg tag pr-ffstaging-80/softworkz/submit_commonmak-v6

[ffmpeg-codebot]

On the FFmpeg mailing list, "softworkz ." wrote (reply to this):

> -----Original Message-----
> From: ffmpegagent <ffmpegagent@gmail.com>
> Sent: Tuesday, June 17, 2025 6:02 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: softworkz <softworkz@hotmail.com>
> Subject: [PATCH v6 0/2] ffbuild/commonmak: Fix rebuild check with implicit
> rule chains

[..]

> V4
> ==
> 
>  * Always keep .ptx files (as suggested by Timo - thanks) Tested all
>    scenarios:
>    * .ptx.c and .ptx.gz still get deleted (as intermediates)
>    * repeated make shows "up-to-date"
>    * removing a .ptx file does not cause a rebuild (it's still an
>      intermediate, but an "intermediate to keep")
>    * but changing a .ptx does (in case of dev/debugging)
>    * changed .cu files always rebuild of course
> 
> 
> V5
> ==
> 
>  * First patch remains unchanged
>  * Added second patch to clean up and consolidate the rules around
>    compression
> 
> 
> V6
> ==
> 
>  * Rebased
>  * Confirmed that it also resolves MSVC-CLang compilation
>    (as reported by Kasper Michalow - thanks!)

@Andreas - this slightly conflicts with your WIP patchset. Do you think it makes
sense to get this one merged first?

It would also need a review, I'm not going to push this without, even though I 
believe it's the most suitable and straightforward way to get all the issues 
fixed that it covers (up-to-date check wrt. double-make, log-spam, log prefixes,
common.mak sanity and MSVC-CLang build). 

Thanks,
sw


_______________________________________________
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".

[softworkz]

/help

[softworkz]

/help

[ffmpeg-codebot]

HttpError: Validation Failed: {"resource":"IssueComment","code":"unprocessable","field":"data","message":"Body cannot be blank"}

[softworkz]

/submit

[ffmpeg-codebot]

Submitted as pull.80.v7.ffstaging.FFmpeg.1750699628.ffmpegagent@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-80/softworkz/submit_commonmak-v7

To fetch this version to local tag pr-ffstaging-80/softworkz/submit_commonmak-v7:

git fetch --no-tags https://github.com/ffstaging/FFmpeg tag pr-ffstaging-80/softworkz/submit_commonmak-v7

[softworkz]

/submit

[ffmpeg-codebot]

Submitted as pull.80.v8.ffstaging.FFmpeg.1750719366.ffmpegagent@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-80/softworkz/submit_commonmak-v8

To fetch this version to local tag pr-ffstaging-80/softworkz/submit_commonmak-v8:

git fetch --no-tags https://github.com/ffstaging/FFmpeg tag pr-ffstaging-80/softworkz/submit_commonmak-v8

[ePirat]

Why remove those comments?

[softworkz]

Someone had asked on IRC whether I would submit AI generated code as those comments would look like I did.
(the only AI generated line of code I've ever submitted is the sed command in that file)

While I believe that comments are often useful, there aren't any other comments in common.mak, and there had been some disliking comments about those lines earlier, so I wanted to adapt to these attitudes.

One could also say that due to the command variables like $(RUN_GZIP), $(RUN_MINIFY)and $(RUN_BIN2C) it is now more clear what happens on each line.

PS: Thanks a lot for looking at this patchset :-)