From bubnikv@gmail.com

Hello.

I am trying to set up a development perl environment compiled from scratch
with Visual Studio 2013 free C/C++ compiler. I stumbled over a following
problem​:

If the XS file contains an INCLUDE_COMMAND call, this line is later stored
as a comment into the generated XS.c file in a form of #line NUMBER
"filepath". Here the "filepath" will be the complete parameter of
INCLUDE_COMMAND. If the parameter contains escaped quotes, this breaks the
__FILE__ substitution in the visual studio C++ compiler.

Here is an example of a #line inserted into XS.c, which the Visual Studio
C++ has a problem with​:

#line 112 "c​:\\\\wperl64d\\\\bin\\\\perl.exe -MExtUtils​::XSpp​::Cmd -e xspp
-- -t \"D​:/src-perl/Slic3r/xs/xsp/typemap.xspt\"
\"D​:/src-perl/Slic3r/xs/xsp/Print.xsp\""

If I remove the quotes from the INCLUDE_COMMAND call, the resulting form is
swallowed by the Visual Studio compiler without any problem.

#line 112 "c​:\\\\wperl64d\\\\bin\\\\perl.exe -MExtUtils​::XSpp​::Cmd -e xspp
-- -t D​:/src-perl/Slic3r/xs/xsp/typemap.xspt
D​:/src-perl/Slic3r/xs/xsp/Print.xsp"

I see the following ways to fix this problem​:

1) The XS generator would remove the inner quotes from the #line comments
when targeting the Visual Studio compiler

2) The XS generator would save the intermediate file generated by the
script in INCLUDE_COMMAND, and reference it in XS.c

Thanks for consideration,
Vojtech

From @cpansprout

On Sun Aug 21 09​:48​:30 2016, bubnikv@​gmail.com wrote​:

Hello.

I am trying to set up a development perl environment compiled from scratch
with Visual Studio 2013 free C/C++ compiler. I stumbled over a following
problem​:

If the XS file contains an INCLUDE_COMMAND call, this line is later stored
as a comment into the generated XS.c file in a form of #line NUMBER
"filepath". Here the "filepath" will be the complete parameter of
INCLUDE_COMMAND. If the parameter contains escaped quotes, this breaks the
__FILE__ substitution in the visual studio C++ compiler.

Here is an example of a #line inserted into XS.c, which the Visual Studio
C++ has a problem with​:

#line 112 "c​:\\\\wperl64d\\\\bin\\\\perl.exe -MExtUtils​::XSpp​::Cmd -e xspp
-- -t \"D​:/src-perl/Slic3r/xs/xsp/typemap.xspt\"
\"D​:/src-perl/Slic3r/xs/xsp/Print.xsp\""

If I remove the quotes from the INCLUDE_COMMAND call, the resulting form is
swallowed by the Visual Studio compiler without any problem.

How exactly does it fail? What error message does it produce?

--

Father Chrysostomos

The RT System itself - Status changed from 'new' to 'open'

From bubnikv@gmail.com

How exactly does it fail? What error message does it produce?

What fails is the substitution of the __FUNCTION__ macro, which is
Microsoft's non-standard variant of the __func__ macro defined by the C99
standard I believe. Visual Studio will fail to compile various asserts,
which unfold the __FUNCTION__ macro. I think what happens is the Visual
Studio compiler somehow incorrectly interprets the quoting. The error
message given by the compiler is confusing at least and it was quite hard
to pinpoint it to the quotes in the #line.

On Sun, Aug 21, 2016 at 7​:35 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Sun Aug 21 09​:48​:30 2016, bubnikv@​gmail.com wrote​:

Hello.

I am trying to set up a development perl environment compiled from
scratch
with Visual Studio 2013 free C/C++ compiler. I stumbled over a following
problem​:

If the XS file contains an INCLUDE_COMMAND call, this line is later
stored
as a comment into the generated XS.c file in a form of #line NUMBER
"filepath". Here the "filepath" will be the complete parameter of
INCLUDE_COMMAND. If the parameter contains escaped quotes, this breaks
the
__FILE__ substitution in the visual studio C++ compiler.

Here is an example of a #line inserted into XS.c, which the Visual Studio
C++ has a problem with​:

#line 112 "c​:\\\\wperl64d\\\\bin\\\\perl.exe -MExtUtils​::XSpp​::Cmd -e
xspp
-- -t \"D​:/src-perl/Slic3r/xs/xsp/typemap.xspt\"
\"D​:/src-perl/Slic3r/xs/xsp/Print.xsp\""

If I remove the quotes from the INCLUDE_COMMAND call, the resulting form
is
swallowed by the Visual Studio compiler without any problem.

How exactly does it fail? What error message does it produce?

--

Father Chrysostomos