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
