On 2025-03-20 05:39 am, Ramiro Polla wrote:
On Tue, Mar 18, 2025 at 11:06 AM Gyan Doshi<g...@videolan.org> wrote:
ffmpeg | branch: master | Gyan Doshi<ffm...@gyani.pro> | Mon Mar 17 20:57:28
2025 +0530| [740d4009656abeb006e2d43001b59d875c1a7a6a] | committer: Gyan Doshi
ffbuild: use response files only if ar accepts them
Sorry to come in late to the discussion...
I'm not a big fan of response files, because they make troubleshooting
more annoying (I like copying the command that failed and running it
again on its own with all arguments). IMO this shouldn't be the
default, but only used on systems where this could be a problem (i.e.:
Windows). Also, only based on host systems, so not while
cross-compiling from Linux.
I don't think most users want to log a ~30K character command for debugging.
How about an option, choices : yes, no, auto(default)?
I was wondering why ld.exe/ar.exe fail with a long argument list, but
echo doesn't. After a bit of investigation, it seems that cygwin/msys2
pass arguments through STARTUPINFO::lpReserved2 and shared memory. But
only programs built for cygwin/msys2 can make use of that, otherwise
the parameters from CreateProcess() are used. So echo is a
cygwin/msys2 program, but ld.exe/ar.exe are not. If, by any chance,
you have a non-cygwin/msys2 echo.exe on your path, this will fail
again.
I think this permutation of tools is low-probability but I have a
workaround in mind, so I'll send that.
@@ -68,8 +72,12 @@ $(SUBDIR)$(SLIBNAME): $(SUBDIR)$(SLIBNAME_WITH_MAJOR)
$(SUBDIR)$(SLIBNAME_WITH_MAJOR): $(OBJS) $(SHLIBOBJS) $(SLIBOBJS)
$(SUBDIR)lib$(NAME).ver
$(SLIB_CREATE_DEF_CMD)
+ifeq ($(AR_OBJS),true)
$(Q)echo $$(filter %.o,$$^) > $$@.objs
$$(LD) $(SHFLAGS) $(LDFLAGS) $(LDSOFLAGS) $$(LD_O) @$$@.objs
$(FFEXTRALIBS)
+else
+ $$(LD) $(SHFLAGS) $(LDFLAGS) $(LDSOFLAGS) $$(LD_O) $$(filter %.o,$$^)
$(FFEXTRALIBS)
+endif
$(SLIB_EXTRA_CMD)
-$(RM) $$@.objs
Is there any reason why we don't ifeq the removal of the response file as well?
The command result won't abort the script so I avoided inserting more
guards.
Regards,
Gyan
_______________________________________________
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".
