C++ and Ivy [WAS: Re: [DISCUSS] EasyAnt ...]

[Dominique Devienne <dd...@gmail.com>]

> On Jan 10, 2008 10:34 AM, Xavier Hanin <xa...@gmail.com> wrote:
> > On Jan 10, 2008 5:13 PM, Dominique Devienne <dd...@gmail.com> wrote:
> > it so that my involvement with Ant took a back step, and I'm mostly
> > watching from afar what's going on in Ant. I've never used Ivy for
> > example. I'd probably have replaced my dependency stuff with Ivy by
> > now, although my stuff was C++ aware and was pulling not just jars
> > with also C++ headers and libraries, packaged sources of dependent
> > modules for debugging, etc...
>
> BTW Ivy is language agnostic, so you can use it for non java dependency
> management. But this is out of topic.

Can I abuse of your time to explore this a little more Xavier? Being
language agnostic doesn't necessarily translate in being usable to
deal with natively compiled and linked dependencies. The ad-hoc system
I built wasn't agnostic. When a dependency had native code associated
to it (the JNI glue code and supporting native libs it depended upon)
as described in the published artifact descriptor, the system knew to
look for foo-module-win32.zip in addition to foo-module.zip, if you
were building on win32, and each platform was getting its own specific
binaries. Then once the dependency was expanded, in addition to
automatically adding the dependent JARs on the classpath, it also
appended to the compilation include path, link library path, and
runtime PATH and java.library.path, and all transitive dependencies of
the current project. The common build could then reference all these
paths by well know ids, with no further configuration. The system
depended on a fixed and well know hierarchy for the artifact zips.

Given the agnostic nature of Ivy, how would one go about replicating
the kind of system I describing above on top of existing Ivy? Note
that I'm pretty ignore of Ivy, and haven't taken the time to explore
the doc before asking this question, so feel free to brush me off to
find the answers myself ;-) But since I have your attention, I thought
I'd try to get advice from the Ivy man directly ;-) Thanks, --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: C++ and Ivy [WAS: Re: [DISCUSS] EasyAnt ...]

[Gilles Scokart <gs...@gmail.com>]

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 <dd...@gmail.com>:
>
> On Jan 10, 2008 11:26 AM, Xavier Hanin <xa...@gmail.com> wrote:
> > On Jan 10, 2008 6:13 PM, Dominique Devienne <dd...@gmail.com> 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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 
Gilles Scokart

Re: C++ and Ivy [WAS: Re: [DISCUSS] EasyAnt ...]

[Dominique Devienne <dd...@gmail.com>]

On Jan 10, 2008 11:26 AM, Xavier Hanin <xa...@gmail.com> wrote:
> On Jan 10, 2008 6:13 PM, Dominique Devienne <dd...@gmail.com> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: C++ and Ivy [WAS: Re: [DISCUSS] EasyAnt ...]

[Xavier Hanin <xa...@gmail.com>]

On Jan 10, 2008 6:13 PM, Dominique Devienne <dd...@gmail.com> wrote:

> > On Jan 10, 2008 10:34 AM, Xavier Hanin <xa...@gmail.com> wrote:
> > > On Jan 10, 2008 5:13 PM, Dominique Devienne <dd...@gmail.com>
> wrote:
> > > it so that my involvement with Ant took a back step, and I'm mostly
> > > watching from afar what's going on in Ant. I've never used Ivy for
> > > example. I'd probably have replaced my dependency stuff with Ivy by
> > > now, although my stuff was C++ aware and was pulling not just jars
> > > with also C++ headers and libraries, packaged sources of dependent
> > > modules for debugging, etc...
> >
> > BTW Ivy is language agnostic, so you can use it for non java dependency
> > management. But this is out of topic.
>
> Can I abuse of your time to explore this a little more Xavier? Being
> language agnostic doesn't necessarily translate in being usable to
> deal with natively compiled and linked dependencies. The ad-hoc system
> I built wasn't agnostic. When a dependency had native code associated
> to it (the JNI glue code and supporting native libs it depended upon)
> as described in the published artifact descriptor, the system knew to
> look for foo-module-win32.zip in addition to foo-module.zip, if you
> were building on win32, and each platform was getting its own specific
> binaries. Then once the dependency was expanded, in addition to
> automatically adding the dependent JARs on the classpath, it also
> appended to the compilation include path, link library path, and
> runtime PATH and java.library.path, and all transitive dependencies of
> the current project. The common build could then reference all these
> paths by well know ids, with no further configuration. The system
> depended on a fixed and well know hierarchy for the artifact zips.
>
> Given the agnostic nature of Ivy, how would one go about replicating
> the kind of system I describing above on top of existing Ivy? Note
> that I'm pretty ignore of Ivy, and haven't taken the time to explore
> the doc before asking this question, so feel free to brush me off to
> find the answers myself ;-) But since I have your attention, I thought
> I'd try to get advice from the Ivy man directly ;-) Thanks, --DD

Sure :-) But I'm not *the* Ivy man, only *one* Ivy man :-)

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.

Is this clear enough for an Ivy "ignorant"?

Xavier


>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/