#1058: auto::funcptr:  config step not needed if 'jitcapable' is never true
-----------------------+----------------------------------------------------
 Reporter:  jkeenan    |       Owner:  jkeenan    
     Type:  RFC        |      Status:  new        
 Priority:  normal     |   Milestone:             
Component:  configure  |     Version:  1.6.0      
 Severity:  medium     |    Keywords:  jit funcptr
     Lang:             |       Patch:             
 Platform:             |  
-----------------------+----------------------------------------------------
 Configuration step `auto::funcptr` is supposed to ''"[verify] that the
 compiler supports function pointer casts."'' It only does something
 meaningful if the value of `jitcapable` in the Parrot::Configure object is
 a true value.
 {{{
 sub runstep {
     my ( $self, $conf ) = @_;

     my $jitcapable = $conf->data->get('jitcapable');

     if ($jitcapable) {
         $conf->cc_gen('config/auto/funcptr/test_c.in');
         eval { $conf->cc_build(); };

         if ( $@ || $conf->cc_run() !~ /OK/ ) {
             _cast_void_pointers_msg();
             exit(-1);
         }
         $conf->cc_clean();
         $self->_set_positive_result($conf);
     }

     return 1;
 }
 }}}
 However, with the recent removal of JIT code, `jitcapable` is now hard-
 coded to `0` in auto::jit.  From ''config/auto/jit.pm'':
 {{{
     $conf->data->set(
 [snip]
         jitcapable     => 0,
         execcapable    => 0,
 }}}
 Hence, ''config/auto/funcptr.pm'' does not currently do anything
 meaningful.

 In principle, we ''could'' leave it in our configuration system for the
 time being, so that when JIT comes back to life, auto::funcptr is ready to
 do its thing.

 However, I dislike having code in the config system that does nothing.  I
 propose that we delete ''config/auto/funcptr.pm'', the related C probes
 and the related test file.

 Discussion?  Please speak up, as otherwise I will delete these files in 7
 days.  Note that I am not proposing to delete the `jitcapable` element in
 the Parrot::Configure object's data structure, as that would adversely
 impact code in ''config/gen/config_h/config_h.in'' and
 ''config/gen/config_pm/myconfig.in''.

 Thank you very much.

 kid51

-- 
Ticket URL: <https://trac.parrot.org/parrot/ticket/1058>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets

Reply via email to