From: Andrew B. <ab...@ee...> - 2002-01-03 03:44:45
|
This is configure making this C code and compiling it, not make.=20 Workaround #1 fails in the general case where I have to pass a configure option that takes a list of pathnames separated by colons. Or when configure uses AC_PATH_PROG() and tries to iterate over a list of paths. I'll try the second two.=20 I'm also having a problem in my scripts (bash scripts) because I put an MSYS-generated path in the script and need to pass it to XEmacs to assign to one of its variables: e.g. export LOADPATH=3D/h/harmonia/src/lib/xemacs /e/xemacs/xemacs-21.4/src/xemacs -eval (setq load-path (cons \"$LOADPATH\" load-path)) LOADPATH's value was filled in by my configure script which searched for some files and found the path. My XEmacs only understands native pathnames, and fails to set the load-path to a usable value. :( I keep coming back to the solution of some sort of cygpath-like program that translates MSYS paths back into Windows paths, so that we can lift our application and scripts out of MSYS once it has finished configuring and building.=20 Thanks for putting up with all my crap, Andy > -----Original Message----- > From: Earnie Boyd [mailto:ear...@ya...] > Sent: Friday, December 28, 2001 8:51 PM > To: Andrew Begel > Cc: min...@li... > Subject: Re: [Mingw-msys] Problem building XEmacs >=20 >=20 > Andrew Begel wrote: > >=20 > > I'm trying to configure XEmacs with MSYS. Part of the=20 > configure script > > does this: > >=20 > > cat > $tempcname < confdefs.h > > cat >> $tempcname <<EOF > > #define NOT_C_CODE > > #define C_SWITCH_SITE > > #define C_SWITCH_X_SITE > > #define LD_SWITCH_SITE > > #define LD_SWITCH_X_SITE > > #define LD_SWITCH_X_SITE_AUX > > #define OS_RELEASE $os_release > >=20 > > #ifdef config_opsysfile > > #include "$srcdir/src/$opsysfile" > > #endif > >=20 > > #ifdef config_machfile > > #include "$srcdir/src/$machfile" > > #endif > >=20 > > Where $srcdir is an MSYS path. It's put directly into a #include and > > then passed to MinGW's gcc. But gcc can't read MSYS paths=20 > when found in > > #includes. > >=20 > > Is there a good way to rewrite this form to work in MSYS? > >=20 >=20 > Which version of make are you using? If you use `gmake=20 > MAKE=3Dgmake' does > that help? >=20 > Work arounds: >=20 > 1) Modify the Makefile to set the variables so that they are Win32 > absolute but with forward slashes. E.G.: If srcdir =3D=20 > /path/to/foo which > is in reality c:\msys\1.0\usr\src\foo then change it to srcdir =3D > c:/msys/1.0/usr/src/foo. >=20 > 2) Use an absolute name for the include files and don't use the > variablized include and used the -I switch to GCC. >=20 > 3) Generate the c file in the build directory with the appropriate > include file already resolved. >=20 > HTH, > Earnie. >=20 > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com >=20 >=20 |
From: Earnie B. <ear...@ya...> - 2002-01-07 13:14:36
|
I've been out of the office for a couple of weeks. Once I catch up I'll respond to this. Andrew Begel wrote: > > This is configure making this C code and compiling it, not make. > > Workaround #1 fails in the general case where I have to pass a configure > option that takes a list of pathnames separated by colons. Or when > configure uses AC_PATH_PROG() and tries to iterate over a list of paths. > > I'll try the second two. > > I'm also having a problem in my scripts (bash scripts) because I put an > MSYS-generated path in the script and need to pass it to XEmacs to > assign to one of its variables: > > e.g. > > export LOADPATH=/h/harmonia/src/lib/xemacs > /e/xemacs/xemacs-21.4/src/xemacs -eval (setq load-path (cons > \"$LOADPATH\" load-path)) > > LOADPATH's value was filled in by my configure script which searched for > some files and found the path. My XEmacs only understands native > pathnames, and fails to set the load-path to a usable value. :( > > I keep coming back to the solution of some sort of cygpath-like program > that translates MSYS paths back into Windows paths, so that we can lift > our application and scripts out of MSYS once it has finished configuring > and building. > > Thanks for putting up with all my crap, > > Andy > > > -----Original Message----- > > From: Earnie Boyd [mailto:ear...@ya...] > > Sent: Friday, December 28, 2001 8:51 PM > > To: Andrew Begel > > Cc: min...@li... > > Subject: Re: [Mingw-msys] Problem building XEmacs > > > > > > Andrew Begel wrote: > > > > > > I'm trying to configure XEmacs with MSYS. Part of the > > configure script > > > does this: > > > > > > cat > $tempcname < confdefs.h > > > cat >> $tempcname <<EOF > > > #define NOT_C_CODE > > > #define C_SWITCH_SITE > > > #define C_SWITCH_X_SITE > > > #define LD_SWITCH_SITE > > > #define LD_SWITCH_X_SITE > > > #define LD_SWITCH_X_SITE_AUX > > > #define OS_RELEASE $os_release > > > > > > #ifdef config_opsysfile > > > #include "$srcdir/src/$opsysfile" > > > #endif > > > > > > #ifdef config_machfile > > > #include "$srcdir/src/$machfile" > > > #endif > > > > > > Where $srcdir is an MSYS path. It's put directly into a #include and > > > then passed to MinGW's gcc. But gcc can't read MSYS paths > > when found in > > > #includes. > > > > > > Is there a good way to rewrite this form to work in MSYS? > > > > > > > Which version of make are you using? If you use `gmake > > MAKE=gmake' does > > that help? > > > > Work arounds: > > > > 1) Modify the Makefile to set the variables so that they are Win32 > > absolute but with forward slashes. E.G.: If srcdir = > > /path/to/foo which > > is in reality c:\msys\1.0\usr\src\foo then change it to srcdir = > > c:/msys/1.0/usr/src/foo. > > > > 2) Use an absolute name for the include files and don't use the > > variablized include and used the -I switch to GCC. > > > > 3) Generate the c file in the build directory with the appropriate > > include file already resolved. > > > > HTH, > > Earnie. > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > _______________________________________________ > Mingw-msys mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-msys _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Earnie B. <ear...@ya...> - 2002-01-08 00:07:01
|
Andrew Begel wrote: > > This is configure making this C code and compiling it, not make. > > Workaround #1 fails in the general case where I have to pass a configure > option that takes a list of pathnames separated by colons. Or when > configure uses AC_PATH_PROG() and tries to iterate over a list of paths. > Interesting. So the filter needs to search for ':' and translate to ';' then parse each segment independently for path conversion. I need to think this out carefully because changing the ':' to ';' could cause havoc elsewhere in the configure script as it searches for ':' within the script. I can see a possible change to setenv to set not only a POSIX environment variable but also an internal Win32 version. > I'll try the second two. > > I'm also having a problem in my scripts (bash scripts) because I put an > MSYS-generated path in the script and need to pass it to XEmacs to > assign to one of its variables: > > e.g. > > export LOADPATH=/h/harmonia/src/lib/xemacs > /e/xemacs/xemacs-21.4/src/xemacs -eval (setq load-path (cons > \"$LOADPATH\" load-path)) > > LOADPATH's value was filled in by my configure script which searched for > some files and found the path. My XEmacs only understands native > pathnames, and fails to set the load-path to a usable value. :( > This would be helped by converting the environment; however converting the environment may have a differing effect on AC_PATH_PROG. > I keep coming back to the solution of some sort of cygpath-like program > that translates MSYS paths back into Windows paths, so that we can lift > our application and scripts out of MSYS once it has finished configuring > and building. > But that would defeat what my intention is. I don't want you to have to muck with it externally. > Thanks for putting up with all my crap, > Thanks for using mine. Without someone using it, it's not going to get past the rough waters. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Mike T. <mi...@br...> - 2002-01-09 01:08:48
|
Hi Earnie. > Thanks for using mine. Without someone using it, it's not going to get > past the rough waters. As you may only be hearing bug reports as opposed to reports of success, I thought that I should let you know that I have successfully used MSYS to configure (as opposed to build) a number of projects over the past few weeks including GNU fileutils, thanks. I did this while comparing MSYS, PW32 and Cygwin as build environments for Mingw32. Cheers Mike Thomas. |