From: Keith M. <kei...@us...> - 2012-02-23 21:06:44
|
Guys, I've posted a lua-5.2 enabled snapshot of mingw-get-0.5 on my personal SF project page, at https://sf.net/projects/keithmarshall.u/files, along with a modified copy of mingw32-mingw-get.xml, illustrating a possible method of creating start menu or desktop shortcuts during package installation. Please feel free to experiment with this, and to offer suggestions for enhancement. Here's a brief overview of how the scripting capability works: 1) Scripts are defined as the content of <action>script</action> elements; these may be inserted at any level within the XML document hierarchy, (but logically, are best confined to the scope of elements contained within a <package>...</package> definition. 2) Each such script *must* be assigned one of the class attributes: <action class="pre-install"> <action class="post-install"> <action class="pre-remove"> <action class="post-remove"> Note: specifying any other value for the class attribute will not cause an error, but the associated script will never be invoked. 3) Each script *may* be assigned one of the precedence attributes: <action class="..." precedence="normal"> <action class="..." precedence="immediate"> Note: if no precedence is assigned, "normal" is assumed. 4) For each action class, script processing is initiated at the appropriate point in the processing cycle for each <release/> entity processed. 5) Script processing, for each activation point, begins at the active <release/> element, recursively proceeding outwards until the root XML element is encountered, searching for <action> elements of the appropriate class within each XML container element visited; on this outward journey, scripts with "immediate" precedence are executed, as they are found. 6) Script processing continues on the return journey, as the recursion unwinds back to the initial <release/> element; each element visited is again searched for <action> elements, and those with "normal" precedence are executed. The example I've provided calls out to the Windows Scripting Host to create, (and destroy, on package removal), a start menu shortcut; it could just as easily create a desktop shortcut, and either type may be specific to current user, or assigned for all users. As I've written the example, the user has no control over shortcut creation; the script will always try to create one, regardless of any user preference. Perhaps that could be seen as antisocial; any ideas for giving the user some degree of control? Maybe: - Environment variable settings, classifying disposition for each of desktop and start menu shortcuts; - Command line switches, offering similar capabilities; - profile.xml settings; - some hierarchical combination of the three? If we do adopt any of these, or equivalent, how do we propagate the user's preference to lua scripts, (and beyond)? - Through the environment; - Through lua global variables, or the lua data registry? Thoughts? Bear in mind that my lua expertise is, for all intents and purposes, non-existent. If you suggest anything complicated, then please show me how to implement it, (or better yet, provide appropriate patches). -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2012-02-23 22:54:48
|
On 2/23/2012 9:40 AM, Keith Marshall wrote: > I've posted a lua-5.2 enabled snapshot of mingw-get-0.5 on my personal > SF project page, at https://sf.net/projects/keithmarshall.u/files, along > with a modified copy of mingw32-mingw-get.xml, illustrating a possible > method of creating start menu or desktop shortcuts during package > installation. Please feel free to experiment with this, and to offer > suggestions for enhancement. Will review in depth later, but...wow! yay! Good work! ... and thanks! ====== Now I just have to figure out how to re-activate the autoscripting features of mgwport, with this facility in mind...At first, I think all I'm going to attempt is to generate xml fragments, stored in the <workdir>/dist/ area with appropriate names, that the developer can then cut-n-paste into the "real" manifest xml maintained separately. (Otherwise, I have to teach mgwport how to both parse and edit xml -- which means a bash script needs an xml parsing library...ick; better to deploy a C/C++ tool that "knows" how to automatically insert those fragments into the "real" manifest, and then have mgwport call that tool to update the manifest using the fragments). 'Course, doing any of that /really/ means I need to merge in the relevant changes from Yaakov's cygport 0.10.6 and 0.10.7 releases... This is probably going to take a while -- but playing with mingw-get-0.5 and manually creating appropriate manifests that exploit the new capabilities need not (and should not) wait for any such mgwport updates. -- Chuck |