Hello Gnu.org-
Using my RedHat Linux version 6.2, I did this:
a. opened http://www.gnu.org/manual/manual.html
b. clicked (selected) make-379.1
c. clicked (selected) PostScript file (291K chars gzipped)
d. downloaded completely a file named make.ps.gz
e. using gunzip 1.2.4, didgunzip
This is a known bug; it's been fixed in the source code in CVS and will
be included in the next release of GNU make.
Thanks for the report!
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
With the following Makefile:
define thing
echo 1
@echo 2
echo 3
endef
test:
$(thing)
run make. In version 3.79.1, the output is
echo 1
1
2
3
In version 3.77, the output is the expected
echo 1
1
2
echo 3
3
The behavior in 3.79.1 does not agree with
%% Chip Cuntz <[EMAIL PROTECTED]> writes:
cc> If I run gmake without changing anything on SUN, gmake always
cc> thinks "Prerequisite `*.o' is newer than target `common.a(*.o)'.".
Check the GNU make README; look at the last paragraph. Although not
stated there, this issue applies to ar as we
All,
I have the following Makefile that I use to build a static library. The
problem is that it works differently on AIX and SUN using v3.79.1. The
problem can be described as follows:
If I run make without changing anything on AIX, /usr/ccs/bin/make is smart
enough to recognize the library is
%% [EMAIL PROTECTED] writes:
th> So, vpath's don't seem to work for locating 'include' makefiles. For
th> example, you can't do this:
th>vpath %.d directory
th>-include src1.d src2.d src3.d
th> Is this by design?
This is how it's implemented and documented, yes. The manual
