develooper Front page | perl.perl5.porters | Postings from January 2008

Re: dtrace and Perl (again)

Thread Previous | Thread Next
From:
Andy Armstrong
Date:
January 7, 2008 15:22
Subject:
Re: dtrace and Perl (again)
Message ID:
4F797D16-1FAC-4485-B941-38AFD62422C7@hexten.net
On 7 Jan 2008, at 23:15, Nicholas Clark wrote:
>> I assume that all the above should be conditional on -Dusedtrace and
>> that Apple and Sun will set that option when they build their vendor
>> versions. Is that sensible?
>
> No! :-)
>
> Only in that if it's the same speed, I don't see why we don't  
> default to
> building it in on any platform where we can, and let the user have  
> to do
> -Uusedtrace if they don't want it.

I guess I'm worried about introducing fragility into the build. There  
seem to be a few different versions of dtrace floating around - some  
of which are broken. There's at least one extant Sun version that  
can't do the .d -> .h transformation for example.

My thinking is that if it's on by default then broken dtrace implies  
broken Perl.

>> Is there a precedent for finding an executable? Anything else I  
>> should
>> be thinking about?
>
> I can't spot anything in generic Configure that is searching for  
> executables.
> But I would assume that if it's in PATH, it's there. Else the user  
> needs to
> re-run with a better PATH set up.


That's the other thing that attracted me to an explicit switch. Isn't  
asking for dtrace support and having the build fail because it's not  
available better than hoping for dtrace support and having it omitted  
because we couldn't find the executable?

-- 
Andy Armstrong, Hexten





Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About