> Is it just me or is "make check" completely hosed? I'm not at all
> confident in my environment here so this isn't rhetorical. Can someone
> please confirm a working "make check" please?
>
SuSE 7.0 (more or less unmolested)
make check passes smothly
78 Tests Complete ... No Failures :-)
I
Is it just me or is "make check" completely hosed? I'm not at all
confident in my environment here so this isn't rhetorical. Can someone
please confirm a working "make check" please?
Michael Sterrett
-Mr. Bones.-
[EMAIL PROTECTED]
On Tue, 10 Sep 2002 [EMAIL PROTECTED] wrote:
> -BEGIN P
My previous message should have given the URL as:
ftp://alpha.gnu.org/gnu/make/make-3.80rc2.tar.gz
ftp://alpha.gnu.org/gnu/make/make-3.80rc2.tar.bz2
not "alpha.ftp.org". Sums in my previous email are correct. Sorry for
the confusion :(
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all;
I've published the second Release Candidate for GNU make 3.80. You can
get it from:
ftp://alpha.ftp.org/gnu/make/
Contrary to what the name might imply, there have been a number of
changes between the first and second Release Candidates.
"Paul D. Smith" <[EMAIL PROTECTED]> wrote in
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
> The whole entire point of using automake is to allow packages to ship
> with makefiles that are 100% portable without having to go through all
> the effort to write them--which is considerable if you don't
%% Soren A <[EMAIL PROTECTED]> writes:
sa> Yes, this will definitely fix MinGW.
Good, I'm happy then :).
sa> I guess that is the part that confused me, indirectly, so to
sa> speak. Is there some reason to prefer to use memmove() over
sa> bcopy() if both are available?
Realistically it
I am freed from the vile wilderness of Confusion at last ...
"Paul D. Smith" <[EMAIL PROTECTED]> wrote in
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
> %% Soren A <[EMAIL PROTECTED]> writes:
>
> >> I don't understand this. If bcopy() isn't there and memmove() is
> >> (which wasn't being che
%% mst <[EMAIL PROTECTED]> writes:
m> How about a way to call "system" without catching stdout, let
m> stdout be copied as is to the child process?
Hmm. Maybe. I still don't know that it's that useful.
Why don't you just test STDERR instead of STDOUT?
Make doesn't redirect STDERR.
--
-
