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

[Ramiro Polla]

On Tue, May 27, 2025 at 10:13 PM 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 21:59
> > 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 9:20 PM 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 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?
> >
> > I don't like make deleting files.
> >
> > > > > 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.
> >
> > Oh, I don't plan on moving the ptx file rules out of common.mak. Like
> > I said, there is one common suffix for many different files.
> >
> > It can be improved by deduplicating rules though.
> >
> > > > > 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.
> >
> > Ok, I'll move it back to common.mak. But as long as it's one rule per
> > action, and not multiple per file type.
> >
> > Please come up with a plan on how to add resource files from different
> > places in the codebase, and how to include them in the resource
> > manager. Because currently it's not very flexible.
>
> Sure I will, but first of all, we need to get the way of building
> intermediates settled. I'm considering the way you are proposing
> (keeping intermediates) as inferior and against the intended behavior
> of make. What's been there before, has only been a workaround to avoid
> rebuilds triggered by dependency generation.
> In turn, I do not agree to turn back to that ugly and more complicated
> workaround, now that the original problem (which led to that workaround)
> has been identified and solved.

I've split the patchset in two parts and sent a new revision for the
resource manager part.

I don't like intermediate files but I left it like that for now to try
and get this merged more quickly.

Ramiro