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 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. I also don't like
make loudly deleting files at the end of the build. I believe others
feel the same.

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

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

There were 7 rules in common.mak to build 2 files that were specific
to fftools/resources. The rules could stay in common.mak if we come up
with a way to have 1 common rule for each action.

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

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


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