[FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Ramiro Polla
> Sent: Dienstag, 27. Mai 2025 05:29
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move
> fftools/resources-specific code its Makefile
> 
> On Tue, May 27, 2025 at 4:11 AM softworkz .
> <softworkz-at-hotmail.com at ffmpeg.org> wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Ramiro
> Polla
> > > Sent: Dienstag, 27. Mai 2025 03:33
> > > To: ffmpeg-devel at ffmpeg.org
> > > Subject: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move
> > > fftools/resources-specific code its Makefile
> > >
> > > - Intermediate files are no longer removed;
> >
> > Why? That's the way it's meant to work and it's working fine (will push
> tomorrow)
> 
> Deleting intermediate files prints an "rm" message at the end of the
> build. 

Yes, that's correct. That's how make behaves by default. I had set up
a minimal repro to verify.

It also deletes files that we might want to inspect later.

In 99.9% of cases - no.
For the remainder, there's a line in the Makefile to uncomment,
to make the files persists for debugging purposes.

Further, I'm afraid, I also do not agree with the moving around
of the make rules from common.mak. They are there for good reasons:


1. PTX compression is handled there. It makes a lot of sense to 
   bundle code of similar concern instead of spreading it all 
   over many files

2. It allows to have a uniform implementation for all the compression
   without any divergent code over different places

3. The rules in common.mak are intended to be re-usable. Same like
   ptx files could occur not only in avfilter but possibly also in 
   avcodec, the same is true for resources:
   It is very well possible that FFprobe might get similar resources
   for some graph visualization in a different folder.
   Also, the intention for the AVTextFormat API is that it can be
   used from the libs, e.g. formatted data output from a filter
   or visualized as a graph, in which case the filter would require 
   some css or also html resources. That's why the rules should
   remain in common.mak


> > > - A .res suffix has been added to resource files, so that there's no
> > >   need to add new rules for each new filetype;
> >
> > I don't want this. I want the editor to be aware of the file type when
> opening.
> 
> Fair enough. New patch attached.

Anyway, it wouldn't have made any sense, because .css files have a 
different build sequence than html files, which is why you were 
appending .res, but then had to still include the original extension 
for distinction (.css.res).

To be honest, I see no improvement in patches 4/5 and 5/5.
Haven't looked into the removed check.
Michael has some build where no zlib is available, so he'll probably 
let you know in case.

Just to clarify: 

- Static build
- No zlib available
- cli gzip is available

Will compression be used when compiling?

Thank you
sw