Subject: | Configuration of INC is lost if TYPEMAP data is generated |
If configuration parameter INC is set and Inline::CPP generates TYPEMAP data then INC is set back to its default value (i.e. any additional directories that had been added are lost).
The attached script demonstrates the problem, crudely. It doesn't actually need the extra include directory but if you check the generated Makefile, the extra include directory is not there.
If the CRectangle class is removed from this sample then the extra include directory does appear in Makefile because TYPEMAP data is not produced and, therefore, not validated.
The setting of INC is overwritten in Inline::C::validate, unless $o->UNTAINT is set, which it isn't in this example.
I don't know what is going on well enough to suggest a solution, but note that this was reported as a bug in Inline::C (#11748), which I have also updated. I don't see this as a problem in Inline::C itself because Inline::C doesn't generate and validate TYPEMAP data - this is something specific to Inline::CPP.
Subject: | test3.pl |
#!C:/strawberry/perl/bin/perl.exe
#
use strict;
use warnings;
use Inline ('CPP' => 'DATA',
'INC' => '-IC:/',
);
print "9 + 16 = ", add(9, 16), "\n";
__END__
__CPP__
// change 8
int add(int x, int y) {
return x + y;
}
// Adding the following class causes Inline:CPP to generate
// typemap data which is validated. The validation of the
// typemap data causes the configuration of INC to be lost
// In this case, Inline::C::validate, which is called from
// Inline::CPP::validate, sets $o->{ILSM}{MAKEFILE}{INC}
// unless $o->UNTAINT is set.
class CRectangle {
int x, y;
public:
void set_values(int, int);
int area() { return(x*y); }
};
void CRectangle::set_values(int a, int b) {
x = a;
y = b;
}