You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Adam Murdoch <ad...@yahoo.com> on 2001/06/25 09:52:32 UTC
proposed C++ support
Hi,
Last week, a couple of tasks were submitted to ant-dev, for adding C/C++
support to ant. One proposal was from Mark Russell, another from myself.
After a bit of discussion and some helpful suggestions from various ant-dev
people, we've combined what we feel are the best features from both
proposals into a single proposal. Attached are the user docs describing
what the new tasks will do.
Briefly, we're planning to add two new tasks and some supporting data-types.
The main task is called <cc>. It compiles and links a set of C/C++ source
files into an executable, a shared library (DLL), or a static library. It
takes care of things like header-file dependencies, and platform-specific
naming coventions.
The second task is called <cclink>. It is a pared-down version of <cc>
which only does linking. I haven't attached the doc for it. Usage will be
the same as <cc>.
What we'd like from the ant-user folks is some feedback. Have a read and
let us know what you think.
Adam
Re: proposed C++ support
Posted by Glenn McAllister <gl...@somanetworks.com>.
Peter Donald wrote:
> Hi,
>
> I have replied to this on ant-dev as discussion should probably go there
> instead ;)
Which is where most of the discussion already was. Adam was simply trying
to make other Ant users aware that such a project was underway and that he
wanted more feedback than he was currently getting in ant-dev.
Glenn McAllister
SOMA Networks, Inc.
Re: proposed C++ support
Posted by Stefan Bodewig <bo...@apache.org>.
Mark A. Russell <ma...@csgsystems.com> wrote:
> Actually we wanted to put it in ant-user on purpose. At this point
> we want comments from the user community.
Yep, we need some non ant-dev insight here, as most people on ant-dev
seem to be involved in Java only projects.
Stefan
RE: proposed C++ support
Posted by Mark A Russell <ma...@csgsystems.com>.
Actually we wanted to put it in ant-user on purpose. At this point we want
comments from the user community. Anything relating to the actual code of
course can be done in ant-dev.
Mark A Russell
NextGen Software Engineer
CSG Systems, Inc.
E-Mail: mark_russell@csgsystems.com
-----Original Message-----
From: Peter Donald [mailto:donaldp@apache.org]
Sent: Monday, June 25, 2001 4:24 AM
To: ant-user@jakarta.apache.org
Subject: Re: proposed C++ support
Hi,
I have replied to this on ant-dev as discussion should probably go there
instead ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: proposed C++ support
Posted by Peter Donald <do...@apache.org>.
Hi,
I have replied to this on ant-dev as discussion should probably go there
instead ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: proposed C++ support
Posted by Glenn McAllister <gl...@somanetworks.com>.
"Larry V. Streepy, Jr." wrote:
> So, what's the chance that these additions could be made to work with
> the released version 1.3?
From my understanding, the intent is to do this for the 1.x line (so you will
next see it officially (hopefully) in 1.4) and simply port it to Ant 2 when the
time is right.
Glenn McAllister
SOMA Networks, Inc.
Re: proposed C++ support
Posted by "Larry V. Streepy, Jr." <st...@healthlanguage.com>.
I would find this addition EXTREMELY useful. I have a small portion of
my project which is non-java, and I end up using Ant to invoke make to
build that portion (YUK). It is mainly the generation of a shared
library of JNI stuff. The existing javah task when added to the
proposed tasks looks as though it would allow me to manage the whole
thing in my Ant framework. Very nice.
So, what's the chance that these additions could be made to work with
the released version 1.3?
Thanks.
Adam Murdoch wrote:
>
> Hi,
>
> Last week, a couple of tasks were submitted to ant-dev, for adding C/C++
> support to ant. One proposal was from Mark Russell, another from myself.
>
> After a bit of discussion and some helpful suggestions from various ant-dev
> people, we've combined what we feel are the best features from both
> proposals into a single proposal. Attached are the user docs describing
> what the new tasks will do.
>
> Briefly, we're planning to add two new tasks and some supporting data-types.
>
> The main task is called <cc>. It compiles and links a set of C/C++ source
> files into an executable, a shared library (DLL), or a static library. It
> takes care of things like header-file dependencies, and platform-specific
> naming coventions.
>
> The second task is called <cclink>. It is a pared-down version of <cc>
> which only does linking. I haven't attached the doc for it. Usage will be
> the same as <cc>.
>
> What we'd like from the ant-user folks is some feedback. Have a read and
> let us know what you think.
>
> Adam
>
> ------------------------------------------------------------------------
> Name: cc.html
> cc.html Type: Hypertext Markup Language (text/html)
> Encoding: quoted-printable
>
> Name: defineset.html
> defineset.html Type: Hypertext Markup Language (text/html)
> Encoding: quoted-printable
>
> Name: libraryset.html
> libraryset.html Type: Hypertext Markup Language (text/html)
> Encoding: quoted-printable
--
Larry V. Streepy, Jr.
Chief Technical Officer and VP of Engineering
Health Language, Inc. -- "We speak the language of healthcare"
970/626-5028 (office) mailto:streepy@healthlanguage.com
970/626-4425 (fax) http://www.healthlanguage.com
RE: proposed C++ support
Posted by Mark A Russell <ma...@csgsystems.com>.
The reason we decided to do it this way was to provide the most flexability.
Any developer who wishes to can use the single task OR he can use the CC
task to do just the compile, and then use the cclink task to do the link
part.
I see no reason that we can't make the cache dir configurable.
Mark A Russell
NextGen Software Engineer
CSG Systems, Inc.
E-Mail: mark_russell@csgsystems.com
-----Original Message-----
From: Peter Donald [mailto:donaldp@apache.org]
Sent: Monday, June 25, 2001 4:35 AM
To: ant-dev@jakarta.apache.org
Subject: Re: proposed C++ support
Hi,
On Mon, 25 Jun 2001 17:52, Adam Murdoch wrote:
> Last week, a couple of tasks were submitted to ant-dev, for adding C/C++
> support to ant. One proposal was from Mark Russell, another from myself.
>
> After a bit of discussion and some helpful suggestions from various
ant-dev
> people, we've combined what we feel are the best features from both
> proposals into a single proposal.
Excellent!
> The main task is called <cc>. It compiles and links a set of C/C++ source
> files into an executable, a shared library (DLL), or a static library. It
> takes care of things like header-file dependencies, and platform-specific
> naming coventions.
I am not sure I like the idea of combining these two stages. There is a
couple of reasons, mainly as it is different from standard use case and it
is
different from javac style support. I just browsed through all my own
personal native code packages and they all do compilation and "linking" in
separate sweeps.
Also doing it in one task is different from how javac works. For instance,
javac just does compilation. Aggregation of all the .class files into
different output archives (ie jar/zip/ear/war etc) is done via a separate
task. Considering that executable, static and dynamic libraries are just
archives of object code (anyone remember the pain of the ar tool? ;-]) I
don't think we should break this pattern. It could also lead to task
becoming
quite large.
Also would it be possible to make the cache directory for dependency
information configurable.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: proposed C++ support
Posted by Peter Donald <do...@apache.org>.
Hi,
On Mon, 25 Jun 2001 17:52, Adam Murdoch wrote:
> Last week, a couple of tasks were submitted to ant-dev, for adding C/C++
> support to ant. One proposal was from Mark Russell, another from myself.
>
> After a bit of discussion and some helpful suggestions from various ant-dev
> people, we've combined what we feel are the best features from both
> proposals into a single proposal.
Excellent!
> The main task is called <cc>. It compiles and links a set of C/C++ source
> files into an executable, a shared library (DLL), or a static library. It
> takes care of things like header-file dependencies, and platform-specific
> naming coventions.
I am not sure I like the idea of combining these two stages. There is a
couple of reasons, mainly as it is different from standard use case and it is
different from javac style support. I just browsed through all my own
personal native code packages and they all do compilation and "linking" in
separate sweeps.
Also doing it in one task is different from how javac works. For instance,
javac just does compilation. Aggregation of all the .class files into
different output archives (ie jar/zip/ear/war etc) is done via a separate
task. Considering that executable, static and dynamic libraries are just
archives of object code (anyone remember the pain of the ar tool? ;-]) I
don't think we should break this pattern. It could also lead to task becoming
quite large.
Also would it be possible to make the cache directory for dependency
information configurable.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: proposed C++ support
Posted by Stefan Bodewig <bo...@apache.org>.
Michael Twomey <mi...@ireland.sun.com> wrote:
> The other option would be to create a task which evaluated the
> output of *-config and created a set of properties from it. Hmm..
Peter Vogel has submitted such a task (I think it's a patch to the
existing <exec>) to ant-dev a few weeks ago - you should be able to
pick it from the archives.
Stefan
Re: proposed C++ support
Posted by Michael Twomey <mi...@ireland.sun.com>.
Hmm, I tried this and it doesn't seem to work due to the funky way
backticks evaluation usually works in shells. I tried the following and
got the following output :
$ cat build.xml
<?xml version="1.0" ?>
<project name="Template" default="printhelp" basedir=".">
<!-- prints out help -->
<target name="printhelp" description="Prints out usage help">
<echo>Usage: ant -Dparameter=blah</echo>
<exec executable="/bin/sh">
<arg value="-c" />
<arg value="echo `gnome-config --cflags` -o somefile.o somefile.c" />
</exec>
</target>
</project>
$ ant -verbose
Ant version 1.3 compiled on March 2 2001
Buildfile: build.xml
Detected Java Version: 1.2
Detected OS: SunOS
parsing buildfile /scratch/mick/AntTest/build.xml with URI =
file:/scratch/mick/AntTest/build.xml
Project base dir set to: /scratch/mick/AntTest
Build sequence for target `printhelp' is [printhelp]
Complete build sequence is [printhelp]
printhelp:
[echo] Usage: ant -Dparameter=blah
[exec] Myos = SunOS
[exec] /bin/sh -c "echo `gnome-config --cflags` -o somefile.o
somefile.c"
[exec] -o somefile.o somefile.c
BUILD SUCCESSFUL
Total time: 2 seconds
Notice that the part contained within the backticks has dissappeared.
I'll poke around and see if I've missed something obvious (from my
experience of shells there is usually a 20 line hack to get around these
problems :)
The other option would be to create a task which evaluated the output of
*-config and created a set of properties from it. Hmm..
thanks,
mick
Stefan Bodewig wrote:
> Michael Twomey <mi...@ireland.sun.com> wrote:
>
>
>>Usually these are invoked using backticks from the compiler command
>>line (e.g. 'gcc `gnome-config --cflags` -o somefile.o somefile.c')
>>but this never seemed to work for me in Ant when I tried passing
>>them as parameters.
>>
>
> It is the shell that is expanding the backticks magic, doing something
> like
>
> <exec executable="/bin/sh">
> <arg value="-c" />
> <arg value="gcc `gnome-config --cflags` -o somefile.o somefile.c" />
> </exec>
>
> should work (untested).
>
> Stefan
>
--
Michael Twomey
These opinions are my own and do not represent Sun unless otherwise stated.
Sun Microsystems, Dublin, 8199164, x19164
"Fly my little Makefiles! Fly!"
Re: proposed C++ support
Posted by Stefan Bodewig <bo...@apache.org>.
Michael Twomey <mi...@ireland.sun.com> wrote:
> Usually these are invoked using backticks from the compiler command
> line (e.g. 'gcc `gnome-config --cflags` -o somefile.o somefile.c')
> but this never seemed to work for me in Ant when I tried passing
> them as parameters.
It is the shell that is expanding the backticks magic, doing something
like
<exec executable="/bin/sh">
<arg value="-c" />
<arg value="gcc `gnome-config --cflags` -o somefile.o somefile.c" />
</exec>
should work (untested).
Stefan
Re: proposed C++ support
Posted by "Larry V. Streepy, Jr." <st...@healthlanguage.com>.
You could use the patch posted by Peter Vogel to exec a command and
place the output into a property. Then, you can use that property as
the value for a "compilerarg" attribute on the proposed "cc" task.
I think that would solve the problem.
Michael Twomey wrote:
>
> Yeah, I guessed it wasn't going to be easy (I had a look at it once in
> an aborted attempt to write my own cc task). I don't expect it to appear
> any time soon but I though I would mention it 'cos it would be another
> step on the way to making cc files as easy to compile as java in ant.
>
> Keep up the good work, after my attempt I can appreciate the
> difficulties involved (C/C++ is so painful when compared to java from a
> compiler's point of view :)
>
> thanks,
> mick
>
> Mark A Russell wrote:
>
> > Hmm, not an easy request. The problem come in because it ends up being a
> > Runtime.exec() call, which isn't really the commandline. So to support this
> > you'd basically need to make to exec calls. One for the gnome-config
> > capturing its output into a buffer. Then the second would be the actual gcc
> > call where you'd give the captured stuff from the previous call to it.
> >
> > This may be an instance where you could use exec call to execute the
> > gnome-config --cflags using exec's output file. Then read the file into a
> > buffer.
> >
> > As it stands now I don't see a way to do this with ant. I will consider
> > adding something like this into the cc task but it won't be in the first
> > rev. It would probably be something along the line of an attribute that
> > would take a file that holds flags for the compiler. I'll discuss this one
> > with Adam, but like I said it most likely wont be in the first rev.
> >
> > Mark A Russell
> > NextGen Software Engineer
> > CSG Systems, Inc.
> > E-Mail: mark_russell@csgsystems.com
> >
> >
> > -----Original Message-----
> > From: Michael Twomey [mailto:michael.twomey@ireland.sun.com]
> > Sent: Monday, June 25, 2001 9:22 AM
> > To: ant-user@jakarta.apache.org
> > Subject: Re: proposed C++ support
> >
> >
> > Hi,
> > looks good. While I can't comment on how it handles fiddly dependancies
> > until I try it my one request would be some means of handling the
> > *-config scripts common in GNU projects (e.g. `gnome-config --libs
> > --cflags`). Usually these are invoked using backticks from the compiler
> > command line (e.g. 'gcc `gnome-config --cflags` -o somefile.o
> > somefile.c') but this never seemed to work for me in Ant when I tried
> > passing them as parameters.
> >
> > Some means of supporting this would reduce the work writing ant files
> > dramatically for GNU projects. If I've missed something blindingly
> > obvious in Ant that handles this please point it out to me.
> >
> > thanks,
> > mick
> >
> > Adam Murdoch wrote:
> >
> >
> >>Hi,
> >>
> >>Last week, a couple of tasks were submitted to ant-dev, for adding C/C++
> >>support to ant. One proposal was from Mark Russell, another from myself.
> >>
> >>After a bit of discussion and some helpful suggestions from various
> >>
> > ant-dev
> >
> >>people, we've combined what we feel are the best features from both
> >>proposals into a single proposal. Attached are the user docs describing
> >>what the new tasks will do.
> >>
> >>Briefly, we're planning to add two new tasks and some supporting
> >>
> > data-types.
> >
> >>The main task is called <cc>. It compiles and links a set of C/C++ source
> >>files into an executable, a shared library (DLL), or a static library. It
> >>takes care of things like header-file dependencies, and platform-specific
> >>naming coventions.
> >>
> >>The second task is called <cclink>. It is a pared-down version of <cc>
> >>which only does linking. I haven't attached the doc for it. Usage will
> >>
> > be
> >
> >>the same as <cc>.
> >>
> >>What we'd like from the ant-user folks is some feedback. Have a read and
> >>let us know what you think.
> >>
> >>
> >>Adam
> >>
> >>
> >>------------------------------------------------------------------------
> >>
> >>
> >> CC
> >>
> >>
> >> Description
> >>
> >>Compiles and links a set of C and C++ source files into an executable,
> >>shared library (DLL), or static library.
> >>
> >>The CC task invokes the C/C++ compiler on each out-of-date source file.
> >>Following successful compilation of the source files, the CC task
> >>invokes the linker to produce the output file. Linking may be disabled
> >>using the |link| attribute.
> >>
> >>You specify the task's input files using one or more nested |<fileset>|
> >>elements. The |sourcedir| attribute can also be used as a shortcut. It
> >>creates an implicit fileset that recursively includes all files in a
> >>particular directory.
> >>
> >>
> >> Compiling
> >>
> >>The CC task only attempts to compile files which end in the following
> >>suffixes: |.c|, |.cc|, |.cxx|, |.cpp, .c++|. Input files that are not
> >>recognized as source files are passed directly to the linker.
> >>
> >>The CC task tracks the dependencies between the source files, and the
> >>header files that they include. It recompiles a source file if any of
> >>the header files that it includes changes. To do this, the CC task
> >>parses the source and header files when they change, and maintains a
> >>cache of the parsed information in |/basedir//.c_parser_cache|.
> >>
> >>To locate header files, the CC task searches the directories specified
> >>by nested |<includepath>| elements. It does not search the directories
> >>specified by nested |<sysincludepath>| elements. This way, you can
> >>reduce the amount of parsing the task performs by putting header files
> >>which are unlikely to change, such as those from external libraries, in
> >>|<sysincludepath>| elements.
> >>
> >>
> >> Linking
> >>
> >>The linker is only invoked if the output file is out-of-date. The CC
> >>task determines if the linker needs to be invoked by comparing the
> >>last-modified time of the output file against that of the object files
> >>and libraries included in the link. Incremental linking is used where
> >>available.
> >>
> >>Static or shared libraries can be included in the link by including them
> >>in nested |<libraryset>| elements, or in the input file set.
> >>
> >>
> >> Supported Compilers
> >>
> >>The CC task only handles a small number of different compilers and
> >>linkers, listed below. You can control which compiler to use with the
> >>|compiler| attribute. For example, on Windows, where Visual C++ and GCC
> >>are both supported, set |compiler="vc"| to use the Visual C++ compiler
> >>and linker.
> >>
> >>The table below lists the supported compilers, and lists which
> >>command-line tools need to be in your PATH to use the compiler.
> >>
> >>*Name* *Description* *Platforms* *Required Tools*
> >>gcc The GNU Compiler Collection (GCC).
> >>
> >>This is the default compiler for all platforms. This task works with the
> >>MinGW <http://www.mingw.org/> toolset on Windows, and may also work with
> >>the Cygwin toolset.
> >>
> >>UNIX, Windows |gcc, ar|
> >>vc Microsoft Visual C++.
> >>
> >>This task works with version 6.0, may work with other versions.
> >>
> >>Windows |cl, link, lib|
> >>xlc_r IBM xlC_r Compiler. AIX |xlC_r, ar|
> >>sunstudio Sun Workshop.
> >>
> >>This task works with version 4.2, may work with other versions.
> >>
> >>Solaris |CC, ar|
> >>
> >>
> >> Name Mapping
> >>
> >>The CC task takes care of mapping file names, according to the naming
> >>convention for the OS platform that the build is running on. The table
> >>below describes the mappings for the various platforms and file types.
> >>In this table, /basename/ refers to the file name, minus the directory
> >>path and the extension.
> >>
> >>*Operating System* *Executable File* *Object File* *Shared Library*
> >>*Static Library*
> >>Windows /basename/.exe /basename/.obj /basename/.dll /basename/.lib
> >>Other /basename/ /basename/.o lib/basename/.so lib/basename/.a
> >>
> >>
> >> See Also
> >>
> >>The CCLink <cclink.html> task, the DefineSet <defineset.html> data type,
> >>and the LibrarySet <libraryset.html> data type.
> >>
> >>
> >> Parameters
> >>
> >>*Attribute* *Description* *Required*
> >>compiler The compiler to use. See above for the list of supported
> >>compilers. If not specified will default to GCC No
> >>debug Enables the generation of debug information in the output files. No
> >>link The type of output file to produce. Possible values are:
> >>
> >>|none|
> >>Does not produce an output file.|executable|
> >>Produces an executable file.|shared|
> >>Produces a shared library.|static|
> >>Produces a static library.
> >>
> >>Default is |executable|. No
> >>objdestdir The directory to place object files. Yes
> >>outfile The name of the output file. The CC task maps this file name
> >>depending on the output type and OS platform the build is running on
> >>(see above). Yes, if |link| is not set to |none|
> >>sourcedir The directory containing the source files. Yes, or at least
> >>one nested |<fileset>| element.
> >>
> >>
> >> Parameters specified as nested elements
> >>
> >>
> >> compilerarg
> >>
> >>An additional command-line argument to pass to the compiler. There may
> >>be more than one nested |<compilerarg>| element.
> >>
> >>
> >> defineset
> >>
> >>A set of preprocessor macros to define and/or undefine. See DefineSet
> >><defineset.html> for more details. There may be more than one nested
> >>|<defineset>| element.
> >>
> >>
> >> fileset
> >>
> >>A Fileset that specifies the input files for the task. Files that are
> >>recognised as C or C++ source files are passed to the compiler. All
> >>other files are passed directly to the linker. There may be more than
> >>one nested |<fileset>| element.
> >>
> >>
> >> includepath
> >>
> >>A Path that specifies the directories to use when searching for header
> >>files. This path is passed to the compiler, and is used by the CC task
> >>when it is performing header file dependency checking. There may be more
> >>than one nested |<includepath>| element.
> >>
> >>
> >> libpath
> >>
> >>A Path that specifies the directories to use when searching for the
> >>libraries listed in the |libs| attribute. There may be more than one
> >>nested |<libpath>| element.
> >>
> >>
> >> linkerarg
> >>
> >>A command-line argument to pass to the linker. There may be more than
> >>one nested |<linkerarg>| element.
> >>
> >>
> >> sysincludepath
> >>
> >>A Path that specifies the directories to use when searching for system
> >>header files. This path is passed to the compiler. It is /not/ used by
> >>the CC task when it is performing header file dependency checking. There
> >>may be more than one nested |<sysincludepath>| element.
> >>
> >>
> >> Examples
> >>
> >>The example below compiles all the source files under the |src|
> >>directory, and links them into |build/bin/someapp|
> >>(|build\bin\someapp.exe|). It places the object files in the |build/obj|
> >>directory.
> >>
> >><cc sourcedir="src" outfile="build/bin/someapp" objdestdir="build/obj" />
> >>
> >>The example below builds an executable from source files in two
> >>different directories. It uses header files from |src/somelib|.
> >>
> >><cc outfile="build/bin/someapp" objdestdir="build/obj" >
> >> <fileset dir="src/common" />
> >> <fileset dir="src/server" />
> >> <includepath location="src/somelib" />
> >></cc>
> >>
> >>The example builds an executable, defining the preprocessor macro
> >>|SOMEDEF| during compilation.
> >>
> >><cc outfile="build/lib/someapp" objdestdir="build/obj" >
> >> <fileset dir="src" />
> >> <defineset>
> >> <define name="SOMEDEF" />
> >> </defineset>
> >></cc>
> >>
> >>The example below builds a shared library called |build/lib/libapp.so|
> >>(|build\lib\app.dll|).
> >>
> >><cc link="shared" outfile="build/lib/app" objdestdir="build/obj" >
> >> <fileset dir="src" />
> >></cc>
> >>
> >>The example builds an executable, linking against the libraries
> >>|pthread| and |dl|, and all the libraries in directory |build/lib|.
> >>
> >><cc outfile="build/lib/someapp" objdestdir="build/obj" >
> >> <fileset dir="src" />
> >> <libraryset libs="pthread, dl">
> >> <fileset dir="build/lib" />
> >> </libraryset>
> >></cc>
> >>
> >>Below is a more complete example. It uses GCC to build debug versions of
> >>a shared library, and an executable that uses the shared library.
> >>
> >><!-- Define a common set of libraries -->
> >><libraryset id="libs">
> >> <fileset dir="lib" />
> >> <fileset dir="/someotherproject/lib" />
> >></libraryset>
> >>
> >><!-- Define a common set of macros -->
> >><defineset id="defs">
> >> <define name="DEBUG" />
> >> <define name="SOMEDEF" value="1"/>
> >> <undefine name="UNWANTEDDEF" />
> >></defineset>
> >>
> >><target name="build">
> >>
> >> <!-- Build a shared library -->
> >> <cc compiler="gcc" debug="true" link="shared"
> >>
> > outfile="build/lib/somelib" objddestdir="build/obj">
> >
> >> <fileset dir="src/somelib" />
> >> <includepath location="inc" />
> >> <sysincludepath location="/someotherproject/include" />
> >> <defineset refid="defs" />
> >> <defineset define="EXTRA_DEF" />
> >> <libraryset refid="libs" />
> >> <linkerarg value="-somearg" />
> >> </cc>
> >>
> >> <!-- Build an executable -->
> >> <cc compiler="gcc" debug="true" outfile="build/lib/someapp"
> >>
> > objddestdir="build/obj">
> >
> >> <fileset dir="src/someapp" />
> >> <includepath location="inc" />
> >> <defineset refid="defs" />
> >> <libraryset refid="libs" />
> >> <libraryset>
> >> <fileset dir="build/lib" includes="*somelib*" />
> >> </libraryset>
> >> <compilerarg value="-somearg" />
> >> </cc>
> >></target>
> >>
> >>------------------------------------------------------------------------
> >>
> >>------------------------------------------------------------------------
> >>
> >>
> >> DefineSet
> >>
> >>
> >> Description
> >>
> >>A datatype that defines a set of C preprocessor macros.
> >>
> >>
> >> See Also
> >>
> >>The CC <cc.html> task.
> >>
> >>
> >> Parameters
> >>
> >>*Attribute* *Description* *Required*
> >>define A comma-separated list of preprocessor macros to define. These
> >>take the form /macro/[=/value/]. No
> >>undefine A comma-separated list of preprocessor macros to undefine. No
> >>refid A reference to another |<defineset>|. No other attributes or
> >>nested elements may be used with this attribute. No
> >>
> >>
> >> Parameters specified as nested elements
> >>
> >>
> >> define
> >>
> >>Defines a preprocessor macro. It takes the following attributes:
> >>
> >>*Attribute* *Description* *Required*
> >>name The name of the macro to define. Yes
> >>value The value to set the macro to. No
> >>
> >>
> >> undefine
> >>
> >>Undefines a preprocessor macro. It takes a single |name| attribute.
> >>
> >>
> >> Examples
> >>
> >>Below is a define set which defines two macros, |SOMEDEF| and
> >>
> > |ANOTHERDEF|.
> >
> >><defineset define="SOMEDEF, ANOTHERDEF" />
> >>
> >>Below is a define set which defines the same macros, using nested
> >>
> > elements.
> >
> >><defineset>
> >> <define name="SOMEDEF" />
> >> <define name="ANOTHERDEF" />
> >></defineset>
> >>
> >>Below is a define set which gives macro |SOMEDEF| the value 1, and
> >>undefines macro |UNWANTEDDEF|.
> >>
> >><defineset>
> >> <define name="SOMEDEF" value="1" />
> >> <undefine name="UNWANTEDDEF" />
> >></defineset>
> >>
> >>------------------------------------------------------------------------
> >>
> >>------------------------------------------------------------------------
> >>
> >>
> >> LibrarySet
> >>
> >>
> >> Description
> >>
> >>A datatype that defines a set of static and shared libraries to include
> >>when linking an output file.
> >>
> >>
> >> See Also
> >>
> >>The CC <cc.html> task.
> >>
> >>
> >> Parameters
> >>
> >>*Attribute* *Description* *Required*
> >>libs A comma-separated list of the libraries to include in the link.
> >>Names in this list should be the library's /basename/. No
> >>refid A reference to another |<libraryset>|. No other attributes or
> >>nested elements may be used with this attribute. No
> >>
> >>
> >> Parameters specified as nested elements
> >>
> >>
> >> fileset
> >>
> >>A Fileset that contains the libraries to include in the library set.
> >>There may be more than one nested |<fileset>| element.
> >>
> >>
> >> Examples
> >>
> >>The example below defines a library set that contains the libraries
> >>|pthread| and |dl|.
> >>
> >><libraryset libs="pthread, dl" />
> >>
> >>The example below defines a library set that contains all the files in
> >>|build/lib|.
> >>
> >><libraryset>
> >> <fileset dir="build/lib" />
> >></libraryset>
> >>
> >>------------------------------------------------------------------------
> >>cc.html
> >>
> >>Content-Type:
> >>
> >>text/html
> >>Content-Encoding:
> >>
> >>quoted-printable
> >>
> >>
> >>------------------------------------------------------------------------
> >>defineset.html
> >>
> >>Content-Type:
> >>
> >>text/html
> >>Content-Encoding:
> >>
> >>quoted-printable
> >>
> >>
> >>------------------------------------------------------------------------
> >>libraryset.html
> >>
> >>Content-Type:
> >>
> >>text/html
> >>Content-Encoding:
> >>
> >>quoted-printable
> >>
> >>
> >>
> >
> >
> > --
> > Michael Twomey
> > These opinions are my own and do not represent Sun unless otherwise stated.
> > Sun Microsystems, Dublin, 8199164, x19164
> > "Fly my little Makefiles! Fly!"
> >
> >
>
> --
> Michael Twomey
> These opinions are my own and do not represent Sun unless otherwise stated.
> Sun Microsystems, Dublin, 8199164, x19164
> "Fly my little Makefiles! Fly!"
--
Larry V. Streepy, Jr.
Chief Technical Officer and VP of Engineering
Health Language, Inc. -- "We speak the language of healthcare"
970/626-5028 (office) mailto:streepy@healthlanguage.com
970/626-4425 (fax) http://www.healthlanguage.com
Re: proposed C++ support
Posted by Michael Twomey <mi...@ireland.sun.com>.
Yeah, I guessed it wasn't going to be easy (I had a look at it once in
an aborted attempt to write my own cc task). I don't expect it to appear
any time soon but I though I would mention it 'cos it would be another
step on the way to making cc files as easy to compile as java in ant.
Keep up the good work, after my attempt I can appreciate the
difficulties involved (C/C++ is so painful when compared to java from a
compiler's point of view :)
thanks,
mick
Mark A Russell wrote:
> Hmm, not an easy request. The problem come in because it ends up being a
> Runtime.exec() call, which isn't really the commandline. So to support this
> you'd basically need to make to exec calls. One for the gnome-config
> capturing its output into a buffer. Then the second would be the actual gcc
> call where you'd give the captured stuff from the previous call to it.
>
> This may be an instance where you could use exec call to execute the
> gnome-config --cflags using exec's output file. Then read the file into a
> buffer.
>
> As it stands now I don't see a way to do this with ant. I will consider
> adding something like this into the cc task but it won't be in the first
> rev. It would probably be something along the line of an attribute that
> would take a file that holds flags for the compiler. I'll discuss this one
> with Adam, but like I said it most likely wont be in the first rev.
>
> Mark A Russell
> NextGen Software Engineer
> CSG Systems, Inc.
> E-Mail: mark_russell@csgsystems.com
>
>
> -----Original Message-----
> From: Michael Twomey [mailto:michael.twomey@ireland.sun.com]
> Sent: Monday, June 25, 2001 9:22 AM
> To: ant-user@jakarta.apache.org
> Subject: Re: proposed C++ support
>
>
> Hi,
> looks good. While I can't comment on how it handles fiddly dependancies
> until I try it my one request would be some means of handling the
> *-config scripts common in GNU projects (e.g. `gnome-config --libs
> --cflags`). Usually these are invoked using backticks from the compiler
> command line (e.g. 'gcc `gnome-config --cflags` -o somefile.o
> somefile.c') but this never seemed to work for me in Ant when I tried
> passing them as parameters.
>
> Some means of supporting this would reduce the work writing ant files
> dramatically for GNU projects. If I've missed something blindingly
> obvious in Ant that handles this please point it out to me.
>
> thanks,
> mick
>
> Adam Murdoch wrote:
>
>
>>Hi,
>>
>>Last week, a couple of tasks were submitted to ant-dev, for adding C/C++
>>support to ant. One proposal was from Mark Russell, another from myself.
>>
>>After a bit of discussion and some helpful suggestions from various
>>
> ant-dev
>
>>people, we've combined what we feel are the best features from both
>>proposals into a single proposal. Attached are the user docs describing
>>what the new tasks will do.
>>
>>Briefly, we're planning to add two new tasks and some supporting
>>
> data-types.
>
>>The main task is called <cc>. It compiles and links a set of C/C++ source
>>files into an executable, a shared library (DLL), or a static library. It
>>takes care of things like header-file dependencies, and platform-specific
>>naming coventions.
>>
>>The second task is called <cclink>. It is a pared-down version of <cc>
>>which only does linking. I haven't attached the doc for it. Usage will
>>
> be
>
>>the same as <cc>.
>>
>>What we'd like from the ant-user folks is some feedback. Have a read and
>>let us know what you think.
>>
>>
>>Adam
>>
>>
>>------------------------------------------------------------------------
>>
>>
>> CC
>>
>>
>> Description
>>
>>Compiles and links a set of C and C++ source files into an executable,
>>shared library (DLL), or static library.
>>
>>The CC task invokes the C/C++ compiler on each out-of-date source file.
>>Following successful compilation of the source files, the CC task
>>invokes the linker to produce the output file. Linking may be disabled
>>using the |link| attribute.
>>
>>You specify the task's input files using one or more nested |<fileset>|
>>elements. The |sourcedir| attribute can also be used as a shortcut. It
>>creates an implicit fileset that recursively includes all files in a
>>particular directory.
>>
>>
>> Compiling
>>
>>The CC task only attempts to compile files which end in the following
>>suffixes: |.c|, |.cc|, |.cxx|, |.cpp, .c++|. Input files that are not
>>recognized as source files are passed directly to the linker.
>>
>>The CC task tracks the dependencies between the source files, and the
>>header files that they include. It recompiles a source file if any of
>>the header files that it includes changes. To do this, the CC task
>>parses the source and header files when they change, and maintains a
>>cache of the parsed information in |/basedir//.c_parser_cache|.
>>
>>To locate header files, the CC task searches the directories specified
>>by nested |<includepath>| elements. It does not search the directories
>>specified by nested |<sysincludepath>| elements. This way, you can
>>reduce the amount of parsing the task performs by putting header files
>>which are unlikely to change, such as those from external libraries, in
>>|<sysincludepath>| elements.
>>
>>
>> Linking
>>
>>The linker is only invoked if the output file is out-of-date. The CC
>>task determines if the linker needs to be invoked by comparing the
>>last-modified time of the output file against that of the object files
>>and libraries included in the link. Incremental linking is used where
>>available.
>>
>>Static or shared libraries can be included in the link by including them
>>in nested |<libraryset>| elements, or in the input file set.
>>
>>
>> Supported Compilers
>>
>>The CC task only handles a small number of different compilers and
>>linkers, listed below. You can control which compiler to use with the
>>|compiler| attribute. For example, on Windows, where Visual C++ and GCC
>>are both supported, set |compiler="vc"| to use the Visual C++ compiler
>>and linker.
>>
>>The table below lists the supported compilers, and lists which
>>command-line tools need to be in your PATH to use the compiler.
>>
>>*Name* *Description* *Platforms* *Required Tools*
>>gcc The GNU Compiler Collection (GCC).
>>
>>This is the default compiler for all platforms. This task works with the
>>MinGW <http://www.mingw.org/> toolset on Windows, and may also work with
>>the Cygwin toolset.
>>
>>UNIX, Windows |gcc, ar|
>>vc Microsoft Visual C++.
>>
>>This task works with version 6.0, may work with other versions.
>>
>>Windows |cl, link, lib|
>>xlc_r IBM xlC_r Compiler. AIX |xlC_r, ar|
>>sunstudio Sun Workshop.
>>
>>This task works with version 4.2, may work with other versions.
>>
>>Solaris |CC, ar|
>>
>>
>> Name Mapping
>>
>>The CC task takes care of mapping file names, according to the naming
>>convention for the OS platform that the build is running on. The table
>>below describes the mappings for the various platforms and file types.
>>In this table, /basename/ refers to the file name, minus the directory
>>path and the extension.
>>
>>*Operating System* *Executable File* *Object File* *Shared Library*
>>*Static Library*
>>Windows /basename/.exe /basename/.obj /basename/.dll /basename/.lib
>>Other /basename/ /basename/.o lib/basename/.so lib/basename/.a
>>
>>
>> See Also
>>
>>The CCLink <cclink.html> task, the DefineSet <defineset.html> data type,
>>and the LibrarySet <libraryset.html> data type.
>>
>>
>> Parameters
>>
>>*Attribute* *Description* *Required*
>>compiler The compiler to use. See above for the list of supported
>>compilers. If not specified will default to GCC No
>>debug Enables the generation of debug information in the output files. No
>>link The type of output file to produce. Possible values are:
>>
>>|none|
>>Does not produce an output file.|executable|
>>Produces an executable file.|shared|
>>Produces a shared library.|static|
>>Produces a static library.
>>
>>Default is |executable|. No
>>objdestdir The directory to place object files. Yes
>>outfile The name of the output file. The CC task maps this file name
>>depending on the output type and OS platform the build is running on
>>(see above). Yes, if |link| is not set to |none|
>>sourcedir The directory containing the source files. Yes, or at least
>>one nested |<fileset>| element.
>>
>>
>> Parameters specified as nested elements
>>
>>
>> compilerarg
>>
>>An additional command-line argument to pass to the compiler. There may
>>be more than one nested |<compilerarg>| element.
>>
>>
>> defineset
>>
>>A set of preprocessor macros to define and/or undefine. See DefineSet
>><defineset.html> for more details. There may be more than one nested
>>|<defineset>| element.
>>
>>
>> fileset
>>
>>A Fileset that specifies the input files for the task. Files that are
>>recognised as C or C++ source files are passed to the compiler. All
>>other files are passed directly to the linker. There may be more than
>>one nested |<fileset>| element.
>>
>>
>> includepath
>>
>>A Path that specifies the directories to use when searching for header
>>files. This path is passed to the compiler, and is used by the CC task
>>when it is performing header file dependency checking. There may be more
>>than one nested |<includepath>| element.
>>
>>
>> libpath
>>
>>A Path that specifies the directories to use when searching for the
>>libraries listed in the |libs| attribute. There may be more than one
>>nested |<libpath>| element.
>>
>>
>> linkerarg
>>
>>A command-line argument to pass to the linker. There may be more than
>>one nested |<linkerarg>| element.
>>
>>
>> sysincludepath
>>
>>A Path that specifies the directories to use when searching for system
>>header files. This path is passed to the compiler. It is /not/ used by
>>the CC task when it is performing header file dependency checking. There
>>may be more than one nested |<sysincludepath>| element.
>>
>>
>> Examples
>>
>>The example below compiles all the source files under the |src|
>>directory, and links them into |build/bin/someapp|
>>(|build\bin\someapp.exe|). It places the object files in the |build/obj|
>>directory.
>>
>><cc sourcedir="src" outfile="build/bin/someapp" objdestdir="build/obj" />
>>
>>The example below builds an executable from source files in two
>>different directories. It uses header files from |src/somelib|.
>>
>><cc outfile="build/bin/someapp" objdestdir="build/obj" >
>> <fileset dir="src/common" />
>> <fileset dir="src/server" />
>> <includepath location="src/somelib" />
>></cc>
>>
>>The example builds an executable, defining the preprocessor macro
>>|SOMEDEF| during compilation.
>>
>><cc outfile="build/lib/someapp" objdestdir="build/obj" >
>> <fileset dir="src" />
>> <defineset>
>> <define name="SOMEDEF" />
>> </defineset>
>></cc>
>>
>>The example below builds a shared library called |build/lib/libapp.so|
>>(|build\lib\app.dll|).
>>
>><cc link="shared" outfile="build/lib/app" objdestdir="build/obj" >
>> <fileset dir="src" />
>></cc>
>>
>>The example builds an executable, linking against the libraries
>>|pthread| and |dl|, and all the libraries in directory |build/lib|.
>>
>><cc outfile="build/lib/someapp" objdestdir="build/obj" >
>> <fileset dir="src" />
>> <libraryset libs="pthread, dl">
>> <fileset dir="build/lib" />
>> </libraryset>
>></cc>
>>
>>Below is a more complete example. It uses GCC to build debug versions of
>>a shared library, and an executable that uses the shared library.
>>
>><!-- Define a common set of libraries -->
>><libraryset id="libs">
>> <fileset dir="lib" />
>> <fileset dir="/someotherproject/lib" />
>></libraryset>
>>
>><!-- Define a common set of macros -->
>><defineset id="defs">
>> <define name="DEBUG" />
>> <define name="SOMEDEF" value="1"/>
>> <undefine name="UNWANTEDDEF" />
>></defineset>
>>
>><target name="build">
>>
>> <!-- Build a shared library -->
>> <cc compiler="gcc" debug="true" link="shared"
>>
> outfile="build/lib/somelib" objddestdir="build/obj">
>
>> <fileset dir="src/somelib" />
>> <includepath location="inc" />
>> <sysincludepath location="/someotherproject/include" />
>> <defineset refid="defs" />
>> <defineset define="EXTRA_DEF" />
>> <libraryset refid="libs" />
>> <linkerarg value="-somearg" />
>> </cc>
>>
>> <!-- Build an executable -->
>> <cc compiler="gcc" debug="true" outfile="build/lib/someapp"
>>
> objddestdir="build/obj">
>
>> <fileset dir="src/someapp" />
>> <includepath location="inc" />
>> <defineset refid="defs" />
>> <libraryset refid="libs" />
>> <libraryset>
>> <fileset dir="build/lib" includes="*somelib*" />
>> </libraryset>
>> <compilerarg value="-somearg" />
>> </cc>
>></target>
>>
>>------------------------------------------------------------------------
>>
>>------------------------------------------------------------------------
>>
>>
>> DefineSet
>>
>>
>> Description
>>
>>A datatype that defines a set of C preprocessor macros.
>>
>>
>> See Also
>>
>>The CC <cc.html> task.
>>
>>
>> Parameters
>>
>>*Attribute* *Description* *Required*
>>define A comma-separated list of preprocessor macros to define. These
>>take the form /macro/[=/value/]. No
>>undefine A comma-separated list of preprocessor macros to undefine. No
>>refid A reference to another |<defineset>|. No other attributes or
>>nested elements may be used with this attribute. No
>>
>>
>> Parameters specified as nested elements
>>
>>
>> define
>>
>>Defines a preprocessor macro. It takes the following attributes:
>>
>>*Attribute* *Description* *Required*
>>name The name of the macro to define. Yes
>>value The value to set the macro to. No
>>
>>
>> undefine
>>
>>Undefines a preprocessor macro. It takes a single |name| attribute.
>>
>>
>> Examples
>>
>>Below is a define set which defines two macros, |SOMEDEF| and
>>
> |ANOTHERDEF|.
>
>><defineset define="SOMEDEF, ANOTHERDEF" />
>>
>>Below is a define set which defines the same macros, using nested
>>
> elements.
>
>><defineset>
>> <define name="SOMEDEF" />
>> <define name="ANOTHERDEF" />
>></defineset>
>>
>>Below is a define set which gives macro |SOMEDEF| the value 1, and
>>undefines macro |UNWANTEDDEF|.
>>
>><defineset>
>> <define name="SOMEDEF" value="1" />
>> <undefine name="UNWANTEDDEF" />
>></defineset>
>>
>>------------------------------------------------------------------------
>>
>>------------------------------------------------------------------------
>>
>>
>> LibrarySet
>>
>>
>> Description
>>
>>A datatype that defines a set of static and shared libraries to include
>>when linking an output file.
>>
>>
>> See Also
>>
>>The CC <cc.html> task.
>>
>>
>> Parameters
>>
>>*Attribute* *Description* *Required*
>>libs A comma-separated list of the libraries to include in the link.
>>Names in this list should be the library's /basename/. No
>>refid A reference to another |<libraryset>|. No other attributes or
>>nested elements may be used with this attribute. No
>>
>>
>> Parameters specified as nested elements
>>
>>
>> fileset
>>
>>A Fileset that contains the libraries to include in the library set.
>>There may be more than one nested |<fileset>| element.
>>
>>
>> Examples
>>
>>The example below defines a library set that contains the libraries
>>|pthread| and |dl|.
>>
>><libraryset libs="pthread, dl" />
>>
>>The example below defines a library set that contains all the files in
>>|build/lib|.
>>
>><libraryset>
>> <fileset dir="build/lib" />
>></libraryset>
>>
>>------------------------------------------------------------------------
>>cc.html
>>
>>Content-Type:
>>
>>text/html
>>Content-Encoding:
>>
>>quoted-printable
>>
>>
>>------------------------------------------------------------------------
>>defineset.html
>>
>>Content-Type:
>>
>>text/html
>>Content-Encoding:
>>
>>quoted-printable
>>
>>
>>------------------------------------------------------------------------
>>libraryset.html
>>
>>Content-Type:
>>
>>text/html
>>Content-Encoding:
>>
>>quoted-printable
>>
>>
>>
>
>
> --
> Michael Twomey
> These opinions are my own and do not represent Sun unless otherwise stated.
> Sun Microsystems, Dublin, 8199164, x19164
> "Fly my little Makefiles! Fly!"
>
>
--
Michael Twomey
These opinions are my own and do not represent Sun unless otherwise stated.
Sun Microsystems, Dublin, 8199164, x19164
"Fly my little Makefiles! Fly!"
RE: proposed C++ support
Posted by Mark A Russell <ma...@csgsystems.com>.
Hmm, not an easy request. The problem come in because it ends up being a
Runtime.exec() call, which isn't really the commandline. So to support this
you'd basically need to make to exec calls. One for the gnome-config
capturing its output into a buffer. Then the second would be the actual gcc
call where you'd give the captured stuff from the previous call to it.
This may be an instance where you could use exec call to execute the
gnome-config --cflags using exec's output file. Then read the file into a
buffer.
As it stands now I don't see a way to do this with ant. I will consider
adding something like this into the cc task but it won't be in the first
rev. It would probably be something along the line of an attribute that
would take a file that holds flags for the compiler. I'll discuss this one
with Adam, but like I said it most likely wont be in the first rev.
Mark A Russell
NextGen Software Engineer
CSG Systems, Inc.
E-Mail: mark_russell@csgsystems.com
-----Original Message-----
From: Michael Twomey [mailto:michael.twomey@ireland.sun.com]
Sent: Monday, June 25, 2001 9:22 AM
To: ant-user@jakarta.apache.org
Subject: Re: proposed C++ support
Hi,
looks good. While I can't comment on how it handles fiddly dependancies
until I try it my one request would be some means of handling the
*-config scripts common in GNU projects (e.g. `gnome-config --libs
--cflags`). Usually these are invoked using backticks from the compiler
command line (e.g. 'gcc `gnome-config --cflags` -o somefile.o
somefile.c') but this never seemed to work for me in Ant when I tried
passing them as parameters.
Some means of supporting this would reduce the work writing ant files
dramatically for GNU projects. If I've missed something blindingly
obvious in Ant that handles this please point it out to me.
thanks,
mick
Adam Murdoch wrote:
> Hi,
>
> Last week, a couple of tasks were submitted to ant-dev, for adding C/C++
> support to ant. One proposal was from Mark Russell, another from myself.
>
> After a bit of discussion and some helpful suggestions from various
ant-dev
> people, we've combined what we feel are the best features from both
> proposals into a single proposal. Attached are the user docs describing
> what the new tasks will do.
>
> Briefly, we're planning to add two new tasks and some supporting
data-types.
>
> The main task is called <cc>. It compiles and links a set of C/C++ source
> files into an executable, a shared library (DLL), or a static library. It
> takes care of things like header-file dependencies, and platform-specific
> naming coventions.
>
> The second task is called <cclink>. It is a pared-down version of <cc>
> which only does linking. I haven't attached the doc for it. Usage will
be
> the same as <cc>.
>
> What we'd like from the ant-user folks is some feedback. Have a read and
> let us know what you think.
>
>
> Adam
>
>
> ------------------------------------------------------------------------
>
>
> CC
>
>
> Description
>
> Compiles and links a set of C and C++ source files into an executable,
> shared library (DLL), or static library.
>
> The CC task invokes the C/C++ compiler on each out-of-date source file.
> Following successful compilation of the source files, the CC task
> invokes the linker to produce the output file. Linking may be disabled
> using the |link| attribute.
>
> You specify the task's input files using one or more nested |<fileset>|
> elements. The |sourcedir| attribute can also be used as a shortcut. It
> creates an implicit fileset that recursively includes all files in a
> particular directory.
>
>
> Compiling
>
> The CC task only attempts to compile files which end in the following
> suffixes: |.c|, |.cc|, |.cxx|, |.cpp, .c++|. Input files that are not
> recognized as source files are passed directly to the linker.
>
> The CC task tracks the dependencies between the source files, and the
> header files that they include. It recompiles a source file if any of
> the header files that it includes changes. To do this, the CC task
> parses the source and header files when they change, and maintains a
> cache of the parsed information in |/basedir//.c_parser_cache|.
>
> To locate header files, the CC task searches the directories specified
> by nested |<includepath>| elements. It does not search the directories
> specified by nested |<sysincludepath>| elements. This way, you can
> reduce the amount of parsing the task performs by putting header files
> which are unlikely to change, such as those from external libraries, in
> |<sysincludepath>| elements.
>
>
> Linking
>
> The linker is only invoked if the output file is out-of-date. The CC
> task determines if the linker needs to be invoked by comparing the
> last-modified time of the output file against that of the object files
> and libraries included in the link. Incremental linking is used where
> available.
>
> Static or shared libraries can be included in the link by including them
> in nested |<libraryset>| elements, or in the input file set.
>
>
> Supported Compilers
>
> The CC task only handles a small number of different compilers and
> linkers, listed below. You can control which compiler to use with the
> |compiler| attribute. For example, on Windows, where Visual C++ and GCC
> are both supported, set |compiler="vc"| to use the Visual C++ compiler
> and linker.
>
> The table below lists the supported compilers, and lists which
> command-line tools need to be in your PATH to use the compiler.
>
> *Name* *Description* *Platforms* *Required Tools*
> gcc The GNU Compiler Collection (GCC).
>
> This is the default compiler for all platforms. This task works with the
> MinGW <http://www.mingw.org/> toolset on Windows, and may also work with
> the Cygwin toolset.
>
> UNIX, Windows |gcc, ar|
> vc Microsoft Visual C++.
>
> This task works with version 6.0, may work with other versions.
>
> Windows |cl, link, lib|
> xlc_r IBM xlC_r Compiler. AIX |xlC_r, ar|
> sunstudio Sun Workshop.
>
> This task works with version 4.2, may work with other versions.
>
> Solaris |CC, ar|
>
>
> Name Mapping
>
> The CC task takes care of mapping file names, according to the naming
> convention for the OS platform that the build is running on. The table
> below describes the mappings for the various platforms and file types.
> In this table, /basename/ refers to the file name, minus the directory
> path and the extension.
>
> *Operating System* *Executable File* *Object File* *Shared Library*
> *Static Library*
> Windows /basename/.exe /basename/.obj /basename/.dll /basename/.lib
> Other /basename/ /basename/.o lib/basename/.so lib/basename/.a
>
>
> See Also
>
> The CCLink <cclink.html> task, the DefineSet <defineset.html> data type,
> and the LibrarySet <libraryset.html> data type.
>
>
> Parameters
>
> *Attribute* *Description* *Required*
> compiler The compiler to use. See above for the list of supported
> compilers. If not specified will default to GCC No
> debug Enables the generation of debug information in the output files. No
> link The type of output file to produce. Possible values are:
>
> |none|
> Does not produce an output file.|executable|
> Produces an executable file.|shared|
> Produces a shared library.|static|
> Produces a static library.
>
> Default is |executable|. No
> objdestdir The directory to place object files. Yes
> outfile The name of the output file. The CC task maps this file name
> depending on the output type and OS platform the build is running on
> (see above). Yes, if |link| is not set to |none|
> sourcedir The directory containing the source files. Yes, or at least
> one nested |<fileset>| element.
>
>
> Parameters specified as nested elements
>
>
> compilerarg
>
> An additional command-line argument to pass to the compiler. There may
> be more than one nested |<compilerarg>| element.
>
>
> defineset
>
> A set of preprocessor macros to define and/or undefine. See DefineSet
> <defineset.html> for more details. There may be more than one nested
> |<defineset>| element.
>
>
> fileset
>
> A Fileset that specifies the input files for the task. Files that are
> recognised as C or C++ source files are passed to the compiler. All
> other files are passed directly to the linker. There may be more than
> one nested |<fileset>| element.
>
>
> includepath
>
> A Path that specifies the directories to use when searching for header
> files. This path is passed to the compiler, and is used by the CC task
> when it is performing header file dependency checking. There may be more
> than one nested |<includepath>| element.
>
>
> libpath
>
> A Path that specifies the directories to use when searching for the
> libraries listed in the |libs| attribute. There may be more than one
> nested |<libpath>| element.
>
>
> linkerarg
>
> A command-line argument to pass to the linker. There may be more than
> one nested |<linkerarg>| element.
>
>
> sysincludepath
>
> A Path that specifies the directories to use when searching for system
> header files. This path is passed to the compiler. It is /not/ used by
> the CC task when it is performing header file dependency checking. There
> may be more than one nested |<sysincludepath>| element.
>
>
> Examples
>
> The example below compiles all the source files under the |src|
> directory, and links them into |build/bin/someapp|
> (|build\bin\someapp.exe|). It places the object files in the |build/obj|
> directory.
>
> <cc sourcedir="src" outfile="build/bin/someapp" objdestdir="build/obj" />
>
> The example below builds an executable from source files in two
> different directories. It uses header files from |src/somelib|.
>
> <cc outfile="build/bin/someapp" objdestdir="build/obj" >
> <fileset dir="src/common" />
> <fileset dir="src/server" />
> <includepath location="src/somelib" />
> </cc>
>
> The example builds an executable, defining the preprocessor macro
> |SOMEDEF| during compilation.
>
> <cc outfile="build/lib/someapp" objdestdir="build/obj" >
> <fileset dir="src" />
> <defineset>
> <define name="SOMEDEF" />
> </defineset>
> </cc>
>
> The example below builds a shared library called |build/lib/libapp.so|
> (|build\lib\app.dll|).
>
> <cc link="shared" outfile="build/lib/app" objdestdir="build/obj" >
> <fileset dir="src" />
> </cc>
>
> The example builds an executable, linking against the libraries
> |pthread| and |dl|, and all the libraries in directory |build/lib|.
>
> <cc outfile="build/lib/someapp" objdestdir="build/obj" >
> <fileset dir="src" />
> <libraryset libs="pthread, dl">
> <fileset dir="build/lib" />
> </libraryset>
> </cc>
>
> Below is a more complete example. It uses GCC to build debug versions of
> a shared library, and an executable that uses the shared library.
>
> <!-- Define a common set of libraries -->
> <libraryset id="libs">
> <fileset dir="lib" />
> <fileset dir="/someotherproject/lib" />
> </libraryset>
>
> <!-- Define a common set of macros -->
> <defineset id="defs">
> <define name="DEBUG" />
> <define name="SOMEDEF" value="1"/>
> <undefine name="UNWANTEDDEF" />
> </defineset>
>
> <target name="build">
>
> <!-- Build a shared library -->
> <cc compiler="gcc" debug="true" link="shared"
outfile="build/lib/somelib" objddestdir="build/obj">
> <fileset dir="src/somelib" />
> <includepath location="inc" />
> <sysincludepath location="/someotherproject/include" />
> <defineset refid="defs" />
> <defineset define="EXTRA_DEF" />
> <libraryset refid="libs" />
> <linkerarg value="-somearg" />
> </cc>
>
> <!-- Build an executable -->
> <cc compiler="gcc" debug="true" outfile="build/lib/someapp"
objddestdir="build/obj">
> <fileset dir="src/someapp" />
> <includepath location="inc" />
> <defineset refid="defs" />
> <libraryset refid="libs" />
> <libraryset>
> <fileset dir="build/lib" includes="*somelib*" />
> </libraryset>
> <compilerarg value="-somearg" />
> </cc>
> </target>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
>
> DefineSet
>
>
> Description
>
> A datatype that defines a set of C preprocessor macros.
>
>
> See Also
>
> The CC <cc.html> task.
>
>
> Parameters
>
> *Attribute* *Description* *Required*
> define A comma-separated list of preprocessor macros to define. These
> take the form /macro/[=/value/]. No
> undefine A comma-separated list of preprocessor macros to undefine. No
> refid A reference to another |<defineset>|. No other attributes or
> nested elements may be used with this attribute. No
>
>
> Parameters specified as nested elements
>
>
> define
>
> Defines a preprocessor macro. It takes the following attributes:
>
> *Attribute* *Description* *Required*
> name The name of the macro to define. Yes
> value The value to set the macro to. No
>
>
> undefine
>
> Undefines a preprocessor macro. It takes a single |name| attribute.
>
>
> Examples
>
> Below is a define set which defines two macros, |SOMEDEF| and
|ANOTHERDEF|.
>
> <defineset define="SOMEDEF, ANOTHERDEF" />
>
> Below is a define set which defines the same macros, using nested
elements.
>
> <defineset>
> <define name="SOMEDEF" />
> <define name="ANOTHERDEF" />
> </defineset>
>
> Below is a define set which gives macro |SOMEDEF| the value 1, and
> undefines macro |UNWANTEDDEF|.
>
> <defineset>
> <define name="SOMEDEF" value="1" />
> <undefine name="UNWANTEDDEF" />
> </defineset>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
>
> LibrarySet
>
>
> Description
>
> A datatype that defines a set of static and shared libraries to include
> when linking an output file.
>
>
> See Also
>
> The CC <cc.html> task.
>
>
> Parameters
>
> *Attribute* *Description* *Required*
> libs A comma-separated list of the libraries to include in the link.
> Names in this list should be the library's /basename/. No
> refid A reference to another |<libraryset>|. No other attributes or
> nested elements may be used with this attribute. No
>
>
> Parameters specified as nested elements
>
>
> fileset
>
> A Fileset that contains the libraries to include in the library set.
> There may be more than one nested |<fileset>| element.
>
>
> Examples
>
> The example below defines a library set that contains the libraries
> |pthread| and |dl|.
>
> <libraryset libs="pthread, dl" />
>
> The example below defines a library set that contains all the files in
> |build/lib|.
>
> <libraryset>
> <fileset dir="build/lib" />
> </libraryset>
>
> ------------------------------------------------------------------------
> cc.html
>
> Content-Type:
>
> text/html
> Content-Encoding:
>
> quoted-printable
>
>
> ------------------------------------------------------------------------
> defineset.html
>
> Content-Type:
>
> text/html
> Content-Encoding:
>
> quoted-printable
>
>
> ------------------------------------------------------------------------
> libraryset.html
>
> Content-Type:
>
> text/html
> Content-Encoding:
>
> quoted-printable
>
>
--
Michael Twomey
These opinions are my own and do not represent Sun unless otherwise stated.
Sun Microsystems, Dublin, 8199164, x19164
"Fly my little Makefiles! Fly!"
Re: proposed C++ support
Posted by Michael Twomey <mi...@ireland.sun.com>.
Hi,
looks good. While I can't comment on how it handles fiddly dependancies
until I try it my one request would be some means of handling the
*-config scripts common in GNU projects (e.g. `gnome-config --libs
--cflags`). Usually these are invoked using backticks from the compiler
command line (e.g. 'gcc `gnome-config --cflags` -o somefile.o
somefile.c') but this never seemed to work for me in Ant when I tried
passing them as parameters.
Some means of supporting this would reduce the work writing ant files
dramatically for GNU projects. If I've missed something blindingly
obvious in Ant that handles this please point it out to me.
thanks,
mick
Adam Murdoch wrote:
> Hi,
>
> Last week, a couple of tasks were submitted to ant-dev, for adding C/C++
> support to ant. One proposal was from Mark Russell, another from myself.
>
> After a bit of discussion and some helpful suggestions from various ant-dev
> people, we've combined what we feel are the best features from both
> proposals into a single proposal. Attached are the user docs describing
> what the new tasks will do.
>
> Briefly, we're planning to add two new tasks and some supporting data-types.
>
> The main task is called <cc>. It compiles and links a set of C/C++ source
> files into an executable, a shared library (DLL), or a static library. It
> takes care of things like header-file dependencies, and platform-specific
> naming coventions.
>
> The second task is called <cclink>. It is a pared-down version of <cc>
> which only does linking. I haven't attached the doc for it. Usage will be
> the same as <cc>.
>
> What we'd like from the ant-user folks is some feedback. Have a read and
> let us know what you think.
>
>
> Adam
>
>
> ------------------------------------------------------------------------
>
>
> CC
>
>
> Description
>
> Compiles and links a set of C and C++ source files into an executable,
> shared library (DLL), or static library.
>
> The CC task invokes the C/C++ compiler on each out-of-date source file.
> Following successful compilation of the source files, the CC task
> invokes the linker to produce the output file. Linking may be disabled
> using the |link| attribute.
>
> You specify the task's input files using one or more nested |<fileset>|
> elements. The |sourcedir| attribute can also be used as a shortcut. It
> creates an implicit fileset that recursively includes all files in a
> particular directory.
>
>
> Compiling
>
> The CC task only attempts to compile files which end in the following
> suffixes: |.c|, |.cc|, |.cxx|, |.cpp, .c++|. Input files that are not
> recognized as source files are passed directly to the linker.
>
> The CC task tracks the dependencies between the source files, and the
> header files that they include. It recompiles a source file if any of
> the header files that it includes changes. To do this, the CC task
> parses the source and header files when they change, and maintains a
> cache of the parsed information in |/basedir//.c_parser_cache|.
>
> To locate header files, the CC task searches the directories specified
> by nested |<includepath>| elements. It does not search the directories
> specified by nested |<sysincludepath>| elements. This way, you can
> reduce the amount of parsing the task performs by putting header files
> which are unlikely to change, such as those from external libraries, in
> |<sysincludepath>| elements.
>
>
> Linking
>
> The linker is only invoked if the output file is out-of-date. The CC
> task determines if the linker needs to be invoked by comparing the
> last-modified time of the output file against that of the object files
> and libraries included in the link. Incremental linking is used where
> available.
>
> Static or shared libraries can be included in the link by including them
> in nested |<libraryset>| elements, or in the input file set.
>
>
> Supported Compilers
>
> The CC task only handles a small number of different compilers and
> linkers, listed below. You can control which compiler to use with the
> |compiler| attribute. For example, on Windows, where Visual C++ and GCC
> are both supported, set |compiler="vc"| to use the Visual C++ compiler
> and linker.
>
> The table below lists the supported compilers, and lists which
> command-line tools need to be in your PATH to use the compiler.
>
> *Name* *Description* *Platforms* *Required Tools*
> gcc The GNU Compiler Collection (GCC).
>
> This is the default compiler for all platforms. This task works with the
> MinGW <http://www.mingw.org/> toolset on Windows, and may also work with
> the Cygwin toolset.
>
> UNIX, Windows |gcc, ar|
> vc Microsoft Visual C++.
>
> This task works with version 6.0, may work with other versions.
>
> Windows |cl, link, lib|
> xlc_r IBM xlC_r Compiler. AIX |xlC_r, ar|
> sunstudio Sun Workshop.
>
> This task works with version 4.2, may work with other versions.
>
> Solaris |CC, ar|
>
>
> Name Mapping
>
> The CC task takes care of mapping file names, according to the naming
> convention for the OS platform that the build is running on. The table
> below describes the mappings for the various platforms and file types.
> In this table, /basename/ refers to the file name, minus the directory
> path and the extension.
>
> *Operating System* *Executable File* *Object File* *Shared Library*
> *Static Library*
> Windows /basename/.exe /basename/.obj /basename/.dll /basename/.lib
> Other /basename/ /basename/.o lib/basename/.so lib/basename/.a
>
>
> See Also
>
> The CCLink <cclink.html> task, the DefineSet <defineset.html> data type,
> and the LibrarySet <libraryset.html> data type.
>
>
> Parameters
>
> *Attribute* *Description* *Required*
> compiler The compiler to use. See above for the list of supported
> compilers. If not specified will default to GCC No
> debug Enables the generation of debug information in the output files. No
> link The type of output file to produce. Possible values are:
>
> |none|
> Does not produce an output file.|executable|
> Produces an executable file.|shared|
> Produces a shared library.|static|
> Produces a static library.
>
> Default is |executable|. No
> objdestdir The directory to place object files. Yes
> outfile The name of the output file. The CC task maps this file name
> depending on the output type and OS platform the build is running on
> (see above). Yes, if |link| is not set to |none|
> sourcedir The directory containing the source files. Yes, or at least
> one nested |<fileset>| element.
>
>
> Parameters specified as nested elements
>
>
> compilerarg
>
> An additional command-line argument to pass to the compiler. There may
> be more than one nested |<compilerarg>| element.
>
>
> defineset
>
> A set of preprocessor macros to define and/or undefine. See DefineSet
> <defineset.html> for more details. There may be more than one nested
> |<defineset>| element.
>
>
> fileset
>
> A Fileset that specifies the input files for the task. Files that are
> recognised as C or C++ source files are passed to the compiler. All
> other files are passed directly to the linker. There may be more than
> one nested |<fileset>| element.
>
>
> includepath
>
> A Path that specifies the directories to use when searching for header
> files. This path is passed to the compiler, and is used by the CC task
> when it is performing header file dependency checking. There may be more
> than one nested |<includepath>| element.
>
>
> libpath
>
> A Path that specifies the directories to use when searching for the
> libraries listed in the |libs| attribute. There may be more than one
> nested |<libpath>| element.
>
>
> linkerarg
>
> A command-line argument to pass to the linker. There may be more than
> one nested |<linkerarg>| element.
>
>
> sysincludepath
>
> A Path that specifies the directories to use when searching for system
> header files. This path is passed to the compiler. It is /not/ used by
> the CC task when it is performing header file dependency checking. There
> may be more than one nested |<sysincludepath>| element.
>
>
> Examples
>
> The example below compiles all the source files under the |src|
> directory, and links them into |build/bin/someapp|
> (|build\bin\someapp.exe|). It places the object files in the |build/obj|
> directory.
>
> <cc sourcedir="src" outfile="build/bin/someapp" objdestdir="build/obj" />
>
> The example below builds an executable from source files in two
> different directories. It uses header files from |src/somelib|.
>
> <cc outfile="build/bin/someapp" objdestdir="build/obj" >
> <fileset dir="src/common" />
> <fileset dir="src/server" />
> <includepath location="src/somelib" />
> </cc>
>
> The example builds an executable, defining the preprocessor macro
> |SOMEDEF| during compilation.
>
> <cc outfile="build/lib/someapp" objdestdir="build/obj" >
> <fileset dir="src" />
> <defineset>
> <define name="SOMEDEF" />
> </defineset>
> </cc>
>
> The example below builds a shared library called |build/lib/libapp.so|
> (|build\lib\app.dll|).
>
> <cc link="shared" outfile="build/lib/app" objdestdir="build/obj" >
> <fileset dir="src" />
> </cc>
>
> The example builds an executable, linking against the libraries
> |pthread| and |dl|, and all the libraries in directory |build/lib|.
>
> <cc outfile="build/lib/someapp" objdestdir="build/obj" >
> <fileset dir="src" />
> <libraryset libs="pthread, dl">
> <fileset dir="build/lib" />
> </libraryset>
> </cc>
>
> Below is a more complete example. It uses GCC to build debug versions of
> a shared library, and an executable that uses the shared library.
>
> <!-- Define a common set of libraries -->
> <libraryset id="libs">
> <fileset dir="lib" />
> <fileset dir="/someotherproject/lib" />
> </libraryset>
>
> <!-- Define a common set of macros -->
> <defineset id="defs">
> <define name="DEBUG" />
> <define name="SOMEDEF" value="1"/>
> <undefine name="UNWANTEDDEF" />
> </defineset>
>
> <target name="build">
>
> <!-- Build a shared library -->
> <cc compiler="gcc" debug="true" link="shared" outfile="build/lib/somelib" objddestdir="build/obj">
> <fileset dir="src/somelib" />
> <includepath location="inc" />
> <sysincludepath location="/someotherproject/include" />
> <defineset refid="defs" />
> <defineset define="EXTRA_DEF" />
> <libraryset refid="libs" />
> <linkerarg value="-somearg" />
> </cc>
>
> <!-- Build an executable -->
> <cc compiler="gcc" debug="true" outfile="build/lib/someapp" objddestdir="build/obj">
> <fileset dir="src/someapp" />
> <includepath location="inc" />
> <defineset refid="defs" />
> <libraryset refid="libs" />
> <libraryset>
> <fileset dir="build/lib" includes="*somelib*" />
> </libraryset>
> <compilerarg value="-somearg" />
> </cc>
> </target>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
>
> DefineSet
>
>
> Description
>
> A datatype that defines a set of C preprocessor macros.
>
>
> See Also
>
> The CC <cc.html> task.
>
>
> Parameters
>
> *Attribute* *Description* *Required*
> define A comma-separated list of preprocessor macros to define. These
> take the form /macro/[=/value/]. No
> undefine A comma-separated list of preprocessor macros to undefine. No
> refid A reference to another |<defineset>|. No other attributes or
> nested elements may be used with this attribute. No
>
>
> Parameters specified as nested elements
>
>
> define
>
> Defines a preprocessor macro. It takes the following attributes:
>
> *Attribute* *Description* *Required*
> name The name of the macro to define. Yes
> value The value to set the macro to. No
>
>
> undefine
>
> Undefines a preprocessor macro. It takes a single |name| attribute.
>
>
> Examples
>
> Below is a define set which defines two macros, |SOMEDEF| and |ANOTHERDEF|.
>
> <defineset define="SOMEDEF, ANOTHERDEF" />
>
> Below is a define set which defines the same macros, using nested elements.
>
> <defineset>
> <define name="SOMEDEF" />
> <define name="ANOTHERDEF" />
> </defineset>
>
> Below is a define set which gives macro |SOMEDEF| the value 1, and
> undefines macro |UNWANTEDDEF|.
>
> <defineset>
> <define name="SOMEDEF" value="1" />
> <undefine name="UNWANTEDDEF" />
> </defineset>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
>
> LibrarySet
>
>
> Description
>
> A datatype that defines a set of static and shared libraries to include
> when linking an output file.
>
>
> See Also
>
> The CC <cc.html> task.
>
>
> Parameters
>
> *Attribute* *Description* *Required*
> libs A comma-separated list of the libraries to include in the link.
> Names in this list should be the library's /basename/. No
> refid A reference to another |<libraryset>|. No other attributes or
> nested elements may be used with this attribute. No
>
>
> Parameters specified as nested elements
>
>
> fileset
>
> A Fileset that contains the libraries to include in the library set.
> There may be more than one nested |<fileset>| element.
>
>
> Examples
>
> The example below defines a library set that contains the libraries
> |pthread| and |dl|.
>
> <libraryset libs="pthread, dl" />
>
> The example below defines a library set that contains all the files in
> |build/lib|.
>
> <libraryset>
> <fileset dir="build/lib" />
> </libraryset>
>
> ------------------------------------------------------------------------
> cc.html
>
> Content-Type:
>
> text/html
> Content-Encoding:
>
> quoted-printable
>
>
> ------------------------------------------------------------------------
> defineset.html
>
> Content-Type:
>
> text/html
> Content-Encoding:
>
> quoted-printable
>
>
> ------------------------------------------------------------------------
> libraryset.html
>
> Content-Type:
>
> text/html
> Content-Encoding:
>
> quoted-printable
>
>
--
Michael Twomey
These opinions are my own and do not represent Sun unless otherwise stated.
Sun Microsystems, Dublin, 8199164, x19164
"Fly my little Makefiles! Fly!"