From: Earnie <ea...@us...> - 2011-10-23 21:31:27
Attachments:
mgwport.diff.txt
|
Any change the attached patch could make to mgwport so that if I have it on a thumb drive it still works? I know packages created for MinGW should be prefixed to c:/mingw but that doesn't mean I need to have it installed there by default and mgwport should just work if I don't. Earnie |
From: Charles W. <cwi...@us...> - 2011-10-24 00:42:11
|
On 10/23/2011 5:31 PM, Earnie wrote: > Any change the attached patch could make to mgwport so that if I have it > on a thumb drive it still works? I know packages created for MinGW > should be prefixed to c:/mingw but that doesn't mean I need to have it > installed there by default and mgwport should just work if I don't. Well, first -- that file is generated by config.status-substitution on mgwport.in. The relevant snippet is: declare -r _privlibdir=@pkglibdir@; declare -r _privdatadir=@pkgdatadir@; declare -r _privclassdir=@mgwclassdir@; declare -r _privdocdir=@docdir@; declare -r _privgnuconfigdir=@gnuconfigdir@; declare -r _sysconfdir=@sysconfdir@; Hence, the dependence on "hard-coded" paths in the generated file. Now, (except for gnuconfigdir), each of those @replacements@ are controllable by cmdline configure arguments. If I want to retain that flexibility (and I do, specifically for cross-compiling mgwport itself on, say, a cygwin $host, where sysconfdir should equal /etc, and not /mingw/etc == $prefix/etc.) -- then I need to come up with a way to automatically deduce the appropriate relative substitutions from the configure subs. Or you could simply build mgwport from source, on your computer, with whatever --configure args you like... -- Chuck |
From: Keith M. <kei...@us...> - 2011-10-24 16:56:50
Attachments:
mgwport.diff
|
On 23/10/11 22:31, Earnie wrote: > Any change the attached patch could make to mgwport so that if I have it > on a thumb drive it still works? I know packages created for MinGW > should be prefixed to c:/mingw but that doesn't mean I need to have it > installed there by default and mgwport should just work if I don't. I encountered the same problem, but... > -declare -r _privlibdir=c:/MinGW/lib/mgwport; > ... > +declare -r _privroot=`cd /mingw && pwd -W`; > +declare -r _privlibdir=${_privroot}/lib/mgwport; > +declare -r _privdatadir=${_privroot}/share/mgwport; > ... is NOT a sufficiently generalised solution; (it effectively ties the code to host=MSYS only, whereas)... On 24/10/11 01:41, Charles Wilson wrote: > Well, first -- that file is generated by config.status-substitution on > mgwport.in. The relevant snippet is: > > declare -r _privlibdir=@pkglibdir@; > declare -r _privdatadir=@pkgdatadir@; > declare -r _privclassdir=@mgwclassdir@; > declare -r _privdocdir=@docdir@; > declare -r _privgnuconfigdir=@gnuconfigdir@; > declare -r _sysconfdir=@sysconfdir@; Which may seem reasonable, but notwithstanding, the hard-coding effect just smells wrong. > Hence, the dependence on "hard-coded" paths in the generated file. Now, > (except for gnuconfigdir), each of those @replacements@ are controllable > by cmdline configure arguments. If I want to retain that flexibility > (and I do, specifically for cross-compiling mgwport itself on, say, a > cygwin $host, where sysconfdir should equal /etc, and not /mingw/etc == > $prefix/etc.) -- then I need to come up with a way to automatically > deduce the appropriate relative substitutions from the configure subs. Yep. That's why the '_privroot=$(cd /mingw && pwd -W)' approach is equally unsatisfactory. I hacked around the issue with an alternative variation on the same theme, (patch attached), which likely still isn't completely satisfactory, (since it probably fails to map _sysconfdir correctly), but it is significantly more generalised; it at least gets me past this first hurdle, on the Linux box where I want to run it. > Or you could simply build mgwport from source, on your computer, with > whatever --configure args you like... I could, but I don't think I should need to. Moreover, even if I do create a custom build, I can't test it without first installing it, so I may need to build it twice, (with different configure settings for a sandboxed build, from those for the final installation). Yuck! -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-10-24 17:11:06
|
On 10/24/2011 5:08 AM, Keith Marshall wrote: > On 24/10/11 01:41, Charles Wilson wrote: >> I need to come up with a way to automatically >> deduce the appropriate relative substitutions from the configure subs. > > Yep. That's why the '_privroot=$(cd /mingw && pwd -W)' approach is > equally unsatisfactory. I hacked around the issue with an alternative > variation on the same theme, (patch attached), which likely still isn't > completely satisfactory, (since it probably fails to map _sysconfdir > correctly), but it is significantly more generalised; it at least gets > me past this first hurdle, on the Linux box where I want to run it. Yes. I recall some example code for doing this sort of relocation thing, within shell scripts, in gnulib's relocatable module. It's used by gettextize. I'll see what can be re-used from that. >> Or you could simply build mgwport from source, on your computer, with >> whatever --configure args you like... > > I could, but I don't think I should need to. Sure, it's just meant as a short term workaround until the task above is completed. -- Chuck |