in reply to Defining an XS symbol in the Makefile.PL

Hi,
As regards my problems in getting the CCFLAGSEX setting right in this script (from my initial post): 
use strict;
use warnings;
use Config;

use Inline C => Config =>
  USING => 'ParseRegExp',
  CCFLAGSEX => '-DMY_FORMAT=\\"%.16e\\"',
  BUILD_NOISY => 1,
;

use Inline C =><<'EOC';

SV * foo(void) {
  printf(MY_FORMAT, sqrt(2.0));
  printf("\n");
}

EOC

foo();

[download]
I've found that it has nothing to do with the versions of Inline::C or ExtUtils::MakeMaker or perl itself.
It's the flavour of make that's critical.

If $Config{make} is gmake then the "%" needs to be replaced with "%%". But if $Config{make} is dmake then it has to be the single "%".
Essentially, whatever works with dmake will also work with gmake so long as that replacement is made.
For example, either of these will work with dmake (but not with gmake): 
CCFLAGSEX => '-DMY_FORMAT=\\"%.16e\\"',
CCFLAGSEX => "-DMY_FORMAT=\\\"%.16e\\\"",
CCFLAGSEX => q["-DMY_FORMAT=\\"%.16e\\""],

[download]
and either of these will work with gmake (but not with dmake): 
CCFLAGSEX => '-DMY_FORMAT=\\"%%.16e\\"',
CCFLAGSEX => "-DMY_FORMAT=\\\"%%.16e\\\"",
CCFLAGSEX => q["-DMY_FORMAT=\\"%%.16e\\""],

[download]
The situation with gmake looks very much like a bug to me.
If it is a bug, I'm guessing it's in perl (probably EU::MM), though it could also be a bug in gmake itself.
That's all I know at the moment.

Cheers,
Rob

Replies are listed 'Best First'.
Re^2: Defining an XS symbol in the Makefile.PL (largely solved)
by jcb (Parson) on Aug 21, 2019 at 23:05 UTC

    Oh, that is another issue: % is also special in make's language — it is used in forming patterns, where GNU make has excellent support and I do not know about dmake. I would strongly recommend passing a number (as I offered in Re^4: Defining an XS symbol in the Makefile.PL and Re^8: Defining an XS symbol in the Makefile.PL; you can combine the techniques and use the "odd" probe code with the "later" XS code to build the format from LU_NV_PREC) instead of trying to get a complete format string from Makefile.PL to XS code through a command-line option.

[reply]
[d/l]
[select]
      ... % 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.

      [download]
      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.

      [download]
      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
[reply]
[d/l]
[select]

        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.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom