[Top][All Lists]

[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) > 
         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) > 
  cat link.tmp >> $(1:.dll=.map)
  cat link.tmp >> make.log
  rm -f $(2:.lib=.exp) link.tmp

I use $(strip ..) so I can call it with spaces:
  $(call do_link_DLL, wiretap.dll, wiretap_imp.lib, $^ $(EXTRA_LIBS))


reply via email to

[Prev in Thread] Current Thread [Next in Thread]