ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: OS specific artifacts
Date Fri, 20 Aug 2010 15:51:50 GMT
Nate's got a better answer than I do for the situation where the various
different platforms' artifacts belong in the same Ivy module. So maybe the
question comes down to whether (A) the different platforms represent the
same Ivy module that gets published together and versioned as one and can
coexist on the Ivy repo or (B) each platform is really its own Ivy module
that versions separately.

Nate, it looks like Ivy is just ignoring the type attribute, no?

I recall resisting the idea of making things like OS and platform
first-class citizens in Ivy, but that's a different story from extending Ivy
with these paradigms. And that seems to be a perfect use of the extra
attribute.

On Fri, Aug 20, 2010 at 6:11 AM, Nathan Franzen
<Nathan.Franzen@mmodal.com>wrote:

>
> I think the difficulty is that ivy does not, out of the box, provide enough
> flexibility to distinguish native artifacts.  There are lots of axes you
> might want to use in differentiating libraries, for example release vs
> debug, windows vs linux, 32 bit vs 64 bit and so on.  And I believe that for
> one codebase it is appropriate to have a one ivy project.
>
> So what to do?  "extra" parameters can help some:
>
> ivy.xml:
>  <publications>
>       <artifact name="libX"   type="linux/icc11.32" ext="so"
> extra:os="linux"  extra:platform="32"  conf="linux32-dynamic"/>
>
>       <artifact name="libX"   type="linux/icc11.64" ext="so"
> extra:os="linux"  extra:platform="64" conf="linux64-dynamic"/>
>
>       <artifact name="X" conf="windows32-dynamic"
>                                 extra:os="windows"  extra:platform="32"
>                                 type="winnt_vc90/Release"
>                                 ext="dll"
>                                 />
>       <artifact name="X" conf="windows32-dynamic"
>                                 extra:os="windows"  extra:platform="32"
>                             type="winnt_vc90/Release"
>                                 ext="lib"
>
>
> And then use those os + platform tags in the ivy resolve task:
>
> <ivy:retrieve       conf="${conf.retrieve}"
>
> pattern="${artifact.retrieve.dir}/([os])([platform])/[artifact].[ext]"
>
>  ivypattern="${ivyfile.retrieve.dir}/[organization].[module]/ivy.xml"
>                            file="${basedir}/ivy/ivy.xml"
>  revision="${version}" refresh="true"  />
>
> * actually, ([os])([platform]/) is probably better in order to avoid cases
> of "//" if those tags are not defined.
>
> I don't have all this working beautifully in our heterogeneous environment
> yet, but there seem to be enough pieces to put it all together.  Notice of
> course that the configuration has mutated a little from the ivy traditional
> sense of conf=>"downstream usage" into conf=>"upstream categorization"   And
> I've used "type" just to represent part of compilation original path, i.e.
> an alternate (but less meaningful) way of disambiguating the artifacts.  I
> know that's a little ugly.
>
> A solution to conflicting names exists, so if you are willing to set the
> configuration outside of ivy somehow, then it can work.
>
> -Nate
>
>

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