ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sutherland <>
Subject Re: AW: Ivy in C/C++ environment
Date Wed, 12 Dec 2012 18:02:34 GMT
I too have developed a C++/C Ant/Ivy cross-platform (x86, and assorted arm) development environment.

Like Maurer, we created ant scripts that all of a common interface of build/test/install/publish
targets.. For projects that we control, we use that interface to drive CMake.. Since all our
projects use CMake, I was able to create 'helper ant files' to handle most of the heavy lifting,
so that a build.xml file for a project is 4 lines long. Third party stuff is somewhat chaotic,
since everything wants to build differently, but we try to maintain that ant interface as
best we can.

One thing that needs to be considered is what files get stored in Ivy.. I didn't want the
maintenance overhead of keeping track of all the header files that are added, so in our 'install',
we always install to a particular directory (<project>/installed_files). Then in the
publish, I zip up that entire directory, and that is my artifact. I have a trigger on the
download of a dependency to unzip the files. (into <project>/dependencies). This allows
us to write the CMake build scripts to always look into ./dependencies for the needed files.

Since we need to be cross platform, I added a "platform" in the dependency info:
<dependency name="libManager" rev="trunk" e:platform="${platform}" />

That platform gets injected into my repo path:

    <sftp name="shared" user="..." userPassword="..." host="..." checksums="sha1,md5" checkmodified="true"
        <ivy pattern="ivy_shared_repo/[organisation]/[module]/[platform]/ivys/[revision]/ivy.xml"/>
        <artifact pattern="ivy_shared_repo/[organisation]/[module]/[platform]/[type]s/[revision]/[artifact].[ext]"/>

When we build or publish, we pass what platform it is: ant -Dplatform=arm-debug

Now we can have pre-compiled dependencies, for multiple platforms.

Its worked fairly well, though some complain that to switch between platforms is somewhat
of a pain (have to clear out the build, and rebuild everything, or use a separate directory)..
But thats far better than the previous system we had (none)..  Now if I can get all the groups
to get rid of their svn:externals (being used for pretty much the same thing, trying to assemble
multiple projects into a single one), my life would be much easier.


On 12/12/2012 01:16 AM, Maurer Philipp wrote:

We've been extensively using Ant/ivy in our C++ environment.
The main reason was actually ivy to have a (transitive) dependency manager, but also to have
the same "build/install/run/test" interface to all our projects.

The idea is pretty simple: We have a company-wide repository of common libraries (C++source
and pre-compiled) in different versions that can be used in other projects.
When building a project, the correct (in term of version) dependee modules are downloaded
from the repository, extracted and locally build (with the normal build environment e.g. MSVC,
make). We also implemented an auto-environment feature that creates suitable environment variables
pointing to the include / import library paths of the locally built common modules.

But be warned: We had to extensively use Python scripts to enhance Ant/Ivy to make it all
work and it cost many man-months. In the end, we use ant as a standardized interface to our
build management system, use ivy for dependency management and leave the rest to python scripts.
But once set up, it works *really* good.

-----Urspr√ľngliche Nachricht-----
Von: Marcel Overdijk []
Gesendet: Donnerstag, 6. Dezember 2012 17:15
Betreff: Ivy in C/C++ environment

I wonder if somebody has some pointers for using Ivy in a C/C++ environment.

a) how is dependency management done (e.g. using custom resolver?)
b) how is building done (based on on de Ivy dependencies)

I'm not looking for a complete solution, just wat to start a discussion about possibilities
or perhaps best practices from people already having this set up.

Unfortunately I can't find and information in the docs. Ivy is especially interesting as it
is nog tight to Java dependency management.

View this message in context:
Sent from the ivy-user mailing list archive at


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message