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

[Ramiro Polla <ramiro.polla@gmail.com>]

On Tue, May 27, 2025 at 9:20 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, 27. Mai 2025 14:36
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@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@ffmpeg.org> wrote:
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Ramiro Polla
> > > > Sent: Dienstag, 27. Mai 2025 05:29
> > > > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@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@ffmpeg.org> wrote:
> > > > > > -----Original Message-----
> > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> > Of Ramiro
> > > > Polla
> > > > > > Sent: Dienstag, 27. Mai 2025 03:33
> > > > > > To: ffmpeg-devel@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.

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