On May 17, 2012, at 2:47 PM, Mark Berryman wrote: > Can the code invoked by makefile.pl tell whether perl itself is being built > or if a perl extension is being built? If so, would it be possible to have > the "install" part of the perl build process add the following files with > their indicated contents to the directory PERL_ROOT:[LIB…CORE]? > > __DECC_INCLUDE_EPILOGUE.H > #pragma names restore > > __DECC_INCLUDE_PROLOGUE.H;1 > #pragma names save > #pragma names uppercase > #pragma names truncated > > This way, the makefile.pl for extensions can automatically add > /names=(as_is,shortened) to the CC command line when building extensions. > This is a requirement to build a number of extensions, not only because they > might use an external library with very long names but also because some > programmers out there still think it is clever to use different > routine/variable names that differ only in case. Those two files will cause > all files included in, or by, the […core]*.h files to be treated as if > /names=(uppercase,truncated) had been specified. The routine that converts > .xs to .c already handles truncating any names that are part of perl so the > shortened only takes effect for references to external libraries. > > Alternatively, one could build perl with /names=shortened, and change the > prologue file accordingly, and completely eliminate the process of manually > shortening names. > > Thoughts?
Starting with Perl 5.14.0, we use the compiler's name shortening by default: <http://perl5.git.perl.org/perl.git/commit/1171624bdbd2f8fae38ebe18d7a2616c4435098c?f=configure.com> and the compiler options you build Perl with should automatically be used for extension building. While it's a slight digression from extension building, I'll go ahead and mention that we solve the problem of predicting shortened symbol names for the linker options file used to create perlshr.exe by implementing the exact same algorithm the compiler uses to shorten symbols: <http://perl5.git.perl.org/perl.git/commitdiff/24ad4a07e88519ae8e63d0b67d519e62a935b577> So that leaves building extensions using /NAMES=AS_IS. If I understand your trick with the prologue, it makes symbols declared in Perl's own headers get upper cased (and thus compatible with the default configuration of the core) while leaving any other symbols to get what you've given them on the command line. That's clever, but sounds fragile to me in that various changes to MakeMaker or ExtUtils:CBuilder or the core build process could break it, plus it would have to be done differently based on different configuration options. ISTR that building Perl with -"Dusecasesensitive" ran into some problem with object libraries. I would rather take another crack at resolving that and have that be the supported way to get case sensitive symbols. ________________________________________ Craig A. Berry mailto:craigbe...@mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
