On Wed, 22 Jul 2015, Steve Lhomme wrote:
On Wed, Jul 22, 2015 at 7:18 PM, Martin Storsjö <[email protected]> wrote:
On Wed, 22 Jul 2015, Steve Lhomme wrote:
use cygpath to determine the path of link.exe next to cl.exe, when
available
---
configure | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 16bf852..5154d6e 100755
--- a/configure
+++ b/configure
@@ -2633,7 +2633,11 @@ case "$toolchain" in
else
cc_default="c99wrap cl"
fi
- ld_default="link"
+ if test -x `which cygpath`; then
+ ld_default=`cygpath -d "\`which cl.exe | sed
"s/cl.exe/link.exe/g"\`"`
+ else
+ ld_default="link.exe"
+ fi
Please don't change the default/fallback case from "link" to "link.exe"
here. In a msvc/wine setup, it really does matter since I might have shell
script wrappers called "cl" and "link" but not "cl.exe" and "link.exe"; from
the build system point of view, I expect that the build system will try to
call "cl" and "link" and I (as the provider of the surrounding environment)
make sure that "cl" and "link" end up calling the right binaries.
Is there a reason it has to be called "link" on your side rather than
"link.exe" ? Your system with wine very likely already has a command
"link". And why not link.sh if you don't want to use "link.exe" ? In
the end that's the real name of the file that should be used.
Well, currently it defaults to calling "link" if you just configure with
--toolchain=msvc; that's why I've called the script "link" and not
"link.sh" or anything else (it saves having to add --ld=link.sh to the
configure line; it more or less perfectly tries to emulate a real windows
environment in that way). Similarly, other (makefile based) projects that
can build using msvc also call plain "link" and not "link.exe".
So so far, I've got at least 2 projects that want "link" and 0 that want
"link.exe".
If we change this, I (and others who use the same msvc/wine setups) would
have to update all the wrapper environments to add an alias link.exe that
map to link. Of course it's not impossible, but it's a (to me) needless
change.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
