On 21 March 2017 at 19:00, Doug Bell <madcity...@gmail.com> wrote: > I tried testing this using `cpanm --interactive`: I created a Makefile.PL > with only "die 'OS unsupported'". When I run `cpanm --interactive .`, it > dies, and does not seem to allow me to edit anything or run anything to > prevent it from dying. `cpanm --look` would let you see the thing before you > install it, but you're altering the dist at that point.
Sorry, might have gotten confused. `cpanm --prompt` might be what I was using. $ cpanm --reinstall --prompt Clipboard --> Working on Clipboard Fetching http://www.cpan.org/authors/id/K/KI/KING/Clipboard-0.13.tar.gz ... OK Configuring Clipboard-0.13 ... Configuring Clipboard failed. You can s)kip, r)etry, e)xamine build log, or l)ook ? [s] l Entering /home/kent/.cpanm/work/1490078449.5607/Clipboard-0.13 with /bin/bash kent@katipo2 ~/.cpanm/work/1490078449.5607/Clipboard-0.13 $ vim Makefile.PL kent@katipo2 ~/.cpanm/work/1490078449.5607/Clipboard-0.13 $ exit Configuring Clipboard failed. You can s)kip, r)etry, e)xamine build log, or l)ook ? [s] r OK Building and testing Clipboard-0.13 ... FAIL Testing Clipboard-0.13 failed. You can s)kip, r)etry, f)orce install, e)xamine build log, or l)ook ? [s] f Successfully reinstalled Clipboard-0.13 1 distribution installed And here's the build.log cpanm-reporter sees: https://gist.github.com/kentfredric/98a238854a1fd3b513c3e4875fb98f4f > cpanm-reporter can't know you altered the dist, so I would really suggest not > sending in reports for dists you've altered, as they could be more confusing > than insightful: You sent in two reports from a Perl without "." in @INC, but > one failed because of it, and one succeeded in spite of it. Does the second > report indicate that "." got added to @INC somehow? Its not exactly a conscious choice, but a side effect. Granted 2 reports would be clearer, ... just several orders of magnitude harder to run. > As I understand cpanm-reporter, you sent in 2 test reports: one configure > failed (missing "." in @INC), one passed. I can't think of any way for the > configure step to fail and yet the installing client will still try to > continue. Here, I guess its a problem that the tool assessing the log can't tell,or can't decide, because the markers of both a fail and a success happen in the same log file. I can really say more atm because my head is killing me :/ -- Kent KENTNL - https://metacpan.org/author/KENTNL
