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

Thanks
sw