Item9974: setlib.cfg loaded twice but LocalLib.cfg only once

Priority:	CurrentState:	AppliesTo:	Component:	WaitingFor:
Normal	Closed	Engine	Configure

I just created a fresh foswiki 1.1.1 setup in order to migrate my old 1.0 content to it. I'm using a non-standard directory layout with the bin directory outside the tree. According to the install guide this should be supported. However, configure greeted me with an empty page.

The reason took some time to uncover. It seems that =TemplateParser.pm= is to blame. There you have the following code:

    # This is probably slow, but we need to know where the templates are
    our $foswikiLibPath;
    unless ( defined $foswikiLibPath ) {
        delete $INC{'setlib.cfg'};
        eval { require 'setlib.cfg'; };
    }
    $foswikiConfigureFilesDir = "$foswikiLibPath/Foswiki/Configure";

setlib.cfg was loaded by the cgi script configure. It in turn loaded LocalLib.cfg which then set foswikiLibPath. Now this code above requires setlib.cfg again. It forces reloading by deleting some hash item first. setlib.cfg doesn't do the same for LocalLib.cfg. Therefore LocalLib.cfg doesn't get loaded again, therefore setlib.cfg falls back to ../lib for the library path, which is wrong in my case.

All of this second loading stuff seems like an attempt to deal with scoping. The original initial loading of the mentioned files happened outside the scope of any explicit package, and therefore in the scope of the main package. Later on, the variable is referenced inside a package and therefore scoped to it. I guess the best approach would be dropping that double-loading stuff and using $main::foswikiLibPath instead.

One method would be this:

    # This is probably slow, but we need to know where the templates are
    our $foswikiLibPath;
    if ( !defined $foswikiLibPath && defined $main::foswikiLibPath ) {
        $foswikiLibPath = $main::foswikiLibPath
    }
    $foswikiConfigureFilesDir = "$foswikiLibPath/Foswiki/Configure";

Another would be something form of global import of that variable, but I'm not sure about the appropriate syntax just now.

-- MartinVonGagern - 08 Nov 2010