Re: AC_PROG_CC_C_O doesn't work with VC++

2005-10-27 Thread Harald Dunkel
Hi folks, Stepan Kasal wrote: > > I committed the patch attached to this mail. > Could you please apply the attached patch as well? It is necessary on Windows to detect '\' as a directory path separator. Many thanx Harri --- compile~ 2005-10-24 12:03:48.0 +0200 +++ compile 2005-10-26

Re: compile with VC++ (was: AC_PROG_CC_C_O doesn't work with VC++)

2005-10-24 Thread Keith MARSHALL
Stepan Kasal wrote: > I think that the parametr to compile should look like >some/path/main.c > which becomes cfile, and then cofile is assigned as... Just guessing, but with cl.exe being Bill's C compiler, it probably doesn't understand `some/path/main.c' as a path name; (it will

compile with VC++ (was: AC_PROG_CC_C_O doesn't work with VC++)

2005-10-24 Thread Stepan Kasal
Hello, [ let's move to automake@gnu.org ] On Mon, Oct 24, 2005 at 04:20:44PM +0200, Harald Dunkel wrote: > I think I found the problem. The compile script says at the > end > : > if test -f "$cofile"; then > mv "$cofile" "$ofile" > elif test -f "${cofile}bj"; then >

Re: AC_PROG_CC_C_O

2005-07-01 Thread Stepan Kasal
comment > above internally uses AC_PROG_CC_C_O. Of course, AM_PROG_CC_C_O may not be broken. Stepan

Re: AC_PROG_CC_C_O

2005-07-01 Thread Stepan Kasal
Hello, On Fri, Jul 01, 2005 at 02:33:57PM +0200, Ralf Wildenhues wrote: > > The macro has two uses: > > 1) in GNU make's configure.in > > 2) in Automake's AM_PROG_CC_C_O > > How do you know nobody else uses it? It's published. Of course I don't know. But it's so poorly designed, that I think i

Re: AC_PROG_CC_C_O

2005-07-01 Thread Ralf Corsepius
bdir-objects" (Flat Makefiles in deep source trees > > support) currently are using it. > > Erm, Stepan talks about AC_PROG_CC_C_O, subdir-objects however uses > AM_PROG_CC_C_O, right? Yep, I am referring to AM_PROG_CC_C_O, which according to the comment above internally uses AC_PROG_CC_C_O. Ralf

Re: AC_PROG_CC_C_O

2005-07-01 Thread Ralf Wildenhues
x27;s configure.in > > > 2) in Automake's AM_PROG_CC_C_O > > > > How do you know nobody else uses it? It's published. > > All packages using "subdir-objects" (Flat Makefiles in deep source trees > support) currently are using it. Erm, Stepan talks about AC_PROG_CC_C_O, subdir-objects however uses AM_PROG_CC_C_O, right? Regards, Ralf

Re: AC_PROG_CC_C_O

2005-07-01 Thread Ralf Corsepius
On Fri, 2005-07-01 at 14:33 +0200, Ralf Wildenhues wrote: > Hi Stepan, > > * Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST: > > > > The macro has two uses: > > 1) in GNU make's configure.in > > 2) in Automake's AM_PROG_CC_C_O > > How do you know nobody else uses it? It's published.

Re: AC_PROG_CC_C_O

2005-07-01 Thread Ralf Wildenhues
Hi Stepan, * Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST: > > The macro has two uses: > 1) in GNU make's configure.in > 2) in Automake's AM_PROG_CC_C_O How do you know nobody else uses it? It's published. > If yes, shouldn't we introduce a generalized macro, for example > >

AC_PROG_CC_C_O

2005-07-01 Thread Stepan Kasal
Hi, a bug report pointed me to AC_PROG_CC_C_O. The macro has two uses: 1) in GNU make's configure.in 2) in Automake's AM_PROG_CC_C_O ad 1) Special needs of a project should be solved in that project. ad 2) The comments in automake/m4/minuso.m4 explain why Automake is not happ