|
On 06/18/2012 02:42 PM, Brad King wrote: On 06/18/2012 12:00 PM, Bhaskar, K.S wrote:[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.I don't think we need any change to the behavior of object file loading/linking. The goal is to compile .m to .o in a DESTDIR. We do not need to load/run the resulting .o files from that location. We only need the stored path to the .m to point to the final path in which the sources will be put when the package is installed. When gtm loads a .o after installation on the end user's system it will find the .m where it expects with no change in search behavior. Here is a patch series that solves this problem. I've only done some lightweight/manual testing with this. The first patch refactors both i386 and x86_64 code paths that emit the path to the source file into the object file to send source file path lookup through a common point (in obj_source.c). The second patch modifies this common point to read a 'gtm_destdir' env var and strip the prefix it names from source file paths. The net diffstat of the series is: sr_i386/obj_file.c | 8 ++++++-- sr_unix/comp_lits.c | 11 +++++++---- sr_unix/obj_file.c | 10 ++++++---- sr_unix/obj_source.c | 25 +++++++++++++++++++++++++ sr_unix/obj_source.h | 12 ++++++++++++ sr_unix_nsb/comp_lits.c | 11 +++++++---- 6 files changed, 63 insertions(+), 14 deletions(-) I tried to follow style and portability conventions I found in existing sources, but this is the first time I've read the code so the patches may need adjustment for such things. The series also doesn't touch any documentation. [KSB2] Thank you very much, Brad. We would like to ask if you would be willing to solve the issue with one of two slightly different approaches from what you have implemented.
Thanks again. 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. |