On Thu, 20 Mar 2025, 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).
Fair enough, I can resonate with that argument.
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.
Yes, maybe. However there are a couple more cases that muddies the
distinction.
If building with Windows tools from within WSL (e.g. if building with MSVC
this way), then the host system, from within configure and make, looks
like a unix, while the build tools actually still have the same
limitation.
The same issue also potentially arises if you build with msvc-wine (MSVC,
wrapped in scripts with wine).
Not sure what the best distinction here would be? If the toolchain is MSVC
or if the host OS is windows?
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.
Yes, this does rely on that assumption. (I did bring this up in early
review and asked Gyan investigate to make sure this really is the case, so
we don't just gain the extra command line space of the linker options). I
don't see it as a very high risk right now though.
@@ -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?
I guess that could be done, but it makes the code a little bit more messy
with even more ifdefs, so I'm not sure if it's worth it?
// Martin
_______________________________________________
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".
