It worked for windows installing from source with strawberry perl. On Sat, Apr 28, 2012 at 3:31 PM, Maggie X <[email protected]> wrote:
> Thanks for helping test and build the windows package!! Instead of > scanning blib for PDL::Stats functions, I changed add_doc.pl to scan the > final installation location, ie something > like /usr/local/lib/perl/5.10.1/PDL/Stats. This works because add_doc.plis > called after the install process copies the modules to the final > location. I'll see try and see if this works on windows installing from > source. Question is, will this work for ppm on windows? > > Best, > Maggie > > > On Sat, Apr 28, 2012 at 2:55 PM, David Mertens > <[email protected]>wrote: > >> On Sat, Apr 28, 2012 at 3:49 AM, Sisyphus <[email protected]>wrote: >> >>> >>> ----- Original Message ----- From: "Maggie X" <[email protected]> >>> To: "chm" <[email protected]> >>> Cc: "perldl" <[email protected]> >>> Sent: Thursday, April 26, 2012 11:03 AM >>> Subject: Re: [Perldl] PDL-Stats new release >>> >>> >>> >>> I didn't have to call scantree.pl. I wrote a little script using >>>> functions >>>> documented in PDL::Doc. It loads the existing pdldoc.db, scans and adds >>>> PDL::Stats functions to it. >>>> >>> >>> For the Windows ppm packages, there's no blib to scan. Well .... there >>> *is* a blib, but it's in some temporary directory, and I don't know what >>> might be involved in locating it. >>> Instead, I'd rather that the updating of pdldoc.db was done *without* >>> attempting to scan the blib. >>> >>> So ... I'm thinking I'll just use a modified version of Maggie's >>> add_doc.pl, run as a post ppm install script. >>> >>> I think the following approach should work. (For some context, see >>> add_doc.pl in the PDL::Stats source.) >>> >>> $dir = <full path to top level PDL folder>; >>> $pdldoc->ensuredb(); >>> $pdldoc->scan("$dir/Stats.pm")**; >>> $pdldoc->scantree("$dir/Stats"**); >>> eval { $pdldoc->savedb(); }; >>> warn $@ if $@; >>> >>> That assumes that you can do a 'scan' followed by a 'scantree' without >>> anything getting clobbered. >>> Should I expect any problems with that ? >>> >>> I'll give this a trial run on one of my own perls .... what's the quick >>> and simple check to see that it has worked ok ? >>> >>> Cheers, >>> Rob >>> >>> ______________________________**_________________ >>> Perldl mailing list >>> [email protected] >>> http://mailman.jach.hawaii.**edu/mailman/listinfo/perldl<http://mailman.jach.hawaii.edu/mailman/listinfo/perldl> >>> >> >> "what's the quick and simple check to see that it has worked ok ?" >> >> I believe (but have not studied the PDL build process closely to "know") >> that PDL's normal make install process scans all files in PDL >> subdirectories of @INC and looks for docs in them. I say this because some >> of my files that are not included in the PDL distribution, but which follow >> the PDL documentation guidelines, are usually indexed by the PDL docs >> database. So a good test would be to do the following: >> >> 1) Explicitly remove PDL::Stats from any @INC directories. >> 2) make install PDL >> 3) Check that PDL::Stats functions are not in the docs database using >> pdldoc or similar >> 4) build, ect, PDL::Stats >> 5) Check that PDL::Stats functions *are* in the docs database >> >> I'm pretty sure that should work and would indicate that Maggie's docs >> installation code works. >> >> David >> >> -- >> "Debugging is twice as hard as writing the code in the first place. >> Therefore, if you write the code as cleverly as possible, you are, >> by definition, not smart enough to debug it." -- Brian Kernighan >> >> >
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
