On Mon Mar 25 12:49:34 2013, LeonT wrote: > On Mon, Mar 25, 2013 at 4:45 PM, Petr Pisar <ppisar@redhat.com> wrote: > > The problem here is the same file gets installed into > /usr/{,local/}bin and > > into @INC. What's good for to have the same file twice in your > system? > > AFAIK the original place was in @INC. It was later added to > install{,vendor,site}bin. > > > And is xsubpp supposed to be "require"-d by other perl code? Then > there is no > > reason to install the file there. > > > >> AFAIK, there is no requirement that the paths named in @INC contain > >> *only* Perl library (.pm) files. > > > > Thus it's reasonable to put the file there? > > Hysterical raisins. > > MakeMaker depends on it being there. Even if we'd change how MakeMaker > works, there's still older versions to keep into account. I agree with > you it's not a logical location, but we just can't go around breaking > 20 years of MakeMaker out of stylistic reasons. > > >>a configuration file (typemap) as well as > >> a read-only version of xsubpp. > >> > > Again, what is it good for? > > Actually, I wouldn't know a better place for that than in @INC. > Granted, nowadays we'd use File::ShareDir or some such, but it boils > down to the same. > > > If I can be constructive, moving lib/ExtUtils/xsubpp to > scripts/xsubpp and > > removing 'EXE_FILES' => ['lib/ExtUtils/xsubpp'] from Makefile.PL > should fix > > this issue. > > Hindsight is 20/20. > > Leon > If Leon's argument is correct, then we are stuck with the status quo -- which makes this ticket closable? Any dissent? Thank you very much. Jim Keenan --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=117289Thread Previous | Thread Next