ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Widmer <tom.wid...@googlemail.com>
Subject Re: configuration help
Date Thu, 16 Apr 2009 10:52:07 GMT
Shawn Castrianni wrote:
> I currently have lots of ivy modules (with native code) setup using configurations as
a way to subset the artifacts for the different platforms I support: win32, win64, linux32,
linux64, and solaris.  Then all of my dependency declarations use "*->@" so that resolving
win32 conf of module A will get win32 conf of module B, win64 conf of module A will get win64
conf of module B, etc.  This works great.
> 
> However, my trouble is that I would like to further subset my modules in a different
way other than platform.  Something like: client and server.  This subsetting is a completely
different axis then subsetting by platform so I need both at the same time.  In other words,
I need something like:  win32 client artifacts, linux64 server artifacts, etc.  I essentially
need to specify the intersection of two configuration names and have the artifacts that only
exist in both configurations get resolved.
> 
> Is this possible?  I would think this might be a popular enhancement for those using
ivy for native code modules.
> 
> 
> Without this feature, I have to declare 5 (number of platforms) * 2 (number of distribution
types) = 10 configurations:
> 
> win32-client
> win32-server
> win64-client
> win64-server
> linux32-client
> linux32-server
> linux64-client
> linux64-server
> solaris-client
> solaris-server
> 
> Imagine the headache if I had more than 5 platforms and more than 2 distribution types.

One option is to use an extra attribute, e.g. 'e:distribution="server"', 
and include ([distribution]/) in your repo paths. Also 
'e:platform="win32"' is an obvious extension to this idea.

However, extra attributes don't work in the same way as confs or 
modules. I tried to add a 'component' extra attribute, but ivy wouldn't 
let one component in the same module depend on another. To avoid 
fighting ivy, you might consider using separate modules (e.g. 
somemodule-server), or if you experiment you may find it works perfectly 
for your use cases (though I can see potential problems if you try to 
have client depending on any server artifacts, or vice-versa - you'd 
need to hoist any common stuff to another shared module).

Another point is that I don't think configurations are normally used for 
platform differences, but rather for what use the artifacts are being 
put to (e.g. building, runtime use, documentation, etc.) - obviously 
their behaviour is based on what they are usually used for. You could 
use separate modules for this as well (e.g. mymodule-server-win32). You 
can use properties in your dependencies, and potentially use a single 
ivy.xml file in your source code for all of them, delivering it once per 
platform. e.g.

<info organisation="us" module="mymodule-${platform.type}"/>
...
<dependency org="us" name="somemodule-client-${platform.type}" .../>

Now you don't have to declare any combinations explicitly as confs, but 
rather engineer your build scripts to do the necessary iterations to 
build everything.

In summary, I've generally concluded:
different artifacts <=> different modules
different subsets of artifacts <=> different confs
be careful with extra attributes (including branches)

Tom


Mime
View raw message