search

Leont / extutils-hascompiler

Check for the presence of a compiler
5 stars 3 forks source link

How to deal with diagnostics? #2

Open Leont opened 9 years ago

Leont commented 9 years ago

Currently, nothing particularly smart is done. It's just printing the command to STDOUT (unless the quiet argument is set), running the command without any redirection (so any errors should be visible on the console) and warning on most errors.

Is this enough? Should something smarter be done?

Leont commented 9 years ago

One thing I'm considering: collecting the compiler output, and adding that to the warn on failure (but being silent on success). Disadvantage: I don't think I can make this work on VMS.

ribasushi commented 9 years ago

@Leont can you summarize the VMS problem?

Leont commented 9 years ago

can you summarize the VMS problem?

IPC::Open3 doesn't work on VMS, only backticks and system do.

Leont commented 9 years ago

Currently the code contains a lot of foo or do { carp "foo failed because $!"; return }, this feels rather smelly.

Making it croak would make more sense on the inside, but I'm not sure if would also make more sense on the outside

ribasushi commented 9 years ago

@leont what about a stupid generic "run" wrapper, which keeps writing the command and the output to somewhere in File::Spec->tmpdir, and nukes the file on success, or says on STDERR "look here", sort of like cpanm?

ribasushi commented 9 years ago

The thinking is that the log will be examined (or relayed to be examined) by someone who knows what they are looking at/for, so pretty-printing, nor limiting amount of data is not a concern.

Leont commented 9 years ago

what about a stupid generic "run" wrapper, which keeps writing the command and the output to somewhere in File::Spec->tmpdir, and nukes the file on success, or says on STDERR "look here", sort of like cpanm?

I don't expect that to be sensible given the low amounts of information. In most cases it will be a single line of information. Current possible warnings are:

  1. "Couldn't write to $source_name: $!"
  2. "Couldn't close $source_name: $!"
  3. "Couldn't append to '$abs_basename.opt'" (on VMS)
  4. "Couldn't execute $command: $!"
  5. "Couldn't load $loadable_object: " . DynaLoader::dl_error();
  6. "Couldn't find boot symbol for $basename"
  7. A freak error while running the boot symbol or the actual XSUB
  8. Can't locate auto/DynaLoader/dl_unload_f.al in @INC (on HP-UX on perl < 5.8, this is otherwise harmless).
  9. Anything use warnings might generate

Of these, only warning 4 is something that should happen on normal production systems.

In branch capture, warning 4 is replaced (except on VMS) by :

  1. Any error from IPC::Open3 (such as not being able to run the command)
  2. "Command $command returned $?: $output" (**potentially multi-line**)

Stuff I probably should also cover:

  1. Mksymlists errors
  2. perl not supporting dynamic linking