DECC's make utility, MMS, speaks a very, very strict and unforgiving
dialect of make. It's very useful for finding things like macros
defined twice or missing targets:
$ mms
%MMS-W-MBREDEFILL, Illegal attempt to redefine macro 'LD'
test : $(TEST_PROG) assemble.pl .test_dummy
%MMS-W-DRV
The patch below fixes a very basic Makefile syntax error (on VMS
anyway). MMS requires that there be at least one space between the
target and the colon.
http://www.openvms.compaq.com:8000/73FINAL/5825/5825_.htm
You begin a target or source line in column 1 of the line and use
the keywor
FWIW, I really like having make clean delete *~. But since we have things
like make cvsclean, i don't consider it essential.
--Josh
At 7:19 on 03/18/2002 GMT, Jonathan Stowe <[EMAIL PROTECTED]> wrote:
> There may be a very good reason for this that I haven't determined but
> this keeps catchi
There may be a very good reason for this that I haven't determined but
this keeps catching me - I don't really expect 'make clean' to be deleting
files that I have deliberately made:
--- Makefile.in~Mon Mar 18 07:06:35 2002
+++ Makefile.in Mon Mar 18 07:08:26 2002
@@ -425,7 +425,6 @@
At 10:05 PM 1/2/2002 -0500, Kevin Falcone wrote:
>docs/Makefile should be removed by realclean, but isn't
>I though I saw a patch for this go by at some point
Applied, thanks.
Dan
--"it's like this"---
D
docs/Makefile should be removed by realclean, but isn't
I though I saw a patch for this go by at some point
Index: Makefile.in
===
RCS file: /cvs/public/parrot/Makefile.in,v
retrieving revision 1.98
diff -u -r1.98 Makefile.in
--- Ma
> Easy Makefile.in patch. I was worried that Win32 might need the linker
> (the change to $(LD) was submitted as part of a Win32 compatibility
> patch) but that doesn't seem to be the case. I don't have a MinGW
Fine here
Regards
Mattia
Robert Spier:
# Gibbs Tanton - tgibbs writes:
# >Ok, here is the rule based makefile...
#
# Thanks
#
# Looks good (and works for me.)
#
# I suggest the following patch on top of Gibbs' patch, to seperate form
# and function of CC and CFLAGS. (Also, the "standard" (fwiw) is
# CFLAGS, not C_FLAGS)
On Sun, Sep 16, 2001 at 12:49:36PM -0700, [EMAIL PROTECTED] wrote:
> This should be done with an implicit rule or a pattern rule.
>
> By putting all the explicit lines in, it'll be harder to
> change later, and errors can crop up.
>
> The makefile needs a cleanup - we're not making good use of
>
Gibbs Tanton - tgibbs writes:
>Ok, here is the rule based makefile...
Thanks
Looks good (and works for me.)
I suggest the following patch on top of Gibbs' patch, to seperate form
and function of CC and CFLAGS. (Also, the "standard" (fwiw) is
CFLAGS, not C_FLAGS)
-R
--- Makefile.in.1
This should be done with an implicit rule or a pattern rule.
By putting all the explicit lines in, it'll be harder to
change later, and errors can crop up.
The makefile needs a cleanup - we're not making good use of
any of the 'features' of make.
Are we allowed to use gnu makeisms?
-R (holding
Ok, here is the rule based makefile...
-Original Message-
From: [EMAIL PROTECTED]
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED] '
Sent: 9/16/2001 2:49 PM
Subject: Re: [PATCH]Makefile.in
This should be done with an implicit rule or a pattern rule.
By putting all the expl
Brent,
This patch allows the Makefile to work for me...if the
$(CC) -o $*$(O) -c $*.c
line is not below each .c file cygwin's make does not do the right thing and
does not make properly. This patch adds those lines. If you have a better
way to do it, I would be glad to implement that instead.
13 matches
Mail list logo