On Sep 7, 7:05 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> I sympathize with the goal of making it easier to change the installer > script. I don't usually like to do that by creating three external files > that must be kept in synch :-) It's already bad enough that we must > remember to bzr ls -R >bzr-manifest.txt before running the install script. > > Could you live with the following scheme? Place all boilerplate in > nsi-installer-boilerplate.txt. The nsi generation script (in @button make > leo.nsi) will copy that file verbatim near the start of leo.nsi. This seems > a bit simpler than what you propose. I sympathize with your desire to not abandon a scheme that works now in favor of one that you have not seen work. I expect that you would not relish the prospect of further labor: of changing the outline nodes that generate the script and one-time edits to restore the .nsi file. I won't volunteer anyone's time but my own for this. I could create a branch from a suitable revision of Leo's source code, working in private until my code is finished. I could even publish it on Launchpad for anyone else to follow along. The rest of Leo would change during my work, but I doubt that the contents of leoDist.leo and the files it contains would see changes from anyone other than me. My development would start with work to implement my scheme alongside yours, generating a separate .nsi file and using software -- a diff tool or Leo itself -- to prove that my scheme's .nsi file includes the exact statements included in yours. There -- no essay, just blunt English! With the human aspects of this addressed, on to the technical arguments! Your proposal -- putting all the boilerplate in a .txt file -- would allow me to maintain all the code in one place. It would still mean editing the boilerplate in the .txt file and the calls to the boilerplate in a Python script elsewhere in the Leo outline. I see this as similar to keeping the Leo trunk and a release branch in sync, which you write elsewhere is causing you headaches this week. I think the outline would be easier for developers to understand if the .nsi file were fully represented as a first-class citizen. The current scheme uses a button to generate the .nsi file. The scheme that I am suggesting would still use a button.This revised button would generate the "file manifest," "delete manifest" and "definitions" .nsi files for the real .nsi file to include. Why not have the button call bzr to generate the manifest file and then call the NSIS compiler to generate the .exe, and (if the compilation turns up no errors), delete the manifest files and the .nsi file? That way there would be no synchronization problem -- the Leo outline's button would be the *only* way to generate the Leo installer. I read in multiple sources that Python is a great tool for gluing together other software. This sounds like a gluing job. -- David --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
