Hi Marcel, That's interesting. So as far as I understand, unshift @INC seems to work in general but fails with the specific Bugzilla/lib folder?
Something which I think "unshift @INC" won't do is inclusion of platform-specific subfolders. E.g.: <bugzilla-root>/lib/x86_64-linux-thread-multi So can you try following: * dump @INC when things work fine (i.e. - when you have a hardcoded "use lib" or PERL5LIB environment var is set) - I suppose it will pick those additional x86_64-linux-thread-multi subdirs * Can you try with the "unshift @INC" approach - also adding the relevant additional platform-specific subfolders to @INC. Regards, Yavor On Thu, Mar 10, 2011 at 12:39, Marcel Loose <[email protected]> wrote: > Hi Yavor, > > On Thu, 2011-03-10 at 11:27 +0200, Yavor Nikolov wrote: > > Yep, I came up to almost same idea - keeping config data into separate > > shared module which is populated before Bugzilla. use lib would be > > able to access it then (it worked for me). > > > > "use lib" seems to be processed at compile time (no matter if you put > > it in BEGIN block or somewhere else. Best to keep it in BEGIN though). > > > > Marcel - I've been installing Bugzilla-specific modules in it's lib > > and I've never experienced this issue. > > Interesting that "unshift @INC" worked for me with perl 5.10.0 on > > debian. And also with perl 5.12.1 on opensuse 11.3. > > Well, it could be caused by differences between Bugzilla 3.2 and 3.4. I > *can* successfully start a scmbug-server when using Bugzilla 3.2, even > though that directory also contains a lib directory, which is included > in the traditional "unshift @INC ..." way. > > > Maybe it's not a bug that modifying @INC at runtime doesn't always > > work - I'm not sure. (Could be implementation-dependent stuff - i.e. > > unspecified behavior on which is not a good idea to rely on). > > > > Marcel, could you try another thing: > > In BEGIN block try to add the relevant libraries: > > BEGIN { > > unshift @INC, "/bugzilla/root/lib"; > > unshift @INC, "/bugzilla/root"; > > } > > > > Don't use variables or methods above for now - just hardcode the paths > > and see if it helps to get modules discovered or not. (You can try > > this with a simplified test-case too instead of Scmbug). > > Nope, that doesn't work either. > > > Here is another example where "unshift @INC" is mentioned. > > > > Regards, > > Yavor > > Cheers, > Marcel Loose. > > >
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
