>>my plans are to remove *all* "use" statements from Tcl.pm.
>>
>>
>
>The use of Config in that situation is very important. Otherwise you risk not
>functioning correctly on OS X 10.3.
>
>
of course I am not against the functioning correctly :)
>
>
>>If all else fails, please write
>>
>>if ($^O eq 'whatever') {
>>require 'Config.pm';
>># ... or
>># eval "use Config;"
>>}
>>
>>
>
>If these are all functionally equivalent, then we can replace the 'use
>Config'.
>
>
please do so.
Otherwise all usages of Tcl.pm will read Config.pm, which is huge.
The only distionction between 'use Config' and 'require Config.pm' are
1. compile/run-time distinction and 2. call of 'import' function; but
all these are negotiable for given $^O
>
>
>>BTW there are too many startup logic dependant on many ENV
>>variables, etc.
>>
>>
>
>I don't see why these internal bits need to be cleaned up.
>
>
>
>>and Tcl.xs contain some code like:
>>
>> dl_path = SvPV_nolen(get_sv("Tcl::DL_PATH", TRUE));
>>
>>plus some registry searching in the "Software\\ActiveState\\ActiveTcl"
>>
>>plus some more...
>>
>>IMO there are too many... Especially registry setting, which
>>will prohibit PAR usage, for example...
>>
>>I propose removing all ENV vars and registry vars from XS,
>>move those to pure-perl, and Tcl.pm should pass found DLL
>>into XS via SV.
>>
>>
>
>OK, that would be the Tcl::DL_PATH that we already allow to be initialized at
>the pure-perl level. However, I disagree that what is in Tcl.xs should be
>moved out - it's impractical.
>
I guess you're right.
> The code paths in there are as follows:
>
>CASE 1: if defined(Tcl::DL_PATH), load it
>CASE 2: if APPLE, load as framework
>CASE 3: if !defined(Tcl::DL_PATH), load with dlopen (tcl8x.dll on path)
>CASE 4: if WIN32, try registry
>
>CASE 1 is the pure-perl path (and is what Tkx in ActivePerl will use).
>CASE 2 is may not possible in pure-perl, and is the needed fallback for Apple.
>CASE 3 is the general fallback - you'll need to leave this in regardless.
>CASE 4 is a Win32-specific fallback that allows for the most popular Tcl
>distribution to be found.
>
>
These are not all the cases (there are some STUB logic for example, and
some starkit)
But there are some more logic that I am very inclined to add:
- in the PAR case, tk.dll should be found differently, in order to get
needed resources
- in case Tcl+Tk are built into Tcl.dll, extra call needed, again, for
Tk resources to be found by Tk system
I hope this is doable via $ENV{PERL_TCL_DLL} or Tcl::DL_PATH variable(s)
But I'll provide more exact details on these separatedly.
>So as you see, the other pieces in Tcl.xs are all fallbacks to Tcl::DL_PATH
>not being specified. If you can move the Apple path to pure-perl, then you
>could reproduce that logic there, but CASE 3 would require reproducing the
>dlopen search logic, and CASE 4 needs to remain a final fallback after CASE 3.
>
>If you think you can move this to pure-perl, I'd welcome the patch, but all of
>the functionality needs to remain.
>
>
I do not intend to remove any of functionality.
Best regards,
Vadim.
