On Thu, Jul 23, 2015 at 9:34 AM, Martin Storsjö <[email protected]> wrote: > On Thu, 23 Jul 2015, Steve Lhomme wrote: > >> On Thu, Jul 23, 2015 at 9:04 AM, Martin Storsjö <[email protected]> wrote: >>> >>> On Thu, 23 Jul 2015, Steve Lhomme wrote: >>> >>>> -- >>>> favor link over link.exe in case some wrapper script already exists >>>> fallback to "link" in the path if the one next to cl.exe is not found >>>> --- >>>> configure | 2 +- >>>> tools/mslink.sh | 9 +++++++++ >>>> 2 files changed, 10 insertions(+), 1 deletion(-) >>>> create mode 100644 tools/mslink.sh >>>> >>>> diff --git a/configure b/configure >>>> index 16bf852..a1901af 100755 >>>> --- a/configure >>>> +++ b/configure >>>> @@ -2633,7 +2633,7 @@ case "$toolchain" in >>>> else >>>> cc_default="c99wrap cl" >>>> fi >>>> - ld_default="link" >>>> + ld_default="$source_path/tools/mslink.sh" >>>> nm_default="dumpbin -symbols" >>>> ar_default="lib" >>>> target_os_default="win32" >>>> diff --git a/tools/mslink.sh b/tools/mslink.sh >>>> new file mode 100644 >>>> index 0000000..a34f05e >>>> --- /dev/null >>>> +++ b/tools/mslink.sh >>>> @@ -0,0 +1,9 @@ >>>> +#!/bin/sh >>>> + >>>> +LINK_EXE_PATH=$(dirname "`command -v cl.exe`")/link >>> >>> >>> >>> Why is this suddenly using "command" instead of "which" now? This won't >>> work >>> in a linux environment. And please check for "cl" instead of "cl.exe". >> >> >> I was told command -v is preferred to which. I looked around and it >> seems common practice. It may not work in C-shell. But I'm no expert. > > > Perhaps common practice in windows scripts, but not ok in a posix shell > script. > >> Anyway, seems the solution to use a script is rejected. We can't call >> a script in the source folder, because the source folder may have >> spaces. Just like MS link.exe... > > > I wouldn't call it "rejected", but we need to think further... >
Out-of-tree builds with spaces in their path aren't supported to begin with ... and if I do an in-tree build, is it guaranteed that $source_path is always simply "."? It seems to be for me right now.. so this might work afterall. - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
