On Mon, 10 Aug 2009 17:21 -0500, "Phil Lawrence" <prlawre...@gmail.com> wrote: > Curtis, > > First, thanks for writing such a comprehensive answer. I appreciate > it very much, as it has facilitated my conversation with the msysgit > developers. > > On Fri, Aug 7, 2009 at 7:38 PM, Curtis > Jewell<lists.perl.wi...@csjewell.fastmail.us> wrote: > > On Fri, 07 Aug 2009 17:36 -0500, "Phil Lawrence" <prlawre...@gmail.com> > > wrote: > >> I'm interested in having Strawberry Perl as a dependency of MsysGit. > >> That project is recently having success compiling code (e.g. git-svn) > >> against MinGW Perl, whereas in the past they had to settle for the > >> slower msys Perl. In my mind, this opens up the possibility of using > >> SP as MsysGit's Perl. > >> > >> If I understand SP correctly, it is an MinGW Perl, i.e. it does not > >> rely on the "mini cygwin" POSIX stuff of msys. Correct? > > > > Correct. > > > >> If so, then perhaps this ticket could be reopened: > >> http://code.google.com/p/msysgit/issues/detail?id=218 > >> > >> My question springs from one of Dscho's requirements in that ticket: > >> > provid[e] patches to msysgit.git that add a compile recipe > >> > (at the moment, we can compile Perl from scratch, if we > >> > cannot do that with Strawberry Perl, I will not accept it), > >> > >> Does Perl-Dist-WiX allow for this possibility? Can one compile SP > >> from the command line and save the results for install via script? > > > > Not by itself. BUT - Perl-Dist-WiX and Perl-Dist-Strawberry are both > > subclassable, so it'd be easy enough to override the write() subroutine > > (and other subroutines, if you wish) to do what you want at the moment. > > I'd be willing to help with that. > > Oops. I think I found a snag. WiX is released under the CPL v1.0, > and that is listed as incompatible with the GPL at: > http://www.gnu.org/philosophy/license-list.html > > Even though Strawberry Perl seems to be concentrating on WiX, it > it/will it remain possible to use Perl::Dist::Inno? What about NSIS > (NullSoft scriptable install system)? > > I'm pretty sure the msysgit team is not interested in anything listed > as "incompatible" with the GPL.
I should clarify something: Windows Installer and WiX are two different things. WiX is only used as a builder on the author's system - If you do it right, you're not distributing any of its code. You're distributing an .msi created using it, so its license should not matter unless they're really, really, REALLY being GPL purists and wanting to use GPL-compatible TOOLS only. (To "do it right" as a strict purist, you could create the msi user interface "clean-room" on your own instead of using the UI examples they provide. It's supported, and directions are given for doing so, because they expect you to be able to extend the UI if that's required.) As long as you use your own UI, and do not use any of their extensions, (like the FirewallExtension, etc.) you aren't distributing any code of theirs. What actually executes on the user's system is the Windows Installer front end and service - and that's provided with any recent version of Windows as part of the operating system. .msi's are referred to as "Windows Installer databases" in the Microsoft documentation - and yes, they actually are relational databases that you can use a (limited) subset of SQL against. The database is instructions for the Windows Installer service to do the installation - you may want to download InstEd at www.instedit.com and load one up and you'll see what I mean. Windows Installer databases store the files (if requested, and you'll probably want to), directions on how to install them, what registry or environment entries to add, any special binary or script code required for "custom actions", what to show in each dialog, etcetera. There may be a few "custom actions" provided by the .msi author or the .msi creation program, but it's mostly database entries to direct the Windows Installer service. Does that clear things up? > > Or, you could provide your own Main.wxs.tt (with a small subclass) that > > makes Strawberry into a merge module instead of an installer of its own, > > and include the merge module in the Git for Windows msi. > > > > The trick is that you have to have Perl installed already in a different > > place in order to do the building. (That's what Perl::Dist::Bootstrap in > > the Strawberry distribution provides.) > > > > "command-line" = you make your own 10-line Perl script, and maybe a > > 4-10K perl module to do what overriding you need, and provide some > > accessory files, and then call that script that uses the module on the > > command line? It should work. > > > > One fun problem - I think you know about this - is that the location > > that Strawberry Perl is put in cannot contain spaces. It's a restriction > > of the C toolchain for the most part. > > > >> Basically, instead of shipping SP with MsysGit pre-compiled in it's > >> own MSI installer, it sounds like it would need to be compiled from > >> source when the Git for Windows MSI installer is generated. Then the > >> Git for Windows installer would take care of placing the pieces > >> correctly on the end user's system. > > > > Not neccessarily. One of the things I plan to do for the October 2009 or > > January 2010 releases of Strawberry (I've got a lot of stuff on my > > plate) is to make Strawberry generate a merge module, as well as create > > an MSI that uses it. > > > > You may wish to use this merge module once we get it done - or even > > assist in getting it done! > > From whet I've read, "merge modules" are WiX specific. This page was > interesting (if way over my head): > > http://kobyk.wordpress.com/2008/04/12/deploying-the-visual-c-libraries-with-an-nsis-installer/ No, they're Windows Installer specific. (What software is used to create the msysgit .msi in the first place? I thought NSIS created .exe's. [Looked at page - it IS an .exe - which isn't really recommended anymore, at least by Microsoft... You see the hoops that had to be jumped through for installing the newer Visual C++ stuff with NSIS on that page.]) WiX has its own .wixlib format that is specific to it and does the same type of thing that merge modules do, but we don't have to use those. > It seems to me the value of "Strawberry Perl" is entirely in the fact > that it attempts a first-class Perl distribution, complete with > functional cpan. I look forward to hearing whether that value could > be delivered via GPL compatible installers. > > Thanks for offering to help with any subclassing I might want to do, > and also for pointing out a spot where I could contribute back. :-) > > Phil Lawrence --Curtis -- Curtis Jewell swords...@csjewell.fastmail.us %DCL-E-MEM-BAD, bad memory -VMS-F-PDGERS, pudding between the ears [I use PC-Alpine, which deliberately does not display colors and pictures in HTML mail]
