> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Actually, cvs libtool is still much happier with autoconf-2.13
Gary> than cvs autoconf =(O| I am hoping that a 2.50 compatible
Gary> libtool-1.4 won't be too far behind the autoconf release...
What's wrong? How does it happen? Wh
This new version of the patch avoids the non-portable use of the "-ef"
option to ``test''.
Is this one ok?
Regards,
Morten
Index: ChangeLog
===
RCS file: /cvs/autoconf/ChangeLog,v
retrieving revision 1.897
diff -u -r1.897 ChangeL
Akim Demaille wrote:
> The previous code was, apparently, able to cope with other extensions
> than `' and `.exe'. I know of no others,
There was the Atari ST/TT family (TOS), which had used *.prg, *.ttp
and *.tos, IIRC.
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte W
| * Morten
| | It was also mentioned on the list a while ago (by yours truly) how the
| | _AC_EXEEXT macro has a circular dependency: _AC_EXEEXT uses
| | AC_LINK_IFELSE which uses $ac_exeext which is found by _AC_EXEEXT.
|
| * Akim
| | AFAICS you still have this problem: you use AC_LINK_IFELSE.
Hi,
this patch contains various simple fixes for misuse or missing use of
the object file extension and executable file suffix.
Regards,
Morten
Index: ChangeLog
===
RCS file: /cvs/autoconf/ChangeLog,v
retrieving revision 1.897
di
* Akim
| [...] Your patch, as is, does not solve [...]
I know, I know. I don't claim the patch to be perfect, I'm just saying
that it is _better_ than the code it replaces. :^}
| [...] since AC_PROG_CC launches AC_EXEEXT which uses AC_LINK_IFELSE
| which requires AC_PROG_CC, autoconf should and
On Tue, Oct 10, 2000 at 07:35:52PM +0200, Akim Demaille wrote:
: | BTW, is the "-ef" option to ``test'' portable? If not, that part could
: | be stripped out.
:
: See the documentation of Autoconf :)
:
: @item @command{test} (files)
: To enable @code{configure} scripts to support
| * Akim
| | [...] Your patch, as is, does not solve [...]
|
| I know, I know. I don't claim the patch to be perfect, I'm just saying
| that it is _better_ than the code it replaces. :^}
|
| | [...] since AC_PROG_CC launches AC_EXEEXT which uses AC_LINK_IFELSE
| | which requires AC_PROG_CC, au
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> Note that the above described "-e" option is a completely
Lars> different option from the "-ef" option. When finding the
Lars> exeext, I also believe it is unproblematic to do so on the build
Lars> system, regardless of whether you cro
* Akim
| Then let me restate my question: why don't you use AC_TRY_EVAL just
| like in AC_EXEXT: this is a good first step I think.
Umm.. I assume you mean to ask "why not use AC_TRY_EVAL in AC_EXEEXT
just like in AC_OBJEXT" (and not "..like in AC_EXEEXT")?
If so, my question for you is then: wh
| * Akim
| | Then let me restate my question: why don't you use AC_TRY_EVAL just
| | like in AC_EXEXT: this is a good first step I think.
|
| Umm.. I assume you mean to ask "why not use AC_TRY_EVAL in AC_EXEEXT
| just like in AC_OBJEXT" (and not "..like in AC_EXEEXT")?
|
| If so, my question fo
* Akim
| I agree there are *two* issues. One is that there is a AC_REQUIRE
| circular dependency because AC_EXEXT uses AC_LINK_IFELSE, the other
| is that both AC_LINK_IFELSE and AC_TRY_EVAL(ac_link) are
| inappropriate here.
Aha. How about the attached patch, then?
Regards,
Morten
Index: Ch
Akim Demaille writes:
> So I am back to something I raised some time ago: why the heck do we
> have to compile to recognize Mingw etc.? Can't we just uname? While
> anti-Autoconf (and btw, frankly, compiling __MINGW32__ makes no big
> difference to me), it seems better in that, for instance, it
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> [...] I mean if you do cc conftest.c -o conftest, and afterwards
> there is no file "conftest", but there is a file "conftest.exe" that
> wasn't there before, that should be pretty conclusive, no?
Not really, no. For instance, Cygwin does this funny
Hello, Morten!
> Not really, no. For instance, Cygwin does this funny thing where they
> map all files named ``something.exe'' to also match any inquires to a
> file named ``something''.
Why do you want to set ac_exeext to ".exe" then? Why bother if Cygwin did
everything to hide this complexity
--- Pavel Roskin <[EMAIL PROTECTED]> wrote:
> Hello, Morten!
>
> > Not really, no. For instance, Cygwin does this funny thing where they
> > map all files named ``something.exe'' to also match any inquires to a
> > file named ``something''.
>
> Why do you want to set ac_exeext to ".exe" then? Wh
Morten Eriksen writes:
> (So, in the Cygwin case it doesn't really matter whether you set the
> executable suffix to ".exe" or "", I guess.)
This equivalency only affects stat() and the PATH search of the shell. So
you can write makefiles like this:
fooprog: $(OBJS)
$(CC) -o $@ $^
ins
Hello, Peter!
> One real example is PostgreSQL on AIX, where you need to use xlc instead
> of whatever else configure might think. (AC_PROG_CC_STDC is less than
> ideal for related reasons.) I still want to check for gcc first, though,
> so I'd use AC_PROG_CC([gcc xlc cc]). Then we have older
Hello, Peter!
> This equivalency only affects stat() and the PATH search of the shell. So
> you can write makefiles like this:
>
> fooprog: $(OBJS)
> $(CC) -o $@ $^
>
> install: fooprog
> $(INSTALL) fooprog$(EXEEXT) $(bindir)
>
> and they will work. But it probably doesn't in gen
--- Pavel Roskin <[EMAIL PROTECTED]> wrote:
>
> Since EXEEXT="" makes "cp" fail it's not a good choice. So instead of
> doing "test contest -ef contest.exe" do "cp contest contest.ac_" and
> reverse the logic (i.e. if "cp" fails we use ".exe")
>
This sounds good, but you'd have to test for the
20 matches
Mail list logo
