[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 14:36
> 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 6:02 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 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.
> 
> Being make's default behaviour doesn't mean that's how we want it to
> behave. I don't like make silently deleting files. 

It doesn't do it silently.


> I also don't like
> make loudly deleting files at the end of the build. I believe others
> feel the same.

Since when do we make decisions based on whether we like the log
output or not?
And how does it go together when you say you don't want it to happen
silently and you also say that you don't like when make informs you
about it?


> > 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.
> 
> Very few people will know that line exists at all.

For those few who need to know it, their first action will be
to look at the Makefile, where it's right at the top.


> > 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
> 
> I left ptx out of this patchset, but it could be improved as well.
> Also, ptx has one common suffix for many different files. Resources
> could be anything.

Please discuss this with Timo, whether he would agree to moving
those pattern rules to the avfilter Makefile.
It doesn't make sense to do it differently for ptx and resource.


> > 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
> 
> Resources are currently centralized in fftools/resources. New
> resources would also need to be added to resman.c and resman.h.
> 
> How do you plan on adding new resources to different parts of FFmpeg,
> like ffprobe or avfilter? How will files be laid out in the directory
> structure, and how will they be included in the resource manager?
> Having a clear plan will help us moving forward.

I have more resources in my work branch which are for use by FFprobe
(so we're not talking about hypothetical cases here). There, all
resources go into both tools - which would probably be objected.

The answer is that there's no clear plan yet. Keeping the rules
in common.mak provides the flexibility that might be required, when
going forward.



> > > > > - 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.
> 
> Patch 5/5 removes files left over in fftools/{graph,textformat} when
> "make clean" is called. This should be pretty uncontroversial.
> 
> > 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?
> 
> No.

Okay, I have no objections to that change then, but I also do not
understand what the benefit would be in removing the check.

Thanks
sw