🚀 go-pugleaf

%% Alex Vinokur <alexvn@bigfoot.com> writes:

  nav> What is the difference between :

  nav> .c.o:
  nav>     $(CC) <stuff>

  nav> and

  nav> %.o:  %.c ; $(CC) <stuff>

In this case, nothing.  Assuming that, in the first case, you have .c
and .o in your .SUFFIXES list, of course :).

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

I guess I should also point out a few other differences:

 1) The suffix form can be removed via the empty .SUFFIXES target; the
    pattern form can only be removed with the -r option.

 2) The pattern form isn't valid POSIX.2 make.

 3) The pattern form is much more flexible, which doesn't matter in this
    case as you've stated it but matters very much in other
    situations... like if you wanted the .o to go into a different
    directory for example.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

"Paul D. Smith" <psmith@gnu.org> writes:

> [...]
> 
>  3) The pattern form is much more flexible, which doesn't matter in this
>     case as you've stated it but matters very much in other
>     situations... like if you wanted the .o to go into a different
>     directory for example.

Good point, I had always been wondering how this is being done, but
never succeeded doing so. Therefore my java makefile is really dumb,
like this:

${CLASSFDIR}/AdvReader.class: AdvReader.java
        javac -d ${CLASSFDIR} AdvReader.java

${CLASSFDIR}/DbHandler.class: DbHandler.java
        javac -d ${CLASSFDIR} DbHandler.java

${CLASSFDIR}/Token.class: Token.java
        javac -d ${CLASSFDIR} Token.java

...

Can you show me how to do it with the pattern rule? thanks!

PS. I tried 
${CLASSFDIR}/%.class: %.java

and it didn't seem to work. Can't remember why tho.

-- 
Tong (remove underscore(s) to reply)
  *niX Power Tools Project: http://xpt.sourceforge.net/
  http://members.xoom.com/suntong001/
  - All free contribution & collection

In article <sa8vgmls6pf.fsf@sun_tong_001.personal.yahoo.com>,
 * Tong * <sun_tong_001@yahoo.com> writes:
>${CLASSFDIR}/AdvReader.class: AdvReader.java
>        javac -d ${CLASSFDIR} AdvReader.java
>
>${CLASSFDIR}/DbHandler.class: DbHandler.java
>        javac -d ${CLASSFDIR} DbHandler.java
>
>${CLASSFDIR}/Token.class: Token.java
>        javac -d ${CLASSFDIR} Token.java

${CLASSFDIR}/%.class: %.java
        javac -d ${CLASSFDIR} $<

>PS. I tried 
>${CLASSFDIR}/%.class: %.java
>
>and it didn't seem to work. Can't remember why tho.

Well, we certainly can't figure it out either, if that's all the
information you provide....

jik@kamens.brookline.ma.us (Jonathan Kamens) writes:

> ${CLASSFDIR}/%.class: %.java
>         javac -d ${CLASSFDIR} $<

Thanks.

> >PS. I tried 
> >${CLASSFDIR}/%.class: %.java
> >
> >and it didn't seem to work. Can't remember why tho.
> 
> Well, we certainly can't figure it out either, if that's all the
> information you provide....

Oh, at last I recalled why it failed. It has nothing to do with the
OP though. It is really a java issue -- The above will not work if
the java program belongs to a package. The generated .class file
will not be under ${CLASSFDIR} but somewhere beneath it, causing the
make always recompile. 

Here is an example of explicit rule:

${CLASSFDIR}/knn/DbKnn.class: knn/DbKnn.java
        javac -d ${CLASSFDIR} knn/DbKnn.java

${CLASSFDIR}/knn/Knn.class: knn/Knn.java
        javac -d ${CLASSFDIR} knn/Knn.java

Any idea that can make 'make' work this way? 

-- 
Tong (remove underscore(s) to reply)
  *niX Power Tools Project: http://xpt.sourceforge.net/
  http://members.xoom.com/suntong001/
  - All free contribution & collection

In article <sa8snhiepqq.fsf_-_@sun_tong_001.personal.yahoo.com>,
 * Tong * <sun_tong_001@yahoo.com> writes:
>Here is an example of explicit rule:
>
>${CLASSFDIR}/knn/DbKnn.class: knn/DbKnn.java
>        javac -d ${CLASSFDIR} knn/DbKnn.java
>
>${CLASSFDIR}/knn/Knn.class: knn/Knn.java
>        javac -d ${CLASSFDIR} knn/Knn.java
>
>Any idea that can make 'make' work this way? 

I am not sure what the problem is.  The rule I already gave you should
work just fine:

${CLASSFDIR}/%.class: %.java
	javac -d ${CLASSFDIR} $<

Note that there's nothing special about slashes as far as '%' is
concerned -- it's a generic wildcard.  In the examples you gave above,
it would match "knn/DbKnn" the first time or "knn/Knn" the second time.

Perhaps there's something wrong with your example?

jik@kamens.brookline.ma.us (Jonathan Kamens) writes:

> Perhaps there's something wrong with your example?

No, there was something wrong in my mind -- the doubt that how
powerful the make could be, and your explanation has clear it
away. :-) thanks. 

-- 
Tong (remove underscore(s) to reply)
  *niX Power Tools Project: http://xpt.sourceforge.net/
  http://members.xoom.com/suntong001/
  - All free contribution & collection

Make doesn't always like directories (and changing to them).  It is much easier
to create a makefile for each directory, and then write one 'master' makefile
that calls the others (called a recursive makefile; check the O'Reilly book).

Also, did you provide a list of targets?  You may want to add a macro, such as
${CLASSES} in this example:

#Begin makefile
CLASSES = DbKnn.class \
Knn.class

all : ${CLASSES}

%.class : %.java
javac $?
#End makefile

Now you only have to add the class name to the ${CLASSES} macro for each new
class.  IF you want to get fancy, jar the classes using the same technique.

GoodLuck!!

-Brandon



In article <9fc4e2$cko$1@jik.kamens.brookline.ma.us>, Jonathan Kamens says...
>
>In article <sa8snhiepqq.fsf_-_@sun_tong_001.personal.yahoo.com>,
> * Tong * <sun_tong_001@yahoo.com> writes:
>>Here is an example of explicit rule:
>>
>>${CLASSFDIR}/knn/DbKnn.class: knn/DbKnn.java
>>        javac -d ${CLASSFDIR} knn/DbKnn.java
>>
>>${CLASSFDIR}/knn/Knn.class: knn/Knn.java
>>        javac -d ${CLASSFDIR} knn/Knn.java
>>
>>Any idea that can make 'make' work this way? 
>
>I am not sure what the problem is.  The rule I already gave you should
>work just fine:
>
>${CLASSFDIR}/%.class: %.java
>	javac -d ${CLASSFDIR} $<
>
>Note that there's nothing special about slashes as far as '%' is
>concerned -- it's a generic wildcard.  In the examples you gave above,
>it would match "knn/DbKnn" the first time or "knn/Knn" the second time.
>
>Perhaps there's something wrong with your example?

In article <L1aT6.999$SQ2.49646@www.newsranger.com>,
 brinkleybw@hotmail.com writes:
>Make doesn't always like directories (and changing to them).  It is much easier
>to create a makefile for each directory, and then write one 'master' makefile
>that calls the others (called a recursive makefile; check the O'Reilly book).

There are times when recursive Makefiles are appropriate, but I don't
see why this is one of them.  It's prefectly reasonable to have a
single Makefile build all of the class files in a directory hierarchy. 
You just have to understand Make well enough to write all the rules
properly.

In article <9fje0l$rdi$2@jik.kamens.brookline.ma.us>, Jonathan Kamens says...
>
>In article <L1aT6.999$SQ2.49646@www.newsranger.com>,
> brinkleybw@hotmail.com writes:
>>Make doesn't always like directories (and changing to them).  It is much easier
>>to create a makefile for each directory, and then write one 'master' makefile
>>that calls the others (called a recursive makefile; check the O'Reilly book).
>
>There are times when recursive Makefiles are appropriate, but I don't
>see why this is one of them.  It's prefectly reasonable to have a
>single Makefile build all of the class files in a directory hierarchy. 
>You just have to understand Make well enough to write all the rules
>properly.


Unless, of course, you want to make each package completely independent,
including the build process.  That way you can reuse makefiles too!

cheers
-Brandon