> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Jul 11, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> I don't think we need to: test -f itself will do the right thing,
Alexandre> Nope. Think of /foo, when /foo doesn't exist, but
Alexandre> $srcdir/foo does.
A
> "Steve" == Steve Robbins <[EMAIL PROTECTED]> writes:
Steve> Thanks, Akim.
Hi Steve!
Steve> I think what Lars sent out most recently was a *NEW* macro,
Steve> which we have been calling AC_FUNC_SELECT. The name is up for
Steve> discussion of course, but it should be different from the
Ste
On Wed, Jul 12, 2000 at 10:08:46AM +0200, Akim Demaille wrote:
: Well, this then?
:
: for f in $ac_file_in; do
: case $f in
: -) echo $tmp/stdin ;;
: [[\\/$]]* | ?:[[\\/]]*)
: # Absolute
: test -f "$f" || AC_MSG_ERROR([cannot find input file \\`$f'])
:
Akim Demaille wrote:
>
> | Thanks.
> | So, is next redaction (for autoconf 1.3) is good ?
>
> *A*utoconf *2.50* :)
>
no, *this* is for 1.3; for 2.50 will be released after releasing
autoconf snapshot ;)
...
Ooops,. thanks again.
So, finally:
# RSSH_CHECK_SUNPROC_C([ACTION-IF-YES], [ACT
I've just upgraded our projects to CVS Autoconf and CVS Automake.
It works great on Unix, but on Cygwin, with the VC++ 6.0 compiler, it
stops on the "C++ compiler working" test, because it doesn't understand
that "conftest.cc" is a .cpp file so it defaults to "object file" type
and fails on "corru
On Wed, 12 Jul 2000, Lars J. Aas wrote:
> I've just upgraded our projects to CVS Autoconf and CVS Automake.
> It works great on Unix, but on Cygwin, with the VC++ 6.0 compiler, it
> stops on the "C++ compiler working" test, because it doesn't understand
> that "conftest.cc" is a .cpp file so it d
On Wed, Jul 12, 2000 at 02:54:28AM -0700, Mo DeJong wrote:
: I ran into a problem like the one you describe. It seems
: that the CVS version of autoconf does not work with
: VC++ at all.
This is *bad* news for me, but probably not for Autoconf development,
as I'll have to work on fixing this...
[a-z] gets expanded by the shell:
--- autoconf.sh 2000/07/10 10:23:09 1.76
+++ autoconf.sh 2000/07/12 10:31:31
@@ -223,7 +223,7 @@
# 2. $WARNINGS, $3 command line options, in that order.
# Set them in the order expected by the M4 macros: the converse.
_ac_warnings=
-for warning in `IFS=,;
On Wed, Jul 12, 2000 at 12:29:36PM +0200, Johan Danielsson wrote:
: [a-z] gets expanded by the shell:
:
: --- autoconf.sh 2000/07/10 10:23:09 1.76
: +++ autoconf.sh 2000/07/12 10:31:31
: @@ -223,7 +223,7 @@
: # 2. $WARNINGS, $3 command line options, in that order.
: # Set them i
"Lars J. Aas" <[EMAIL PROTECTED]> writes:
> Why use the braces at all? Are they really necessary? tr A-Z a-z has
> always worked for me, and that format won't be expanded by the shell.
That's probably better.
/Johan
Functions like accept are known to have THREE different prototypes:
int accept (int, struct sockaddr *, socklen_t *); /* Linux, Unix98 */
int accept (int, struct sockaddr *, size_t *); /* Solaris 2.6 */
int accept (int, struct sockaddr *, int *); /* DEC OSF 4.0e */
I think autoconf should have
Martin Buchholz <[EMAIL PROTECTED]> writes:
> Functions like accept are known to have THREE different prototypes:
>
> int accept (int, struct sockaddr *, socklen_t *); /* Linux, Unix98 */
> int accept (int, struct sockaddr *, size_t *); /* Solaris 2.6 */
> int accept (int, struct sockaddr *, int
Hi,
On Wed, Jul 12, 2000 at 12:30:21AM -0400, Steve Robbins wrote:
> Argument 5 is --- as far as I can tell --- always 'struct timeval *' or
> 'const struct timeval *'. For code that uses select(), you needn't care
> whether it is prototyped with 'const' or not, right? So nothing needs to
> be
I have come across one compiler that returns an exit status of 0
if compile errors occur :-{
Thus, AC_COMPILE_IFELSE can't be used to test this compiler's features.
Suggestions?
--
Martin Wilck <[EMAIL PROTECTED]>
Institute for Tropospheric Research, Permoserstr. 15, D-04318 Leipzig, Germany
I wrote:
>
> I have come across one compiler that returns an exit status of 0
> if compile errors occur :-{
>
> Thus, AC_COMPILE_IFELSE can't be used to test this compiler's features.
>
> Suggestions?
A possible workaround is using AC_LINK_IFELSE instead, since that tests
whether an output fil
| [a-z] gets expanded by the shell:
Thanks! Applied.
Alexandre Oliva writes:
> > What about systems that don't have a `cc' but only a `gcc' or whatever
> > else?
>
> The user would have to set CC_FOR_BUILD. But see below:
>
> >> In the future, it may be extended to look for gcc if it can't find
> >> cc.
But that would break things for a lot of
Martin Wilck writes:
> Another point though (practical experience): The SGI, Sun, AIX machines
> at our site often have poorly administered GNU software installed that
> is outdated or sometimes even doesn't work at all, whereas the
> vendor software is updated on a regular basis. This may result
On Wed, 12 Jul 2000, Peter Eisentraut wrote:
> Alexandre Oliva writes:
>
> > > What about systems that don't have a `cc' but only a `gcc' or whatever
> > > else?
> >
> > The user would have to set CC_FOR_BUILD. But see below:
> >
> > >> In the future, it may be extended to look for gcc if it
Martin Buchholz writes:
> Functions like accept are known to have THREE different prototypes:
>
> int accept (int, struct sockaddr *, socklen_t *); /* Linux, Unix98 */
> int accept (int, struct sockaddr *, size_t *); /* Solaris 2.6 */
> int accept (int, struct sockaddr *, int *); /* DEC OSF 4.0e
Lars J. Aas writes:
> : -for warning in `IFS=,; echo syntax,$WARNINGS,$warnings | tr [A-Z] [a-z]`
> : +for warning in `IFS=,; echo syntax,$WARNINGS,$warnings | tr '[A-Z]' '[a-z]'`
>
> Why use the braces at all? Are they really necessary? tr A-Z a-z has
> always worked for me, and that format w
I am getting this strange error from autoheader.
% autoheader
autoheader: No template for symbol `PATH_SEPARATOR'
The code that defines this var looks like:
AC_DEFINE(PATH_SEPARATOR, ';')
Whats up with that?
If I use the old version of autoheader, it given
me some other error.
Symbol `PATH_
> "lb" == lars brinkhoff <[EMAIL PROTECTED]> writes:
lb> For comparision, this is what I use in an application of mine. I
lb> haven't heard any complaints from Solaris users, but I guess they have
lb> just ignored any compilations warnings.
I don't include . The standard says I shouldn't h
> "PE" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
PE> Martin Buchholz writes:
>> Functions like accept are known to have THREE different prototypes:
>>
>> int accept (int, struct sockaddr *, socklen_t *); /* Linux, Unix98 */
>> int accept (int, struct sockaddr *, size_t *); /* Solaris 2
I've been watching these discussions with interest, as INN uses both of
those functions and I've been trying to figure out if I need to worry
about these macros. One thing that I'm mostly missing, though, is what
benefits a portable program gains from either of these, particularly from
accept.
F
Autoconf 2.13 can't distinguish between --version and --verbose options.
The latter is apparently no longer a valid option, which is fine, but
then an attempt to use it should result in a usage message. Instead,
it is mistaken for the "--version" option.
This transcript shows all:
$ autocon
26 matches
Mail list logo
