|
On 06/16/2012 11:03 PM, Yaroslav Halchenko wrote: Thank you Bhaskar for the testing details! The will definetely be useful to provide at least a minimal test of having things built/installed correctly. My family keeps me heavily occupied this weekend so I will have a chance to look at it with a clear head only early next week. But regarding:$ $gtm_dist/mumps -direct GTM>write $text(^%RSEL) ; Notice the blank line GTM>zhelp ; This will clear the screen and generate an error (clears the screen) Error in GT.M help utility GTM>halt $ So you definitely need a postinstall script, and you cannot just install it in one place and move it.I still hope that we could find the relevant code where the filename gets embedded so we could either patch it simply to look for the original .m in the same directory where the .o/.so is, or just to provide compile time argument (e.g. via env variable) to allow "install" into a location with a predefined prefix (i.e. temporary build top directory) which would not be placed into the generated .o file, thus allowing to install the binary into the location without that prefix. Any hints would be more than welcome where to dig in the right direction ;-) [KSB] I'll see about getting you that information - it is possible that none of the developers knows that answer right off the top of his head and some research will be needed. But be aware that you cannot simply "patch it" to look for the original .m file in the same directory without breaking a large number of existing applications that use GT.M, since it is quite common for the source and object files to not be in the same directory. What you are really asking for is an enhancement to GT.M. I can think of a couple of ways to approach the enhancement, but none of them is trivial. For example, one could add an environment variable to tell the compiler to use a relative path to the source instead of an absolute path, or one could provide an option to special case the path if the source module is in the directory pointed to by $gtm_dist. If I understand correctly, you want to make these changes to avoid a postinstall script in the package. I have to ask whether this amounts to spending ten dollars to save one dollar. With the appropriate command line flags, the gtminstall script that comes with GT.M from upstream does everything needed for the postinstall. When we met last week, you said that you wanted to protect against a postinstall that fails, e.g., runs out of room on disk. If that is the case, you can move the installation from the temporary location to the normal location and then use the --overwrite-existing option of the gtminstall script to install on top of an installation, the one that was moved. If there is something you need gtminstall to do differently, please let me know and I am happy to work with you to enhance it. But changes in the core of GT.M should not be made lightly because there are twenty-six years of application code that runs on GT.M and which we cannot afford to break. Changing the topic, I think the pre-remove script requires some thought and should be coded along the following lines, assuming that $gtm_dist is set to the directory of the GT.M release to be removed (if the environment variable is not set, the mupip command described below will not run):
Regards -- Bhaskar -- GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. |