Hello,
> > from source (there could be virii in a configure script, ya know
you mean a real virus, which would infect the autoconf you build?
And thus newly generated configure would be identical to the one you
checked out? That would be cool!
> > -AC_PROG_GREP
> > +AC_SUBST(GREP, grep)
Unfort
Hi David,
David Fang wrote:
> I naively tried to use AC_CHECK_FILE(S) on /dev/stdin /dev/stdout
> and /dev/stderr to detect their presence, but the test result is
> 'no' for these 'files'.
These are not real devices. You may find entries in /dev, which
suggest otherwise, but look closely: if th
Hello,
Chris proposed to document that autoreconf doesn't pass -I to
aclocal. I remember that I was confused by this some time ago, too.
I think his addition can help many users, and there were no objections,
so I committed it, as attached.
(I changed s/on to/to/ on the last line, it seems mor
> > I naively tried to use AC_CHECK_FILE(S) on /dev/stdin /dev/stdout
> > and /dev/stderr to detect their presence, but the test result is
> > 'no' for these 'files'.
>
> These are not real devices. You may find entries in /dev, which
> suggest otherwise, but look closely: if they exist at all, t
David Fang <[EMAIL PROTECTED]> writes:
> To give a little more context for what I'm trying to do in C++
> (experimentally): I've discovered that std::ifstream foo("/dev/stdin")
> results in a file stream that works just like cin, likewise for stdout,
> etc... Just like in standard C, one co
> > To give a little more context for what I'm trying to do in C++
> > (experimentally): I've discovered that std::ifstream foo("/dev/stdin")
> > results in a file stream that works just like cin, likewise for stdout,
> > etc... Just like in standard C, one could use stdin, stdout, stderr as
>
Keith MARSHALL <[EMAIL PROTECTED]> writes:
> David Fang wrote:
>> I naively tried to use AC_CHECK_FILE(S) on /dev/stdin /dev/stdout
>> and /dev/stderr to detect their presence, but the test result is
>> 'no' for these 'files'.
>
> These are not real devices. You may find entries in /dev, which
> s
> Whether /dev/std{in,out,err} are devices, symlinks, or even present
> is going to be system dependent.
>
> They're real character devices on NetBSD:
> $ ls -l /dev/std{in,out,err}
> crw-rw-rw- 1 root wheel 22, 2 Feb 19 11:01 /dev/stderr
> crw-rw-rw- 1 root wheel 22, 0 Feb 19 11:01 /dev/stdi
Hi David,
* David Fang wrote on Fri, Mar 31, 2006 at 03:53:16AM CEST:
>
> As I said in the other message, I just need to see if it is openable and
> usable with std::ifstream, so I've devised the following test. Does this
> look reasonable?
Yes (without having tested it). A couple of very mino
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> While I don't mind doing two alpha releases, wouldn't it be more
> sensible to postpone the alpha release until all those pending changes
> are applied?
No, sorry, by "pending changes" I meant "all the changes that we've
made since 2.59".
Our main pr
> Yes (without having tested it). A couple of very minor nits inline:
>
> > AC_DEFUN([AC_CXX_STD_IFSTREAM_DEV_STDIN],
>
> Please do not name your private macro with `AC_*'. That's the "name
> space" reserved for macros from Autoconf proper. It's commonly seen
> to use ones initials or a project
Hi David,
* David Fang wrote on Fri, Mar 31, 2006 at 08:48:46AM CEST:
>
> > You are assuming an ISO C++ compiler with proper namespace support
> > anyway, right?
> Yeah, for this project, at least, I'm restricting to ANSI/ISO std.
> C++ compilers as much as possible while making *reasonabl
12 matches
Mail list logo
