> -----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-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....@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. 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. 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 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 > > > - 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. 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? Thank you sw _______________________________________________ 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".
