Bug #50960 for Math-GSL: ./Build test fails

>       Queue: Math-Gsl >  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=50960 > > > When trying to run 'make' for Math::GSL 0.20 I also run into this > problem: several basic header files for perl were not found by the > preprocessor.  After some time with the Perl debugger I managed to track > down the root cause for this very bizarre error message: > > At line 207 in the file Math-GSL-0.20/Build.PL, change > >    include_dirs            => q{}, > > into > >    include_dirs            => [], > > > The intent with both lines (the faulty as well as the corrected version) > is to tell Build.PL that "there are no additional include dirs". > Unfortunately will the incorrect line be interpreted by the build > infrastructure as "Please add to the list of include directories a path > consisting of the empy string".  The build infrastructure happily obeys > this request and causes a single '-I' to be added to the gcc calls used > to compile various C code.  The bad thing with that single '-I' is that > gcc does not interpret as "please add a path consisting of the empty > string to the list of include directories", instead it is interpreted as > "please add the NEXT command line, in it's ENTIRETY, to the list of > directories to search for include files".  The reason for THAT to be a > bad thing is that the next command line does not end up be anything that > starts with something like "/usr/lib/perl...", but instead it starts > with "-I/usr/lib/perl..." and THAT is not a valid directory at all. > Yes, what happens is that gcc, by that single '-I' flags being added to > the beginning of all command line arguments, gets confused and fails to > recognize the following '-I' flag which is used to add the directory > with the core perl header files to the path of directories to searh for > header files.  Thus the nasty surprise with a build that fails to find > the very basic, fundamental perl header files. > > Sorry for the long description above, but I thought that once I managed > to track down that chain of events, I better document it.  Actually, it > seems like a similar spurious lone '-I' has confused builds of other > perl modules at some occasions. > > How to solve this?  Well, the straighforward "keep it simple stupid" > approach is to do like I suggest above and just correct the > 'include_dirs' parameter to specify an empty list instead of an empty > string. > > A more bullet proof way to do it is to change the build infrastructure > somehow to make it actually fail and complain with a very clear and > informative error message whenever the empty string is specified as the > value for 'include_dirs'.  This will help developers/maintainers to > avoid that pitfall and instead specify the properly working empty list > as the "no additional include directories" value. > > A less ideal way to solve it is to make the build infrastructure > silently replace any empty string specified for 'include_dirs' with an > empty list.  However, I'm a believer in enforcing a certain level of > strictness and correctness, and would prefer to not forgive an imprecise > and easily misunderstood value being specified as the 'include_dirs' > (but that's just my personal preference). > > Of course, I don't know how easily it is to add the above two suggested > fixes (the explicit, informative error message as well as the "behind > the scenes" correction of the problematic value) to the build > infrastructure.  Perhaps it is just a change in some code already in > this package (then it is easy) but it might also require change in some > change in Module::Build etc. > > Ok, enough said.  I hope this reply is considered helpful. > >