[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Macro question
From: |
Gisle Vanem |
Subject: |
Re: Macro question |
Date: |
Wed, 9 Dec 2015 20:41:33 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
David Boyce wrote:
> First, I think there’s some missing context as you seem to have an
> unusual environment. You’re mixing Unix (cat, rm) and Windows (link)
> invocations; is it Cygwin, GNUWin32, MKS, ???
Thanks for replying.
I'm on Windows 10 using CygWin32 tools together with MSVC tools. (no
problem even with CygWin's link.exe on my PATH; it's after MSVC's link.exe).
Since I had big tool-problems using MSys1 and Msys2 after upgrading to Win10,
I've so far settled on Cygwin32 for it's sh, binutils etc. (but that is probably
off-topic here).
> Second, I suspect the macro is a red herring and thus this is not
> really a “Macro question”. The macro should just expand to the same
> text you’d get by typing it out. What happens when the macro is
> replaced by the equivalent 3-line recipe?
The same result. I tried changing the command to:
.ONESHELL: wiretap.dll
SHELL = cmd.exe
wiretap.dll: $(WIRETAP_OBJ)
link $(LDFLAGS) -dll -out:wiretap.dll -implib:wiretap_imp.lib \
-pdb:wiretap.pdb -map:wiretap.map $^ $(EXTRA_LIBS) >
link.tmp
echo ERRORLEVEL: %?
cat link.tmp >> wiretap.map
rm -f wiretap_imp.exp
The ERRORLEVEL prints some 11xx code in case of error. So 'link' do pass
an exit-code as it should. But in this .ONESHELL case, I'm not sure gmake
should stop.
> Third, there should be nothing you have to do differently because this
> should work as desired. Since you’re not joining the 3 lines together
> with && and \, the result should be a 3-line recipe in which each line
> should abort the recipe on failure.
But it doesn't. I tried a "set GNUMAKEFLAGS=--debug=jobs". The output
wasn't much help.
> Two other little notes: (1) I don’t understand how you can be
> capturing error messages with > redirection, unless link.exe is dumb
> enough to send errors to stdout.
Many MS tools behaves that way. And that is correct IMHO when I've
specified 'link -verbose'. It's a PITA to capture stderr on cmd.
What would gmake have done if link had printed to 'stderr' instead?
I think this is unrelated and the result would have been the same.
> And (2) the second and third macro
> lines could be a little more robust by using $(basename $1) rather
> than assuming the extensions to be .dll and .lib.
I know. My macro was a bit simplified. The full version of it is:
define do_link_DLL
link $(LDFLAGS) -dll -subsystem:console,5.02 -out:$(strip $(1))
-implib:$(strip $(2)) \
-pdb:$(basename $(1)).pdb -map:$(basename $(1)).map $(3) >
link.tmp
cat link.tmp >> $(1:.dll=.map)
cat link.tmp >> make.log
rm -f $(2:.lib=.exp) link.tmp
endef
I use $(strip ..) so I can call it with spaces:
$(call do_link_DLL, wiretap.dll, wiretap_imp.lib, $^ $(EXTRA_LIBS))
--gv