You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Paul Jimenez <pj...@place.org> on 2000/11/02 09:23:58 UTC

Ant & C?

How easy is it to use Ant to compile and link C programs?  libraries?
I'm looking for examples of how this is done before I decide to try it
out in a production environment.  For real fun, a Makefile-to-Ant.xml
converter would go a long way toward getting Ant accepted for real
amounts of use.

 --pj

Bones Heal / Chicks dig scards / Pain is temporary / Glory is forever

Re: Ant & C?

Posted by Richard Beton <ri...@roke.co.uk>.
Stefan Bodewig wrote:

> Richard Beton <ri...@roke.co.uk> wrote:
>
> > I found that there is an undocumented 'update' task to detect file
> > dependencies.
>
> I think you are referring to the uptodate task, which should be
> documented, let me see,
> <http://jakarta.apache.org/ant/jakarta-ant/docs/index.html#uptodate>.

Yes, sorry. Typo. Also I just noticed uptodate *is* documented in Ant1.2. I missed that earlier (although I had found
the task!) My mishtake.

Rick




Re: Ant & C?

Posted by Stefan Bodewig <bo...@bost.de>.
Richard Beton <ri...@roke.co.uk> wrote:

> I found that there is an undocumented 'update' task to detect file
> dependencies.

I think you are referring to the uptodate task, which should be
documented, let me see,
<http://jakarta.apache.org/ant/jakarta-ant/docs/index.html#uptodate>.

Hope we will have something better suited in Ant rather soon (working
hard to get some time to write some code). Of course a <cc> or <gcc>
would be greatly appreciated.

Stefan

Re: Javah Task

Posted by Stefan Bodewig <bo...@bost.de>.
Thanks for your contribution Richard, it usually takes a little time
until one of us committers finds time to review a task, comment on it
and finally maybe incorporate it into Ant.

Richard Beton <ri...@roke.co.uk> wrote:

> Also, note that unlike the javac task, javah does not use reflection
> to call the com.tools constructor, but simply uses the 'new'
> operator.

If we'd want to leave it that way, it would become an optional task
that requires JDK 1.2+, which might be perfectly OK as it doesn't
support JDK 1.1 style JNI. At least this is how I understand your
description.

> Therefore, when the verbose flag is passed to javah, text output
> goes to standard output rather than via the ant logging stream.

Which means it needs to be redirected, see the handling of
System.out/.err in <java> or <javac> when using the modern compiler.

Stefan

Re: Javah Task

Posted by Stefan Bodewig <bo...@apache.org>.
Richard Beton <ri...@roke.co.uk> wrote:

> This javah task has been tested against JDK1.3 and JDK1.2 (new and
> old JNI formats). I don't think it works with JDK1.1 or
> JDK1.0.

No it doesn't, therefore I've moved the task to optional (and it will
be conditionally compiled on jdk1.2+).

> JDK1.1 tools appear not to be pure Java, but rather binary
> executables.

I think you are right here - if anybody feels so inclined and submits
code to invoke binaries for javah as well, we could make the package
complete.

Almost forgot the usual "please submit documentation".

Thanks

        Stefan

Javah Task

Posted by Richard Beton <ri...@roke.co.uk>.
Stefan Bodewig wrote:

> Richard Beton <ri...@roke.co.uk> wrote:
>
> > I now have a javah task. Who might I send it to for inclusion in
> > future versions of Ant?
>
> ant-dev@jakarta.apache.org is the canonical place for patches and code
> contributions.

Please find new javah attached. It was based on the javac task. I have
commented out the extdirs stuff, because I was not quite sure what was
needed. Also, note that unlike the javac task, javah does not use
reflection to call the com.tools constructor, but simply uses the 'new'
operator. Therefore, when the verbose flag is passed to javah, text output
goes to standard output rather than via the ant logging stream.

This javah task has been tested against JDK1.3 and JDK1.2 (new and old JNI
formats). I don't think it works with JDK1.1 or JDK1.0. JDK1.1 tools
appear not to be pure Java, but rather binary executables.

Rick



Re: Ant & C?

Posted by Stefan Bodewig <bo...@bost.de>.
Richard Beton <ri...@roke.co.uk> wrote:

> I now have a javah task. Who might I send it to for inclusion in
> future versions of Ant?

ant-dev@jakarta.apache.org is the canonical place for patches and code
contributions.

Stefan

Re: Ant & C?

Posted by Richard Beton <ri...@roke.co.uk>.
James Duncan Davidson wrote:

> JNI and cc like tasks are something that are needed for sure. This is
> something that needs to be looked at for Ant 2.0

I now have a javah task. Who might I send it to for inclusion in future versions
of Ant?

Rick



Re: Ant & C?

Posted by James Duncan Davidson <du...@x180.com>.
On 11/13/00 2:04 AM, "Richard Beton" <ri...@roke.co.uk> wrote:

> I noticed some difficulty in writing makefile-like ant buildfiles,
> particularly for compiling some JNI native C in the
> case I was working with.

JNI and cc like tasks are something that are needed for sure. This is
something that needs to be looked at for Ant 2.0

-- 
James Duncan Davidson                                        duncan@x180.com
                                                                  !try; do()


Re: Ant & C?

Posted by Richard Beton <ri...@roke.co.uk>.
Paul Jimenez wrote:

> How easy is it to use Ant to compile and link C programs?  libraries?
> I'm looking for examples of how this is done before I decide to try it
> out in a production environment.  For real fun, a Makefile-to-Ant.xml
> converter would go a long way toward getting Ant accepted for real
> amounts of use.

I noticed some difficulty in writing makefile-like ant buildfiles, particularly for compiling some JNI native C in the
case I was working with.

I found that there is an undocumented 'update' task to detect file dependencies. It works fine, but I ended up with a
buildfile that is far more complex than the equivalent makefile. Surely Ant ain't gonna be beaten by Make! C'mon guys!

What I needed for my specific application is a 'gcc' task. Is anyone writing one? It's an obvious candidate to be a
built-in task.

More generally, Ant would benefit from a modified version of the 'update' task as a predicate to any other task, i.e.
like 'if' and 'unless'. Then it would be possible to generate target file a.o from a.c iff a.c had changed. Hmmm, maybe
this is asking too much: it opens a can of worms on dependency checking that is better addressed through the
implementation of specific Ant tasks (gcc, ld, etc). This is because makefiles usually have a load of header-file
dependencies (assuming the author is thorough).


Rick