On 8/3/07, jerry gay <[EMAIL PROTECTED]> wrote:
> On 8/3/07, via RT Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > # 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,
> >
> you're right, on all points. i hacked that code in to get msvc
> working, and figured i'd clean up the damage later. sorry, i didn't
> think of testing icc before i committed--of course it'll break.
>
> i don't expect to have the tuits until monday, though. hopefully
> somebody will step in before then and clean up the mess andy and i
> made. otherwise, i'll get to it first when i'm available.
> ~jerry
>
i think i've fixed it up as of r20521. let me know if it still behaves
unexpectedly.
~jerry
