According to me, you might enounter some issues when working with C/C++. The major issue that I see is that ivy can handle any kind of dependencies provided that the dependencies are files. And the natural way of managing dependencies in C++ is to use directories.
In C++ your compile dependencies are header files, while in java its jars. Usually, you will have quiet a lot of header files. Probably too much to list all of them in a dependency descriptor. So, to work around the fact that ivy only manipulate dependnecies with file, you will probably have to ter/zip/... when publish and untar/unzip/.. when you are resolving dependencies. This is feasible, but might be too heavy in some case. And by the way, one of the most popular issue in ivy is [1] Enable file directory as artifact. <https://issues.apache.org/jira/browse/IVY-209> [1] https://issues.apache.org/jira/browse/IVY-209 Gilles 2008/1/10, Dominique Devienne <[EMAIL PROTECTED]>: > > On Jan 10, 2008 11:26 AM, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > On Jan 10, 2008 6:13 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote: > > First what I mean by language agnostic is that Ivy can handle any kind > of > > artifacts, and not only jars. So in your case you can easily declare > that > > your module publishes several artifacts, one being the jar, and the > others > > being platform specific zips. Then you can split your platform specific > zips > > in separate configurations (one by platform). This declaration goes in > the > > module ivy file in the repository. Then you can ask Ivy to resolve the > > platform specific configuration you need depending on the platform you > make > > your build on. And once you get the zip on your local filesystem you can > do > > whatever you want with it like you did before, Ivy being used only for > > provisioning. > > Yes, this gives me an idea about the process, thanks. I was expecting > a bit more, in term of path assembling, as doing a transitive addition > of all artifact dirs into a path is something that only a > dependency-aware task can do well I think, but OTOH limiting yourself > to doing only one thing well is always a good design decision in my > book. I'll need to dig this more on my own now. --DD > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Gilles Scokart
