On Tue, May 27, 2025 at 10:13 PM softworkz . <softworkz-at-hotmail....@ffmpeg.org> wrote: > > -----Original Message----- > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > > Ramiro Polla > > Sent: Dienstag, 27. Mai 2025 21:59 > > To: FFmpeg development discussions and patches <ffmpeg- > > de...@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....@ffmpeg.org> wrote: > > > > -----Original Message----- > > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > > > > Ramiro Polla > > > > Sent: Dienstag, 27. Mai 2025 14:36 > > > > To: FFmpeg development discussions and patches <ffmpeg- > > > > de...@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....@ffmpeg.org> wrote: > > > > > > -----Original Message----- > > > > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf > > Of > > > > Ramiro Polla > > > > > > Sent: Dienstag, 27. Mai 2025 05:29 > > > > > > To: FFmpeg development discussions and patches <ffmpeg- > > > > de...@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....@ffmpeg.org> wrote: > > > > > > > > -----Original Message----- > > > > > > > > From: ffmpeg-devel <ffmpeg-devel-boun...@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. > > 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
