Re: [Module-build-general] "0" options in compilation lines?

[Ken W. <ke...@ma...>]

On Wednesday, February 26, 2003, at 07:52  PM, Randy W. Sims wrote:
>
> That wouldn't work as it's written. Just before the return there is a 
> call to write_*_script() which delete()s the elements in the hash that 
> it is able to write to the script file, so it needs to be grep{defined 
> && length} to avoid warnings about the no longer existing elements.

Well, if you delete($spec{foo}), then @{$spec{foo}} returns an empty 
list, not something with undef elements in it.


> I've attached a patch that fixes that and fixes a couple of 
> inconsistencies in the way I was access $self->{config} (i.e. in most 
> places I was accessing through the convenience variable $cf while in a 
> couple of spots I spelled it out $self->{config}).

Good, $cf is nicer there.  No possibility of misspelling 'congif' 
either. =)

> In regards to warning users about undefined entries, I think it is 
> valid for some options to be undefined, but I really don't know enough 
> about typical usage across the various platforms to test the validity 
> of options. I need to study modules like MakeMaker and others that use 
> the compiler to see what they do, as well as studing some Makefile.PLs 
> and the generated Makefiles to try to get a better grasp on how the 
> compiler and linker are generally used.

My sense is that the cmd-line flags would be better left out than given 
undef values.  It doesn't seem to make much sense to do system('gcc', 
'-foo', undef).

I'll apply your patch as-is, if for no other reason than the fact that 
you can test things out, and I can't, so I ought to trust you more on 
the code than myself. =)

  -Ken