Re[2]: [tcltk-perl] Tcl::Tk and Tcl/Tk files within Perl installation

[Vadim K. <va...@vk...>]

>> It was easy to arrange so that Tcl/Tk gets all scripts from zipped
>> archive "tcltk.zip"
>>
>> So I ended with about 3 or 4 files for entire Perl + Tk. Adding Tix
>> makes only one file more (tix8184.dll) and tcltk.zip becomes a bit
>> larger. All pure-Tcl extension go to that "tcltk.zip"

JD> All of the above sounds pretty cool.  This will make it a lot easier
JD> for people to use Tcl::Tk without having to install a whole Tcl
JD> installation.

Yes, I also think so.

So I plan to reach a final goal in my spare time within few weeks.


>> I did it further: after few touches in Perl's makefile it is possible
>> to embed extension into perl.dll (it was possible earlier, and I
>> mostly restored and extended such a possibility)
>>
>> So I have 2Mbyte perl58.dll that contains Perl itself, Tcl/Tk, and
>> some Perl extensions (Compress::Zlib for example).

JD> I don't understand the value of this later part.  Why would you want to
JD> do this?  The big advantage of DynaLoader is that you no longer need
JD> to statically link extensions into core Perl (except for DynaLoader
JD> itself, of course).  Am I missing something?

Indeed, mostly modules should be loaded dynamically.
And I will mostly use Tcl::Tk using DynaLoader. 99.5% of the time

There are reasons I did this step:
 - to prove the concept it is able to work, and flexible enough to
   allow different configurations.
 - I was fixing Perl's makefile-s and dynaloader in respect to
   statically building of extensions and decided to do some testing.
 - I was requested to implement some GUI application, and it will
   always start with GUI. So there exist some sence to reduce startup
   time.
   At least it is reasonable to include Compress::Zlib into perl58.dll
   within my distro, because otherwise it always will start from
   loading Zlib.dll, and I will save in startup time a bit.
   
   Still, I am not sure whether my final distribution will have Tcl
   statically built into Perl, because having it separatedly increases
   flexibility in that sence that I can upgrade Tcl/Tk without
   rebuilding Perl each time.

But I do agree that normally Tcl::Tk should be dynamically loaded when
needed, so my extending of Perl's DLL is rather playing.

Best regards,
Vadim.