Mailing List Archive: dprof oct31

dprof oct31

Oct 31, 1995, 10:16 PM

Post #1 of 4 (392 views)

hmm, well, I was just playing with Andreas's little toy and now I think
there's a DProf Oct31.95 version on CPAN. It is not a patchkit over
patch.1n, but a minor upgrade on the Oct7.95 version.

The Oct31.95 version has a PL'd dprofpp, though the shebang still isn't
correct for anybody but me, and (drumroll, please....) I've added Ilya's
patch to make the test driver find ./blib, for those of you who have ./blib's
laying around. You can all stop sending test.pl patches to me now, thank
you very much. It was a lottery, really, and I don't know how Ilya's patch
came out on top. It just did.

I have not tried to address the other apparent DB-related problem that Ilya
found, and the Todo list looks about the same as it did last time, if not
identical.

I'd appreciate comments and ideas on the PL'd dprofpp, how to get the
shebang correct anyway. Installation of dprofpp is an open question, if
DProf is going to be part of the distribution. Should dprofpp be moved to
the toplevel or should installperl be adjusted to go down into ext? Maybe
the toplevel should have an instbin/ directory and all the SH files should
unpack into it and MM should place things like dprofpp into it and then
installperl just installs whatever is in there. If you think you know the
answer to that, then what about getting DProf's test suite to run in this
build/installation scenario?

Dean

Re: dprof oct31 [ In reply to ]

doughera at lafcol

Nov 1, 1995, 9:01 AM

Post #2 of 4 (377 views)

Permalink

On Tue, 31 Oct 1995, Dean Roehrich wrote:

> I'd appreciate comments and ideas on the PL'd dprofpp, how to get the
> shebang correct anyway.

It should probably start with
$Config{'startperl'}
followed by the magic
exec ....
if $running_under_some_shell
sort of trick, where Configure figured out how to start perl on your
system.

Alas, Configure doesn't do that yet (because metaconfig's standard unit
only works if you've *already* installed perl) and I haven't gotten
around to making the appropriate test, and no one else has either.

> Installation of dprofpp is an open question, if
> DProf is going to be part of the distribution.

I put it in the distribution in patch.1n because Larry had it as a Sev. 1
bug entry.

Ideally, maybe installperl should let each extension install itself.
That idea's been kicked around a lot too, but no one has actually done
anything about it.

For 5.002, I think that installperl should just special case dprofpp
and handle it that way.

> answer to that, then what about getting DProf's test suite to run in this
> build/installation scenario?

Ideally, maybe installperl should let each extension test itself.
That idea's been kicked around a lot too, but no one has actually done
anything about it.

Does DProf's test suite take kindly to moving over to t/lib/whatever.t ?
That's what I did with socket.t.

Andy Dougherty doughera@lafcol.lafayette.edu

Re: dprof oct31 [ In reply to ]

k at anna

Nov 1, 1995, 10:24 AM

Post #3 of 4 (380 views)

Permalink

andy> Ideally, maybe installperl should let each extension install itself.
andy> That idea's been kicked around a lot too, but no one has actually done
andy> anything about it.

I will.

andy> Ideally, maybe installperl should let each extension test itself.
andy> That idea's been kicked around a lot too, but no one has actually done
andy> anything about it.

I will.

Yes, Tim's suggestion is that this may wait. Having MM 5 I think the
patch will be pretty small. And I won't whine, if I have to do it
twice.

andreas

Re: dprof oct31 [ In reply to ]

Tim.Bunce at ig

Nov 1, 1995, 10:46 AM

Post #4 of 4 (377 views)

Permalink

> From: Andy Dougherty <doughera@lafcol.lafayette.edu>
>
> Ideally, maybe installperl should let each extension install itself.
> That idea's been kicked around a lot too, but no one has actually done
> anything about it.

Andreas is straining at the leash but I suggested it was too big a change
to contemplate for 5.002. The knock-on effects could take quite awhile to
sort out. I do hope it's addresses as a priority for 5.003 though.

> For 5.002, I think that installperl should just special case dprofpp
> and handle it that way.

That would be fine.

> > answer to that, then what about getting DProf's test suite to run in this
> > build/installation scenario?
>
> Ideally, maybe installperl should let each extension test itself.
> That idea's been kicked around a lot too, but no one has actually done
> anything about it.
>
> Does DProf's test suite take kindly to moving over to t/lib/whatever.t ?
> That's what I did with socket.t.

I'd leave it for now since MakeMaker's impending dominance of extension
building, testing and installing will no doubt address all these issues.
I except to see all the extension specific t/lib/*.t's moved into ext/*/t
subdirectories where they belong once MakeMaker takes control :-)

Tim.