SorryAM, I missed your post while I was investigating and composing my reply to tobyink's.
Again, I'm still faced with the table that I simply don't understand.
I probably should just add an XS file (containing a meaningless and pointless XSub) to the Module::A distro, as that act alone would ensure that the module gets installed into INSTALLSITEARCH ;-)))
Cheers,
Rob | [reply]
[d/l] |
The non-arch-specific files (INST_LIB) will be installed to INSTALLSITELIB, but you want them in the arch-specific site directory (INSTALLSITEARCH). So I think the comments so far (plus those docs) suggest that you could parse out the value of INSTALLSITEARCH from perl -V:installsitearch, then override INSTALLSITELIB to that value: perhaps at make time with something like make install INSTALLSITELIB=`find_archlib`.
It is not clear however why you don't simply put each perl build in a separate hierarchy. That would give you the separation you want in a far cleaner and more obvious manner.
I think the assumption underlying the existing directory layout is that things can and will be tested in isolation: if Module::B passes its tests and gets installed on each of perl-X and perl-Y, then it should not matter which of them the pure-perl Module::A has been tested against. If it does matter, that suggests either that there are tests missing for Module::B, or that there is code in one module that should be in the other.
| [reply]
[d/l]
[select] |
It is not clear however why you don't simply put each perl build in a separate hierarchy
I used to do that, but the repeated duplication of hunks of perl didn't fit well with my frugal nature and my sense of orderliness.
Perl already offered the option to take this alternative approach, so I thought "why not".
I would have gone ahead with the change even if I had been aware of this issue - and I'm still happy that I did go ahead with it.
If it does matter, that suggests either that there are tests missing for Module::B, or that there is code in one module that should be in the other
It's quite possible for bugs to exist for just one architecture - maybe because a pre-requisite is at a different version, or because a need specific to one architecture has been overlooked.
I just want to do what I can to ensure that any such bugs affecting my module are caught.
Cheers,
Rob
| [reply] |
