# New Ticket Created by Andy Dougherty
# Please include the string: [perl #44379]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44379 >
The new attributes scanning ought to use its own test_c.in file, instead
of trying to piggy-back off existing test_c.in files. The scheme in place
has several problems:
1. It has no fallback. From attributes.pm, the following snippet:
if ( $cc =~ /gcc/ ) {
cc_gen('config/auto/gcc/test_c.in');
}
elsif ( $cc eq 'cl' ) {
cc_gen('config/auto/msvc/test_c.in');
}
does nothing for other compilers. Obviously, all the compiles fail,
since no test.c file is generated. I don't know, for example, if 'icc'
handles attributes, or if it might in the future.
2. The name of the compiler is not the best test of whether you are
using gcc. On Linux, for example, if you use Configure.pl --cc=cc, then
this test,
if ( $cc =~ /gcc/ ) {
fails, even though you are using gcc. A better test is to check
gccversion.
3. The attributes testing is now duplicated in two test files,
gcc/test_c.in and msvc/test_c.in.
4. It's now potentially more difficult to use gcc/test_c.in for its
intended use. For example, the Solaris hints file needs to know if
we're using gcc, and it used to try to compile the gcc/test_c.in
program. Now, it has to add in -Iinclude/ to pick up
<parrot/compilers.h> which does the #ifdef dance around all the
attributes. All this compilication just to see if we're using gcc.
A much better plan, in my humble opinion, is to revert most of these
changes and simply make a *new* test_c.in file,
config/auto/attributes/test_c.in. Each test file can then concentrate
on doing one test.
Thanks for listening,
--
Andy Dougherty [EMAIL PROTECTED]
