Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^3: Defining an XS symbol in the Makefile.PL (largely solved)

by syphilis (Bishop)
on Aug 22, 2019 at 01:29 UTC ( #11104837=note: print w/replies, xml ) Need Help??


in reply to Re^2: Defining an XS symbol in the Makefile.PL (largely solved)
in thread Defining an XS symbol in the Makefile.PL

... % is also special in make's language it is used in forming patterns ...

Yes, I know that, and it may well be part of the problem.
However, when I run the script on my Ubuntu box (where GNU make is also used) I find that it needs only the single "%", same as dmake.
Can we therefore assume that the bug is in the Win32 version of "make" that I'm using ?

On windows, I've been using:
GNU Make 3.82.90 Built for i686-pc-mingw32 Copyright (C) 1988-2012 Free Software Foundation, Inc.
and it makes no difference when I switch to:
GNU Make 4.2.1 Built for x86_64-pc-msys Copyright (C) 1988-2016 Free Software Foundation, Inc.
So, if the problem lies with GNU make on Windows, it seems it's a thoroughly embedded problem.

I know that "%%" is the way to escape the "%" in (s)printf's formatting pattern.
According to https://www.cmcrossroads.com/article/gnu-make-escaping-walk-wild-side, in GNU make one escapes the "%" with a backslash - which was another approach I had tried, and found to be unsuccessful.
I'll investigate the possibility that somewhere in EU::MM there's a (s)printf call that's made when make=gmake, but not when make=dmake. (However, I think it unlikely that would happen.)

The problem of how to workaround the issue is, in my view, solved.
I'd just like to understand why and how that issue exists.

Cheers,
Rob

Replies are listed 'Best First'.
Re^4: Defining an XS symbol in the Makefile.PL (largely solved)
by jcb (Chaplain) on Aug 22, 2019 at 02:24 UTC

    Are the % characters appearing in the generated Makefile where they should be?

    When make prints the command it is issuing, is the % present as it should be?

    If it is in the Makefile and missing when make reports the command, file a bug on GNU make, but if GNU make prints the %, my guess is that the Windows shell is eating the single %, a situation that dmake silently works around by doubling % characters (or something else; if the Windows shell is responsible for this, your solution of writing %% may only work due to Yet Another Microsoft Bug).

    If you try installing bash and editing the generated Makefile to set SHELL = /path/to/bash.exe, do the strange problems go away? If so, it is almost a Windows-ism tripping you up here.

    GNU usually has consistent escaping and quoting rules. I doubt that GNU make is that different between "native" and "Windows" ports. Have you tried a Cygwin build of GNU make?

    Unless your module is intended to be Windows-only, I suggest that the most portable solution is to avoid passing format string constants on the command line.

      Are the % characters appearing in the generated Makefile where they should be?

      Yes - if I've specified one "%", then only one appears in the generated Makefile - irrespective of the flavour of make.
      If I've specified "%%", then "%%" appears in the generated Makefile - irrespective of the flavour of make.

      When make prints the command it is issuing, is the % present as it should be?

      Yes - according to what's appearing on the screen as the build is proceeding, the actual command that's being run is as expected for the particular value I've given to CCFLAGSEX, irrespective of the flavour of make.

      There were problems (with which I did not persevere) in getting that Inline::C script to run in my (MSYS2) bash shell using my Windows perl. The process hangs (due to issues with backslashes in paths, I think):
      $ perl try.pl validate Stage Starting Build Preprocess Stage get_maps Stage Finished Build Preprocess Stage Starting Build Parse Stage Finished Build Parse Stage Starting Build Glue 1 Stage Finished Build Glue 1 Stage Starting Build Glue 2 Stage Finished Build Glue 2 Stage Starting Build Glue 3 Stage Finished Build Glue 3 Stage Starting Build Compile Stage Starting "perl Makefile.PL" Stage Generating a gmake-style Makefile Writing Makefile for try_pl_d3118 Writing MYMETA.yml and MYMETA.json Finished "perl Makefile.PL" Stage Starting "make" Stage Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\_32\C\_Inline\build\try_pl_d3118> [Process hangs here]
      However, I've just found another Windows GNU make (provided by Strawberry Perl):
      GNU Make 4.2.1 Built for x86_64-w64-mingw32 Copyright (C) 1988-2016 Free Software Foundation, Inc.
      and using that particular build of make makes the issue go away !!!
      That's a good enough indicator for me that my problems arose because I was using a buggy version of GNU make.

      Thanks for the continuing assistance, guys.
      Further conversation/thoughts/observations are certainly welcome, but I'm now marking this as solved.

      Cheers,
      Rob

        Considering that your Inline::C test is hanging just after producing a cmd.exe startup banner and prompt, I would file this whole mess under the category of "Windows": evidently make is starting a shell to run a command but the shell is waiting for input (probably from NUL:) instead of running the intended command.

      jcb: windows cmd.exe doesn't eat % randomly

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11104837]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (7)
As of 2019-10-19 15:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?