> SRC=*.java
> DEST=cocoon.jar
>
> OBJ=${SRC:.java=.class}
>
> .class.java:
> $(JAVA) $(JAVA_FLAGS) $<
>
> $(DEST): $(OBJ)
> $(JAR) $(JAR_FLAGS) $(OBJ)
>
> clean:
> rm -f $(OBJ) $(DEST)
First of all, we want .class files in a different directory than java.
So you should have:
${CLASSES}/${PACKAGE}/%.class: ${SRCDIR}/${PACKAGE}/%.java
(cd ${SRCDIR}/${PACKAGE}; ${JAVAC} ${notdir $<})
Where classes is the destination dir, and srcdir is where you keep sources.
What if you want multiple packages? Well, you'll need a bit more tricks.
I agree with you that makefiles are more powerfull and most developers
should know how to write makefiles.
My first reaction to ant was to rewrite tomcat ant-files to make.
I don't want to learn yet another new tool.
Then I wanted to create a script to convert all antfiles to Makefile.
And I tried to use XSL for that - since ANT is XML, it seemed
easier than perl.
And then I saw the light :-)
You need a lot of experience with Make in order to create a good makefile.
In most projects I worked, Makefiles are really, really complex and I don't
think you can find 2 projects to use the same Makefile style.
Even if you worked 4-5 years with Make, imake, makemaker - you still
need to guess what each include does, and you still have to do very dirty
tricks to compile on Windows. ( substitute / with \, ; and :).
Ant is not as powerfull, but it is more declarative - you don't have
10 ways to compile java, you havecopydir instead of (ifdef win COPY=xcopy
else COPY=cp -r ).
It should be easy to write a XSL to translate from antfile to makefile,
and you can put all your knowledge about make in it - and other
will probably contribute other tricks - at least the style will be
consistent,
and it will be reusable in other places.
I don't think anyone love to write Makefiles for every project, and
understanding other Makefiles is just a bit easier than reading Perl.
( and I love both Perl and Makefile ! )
Costin
