Skip to content

Conversation

@softworkz
Copy link
Collaborator

@softworkz softworkz commented May 18, 2025

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
Copy link
Collaborator Author

/submit

@ffmpeg-codebot
Copy link

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 softworkz force-pushed the submit_commonmak branch 2 times, most recently from 2d7cf38 to f468ea2 Compare May 18, 2025 05:54
@softworkz
Copy link
Collaborator Author

/submit

@ffmpeg-codebot
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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

@ffmpeg-codebot

This comment was marked as outdated.

@softworkz
Copy link
Collaborator Author

/submit

@ffmpeg-codebot
Copy link

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
Copy link
Collaborator Author

/submit

@ffmpeg-codebot
Copy link

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
Copy link
Collaborator Author

/submit

@ffmpeg-codebot
Copy link

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 softworkz force-pushed the submit_commonmak branch 2 times, most recently from e0edc6e to 1781c5f Compare June 17, 2025 14:23
@softworkz
Copy link
Collaborator Author

/submit

@ffmpeg-codebot
Copy link

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
Copy link

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

Signed-off-by: softworkz <softworkz@hotmail.com>
This commit simplifies and consolidates all the rules around
ptx and resource file compression.

Signed-off-by: softworkz <softworkz@hotmail.com>
@softworkz
Copy link
Collaborator Author

/help

1 similar comment
@softworkz
Copy link
Collaborator Author

/help

@ffmpeg-codebot
Copy link

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

@softworkz
Copy link
Collaborator Author

/submit

@ffmpeg-codebot
Copy link

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

Signed-off-by: softworkz <softworkz@hotmail.com>
@softworkz
Copy link
Collaborator Author

/submit

@ffmpeg-codebot
Copy link

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

$(RUN_BIN2C)
endif

# 1) Preprocess CSS to a minified version
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why remove those comments?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants