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: feature request: configuration intersections only implemented halfway
Date Wed, 29 Jul 2009 21:06:33 GMT
I would heartily second Garima's feature request. I'll describe below a
potential error condition with the way configuration intersections are
implemented now.

It looks to me like adding what she's asking for in no way compromises the
functionality Shawn already enjoys. It just more explicitly, clearly, and
robustly enforces the contract involved in intersections--and prevents the
error I'll describe shortly.

Shawn, a question for you. Would you agree that merely *allowing *intersections
on the *artifact *element--while still supporting the existing behavior--in
no way compromises what you're already able to accomplish?

And a question for Maarten or Xavier. What is the proper channel to go
through for requesting a new feature in Ivy?

Few responses to Shawn inline...


On Wed, Jul 29, 2009 at 11:39 AM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:

> First, I will admit I did not ready every word of your post as it was
> lengthy.  Therefore, I will only comment on what caught my eye.
>
>
> 1. " However, according to system's ivy.xml, this windows+debug syntax is
> useless and meaningless. The implicit request for
> art1d.dll could just as well be expressed as: <dependency ...
> conf="default->windows,debug" />"
>
> This is not true.  "default->windows,debug" means give me all of the
> artifacts that exist in either (union) configurations windows and debug.
>  Whereas, "default->windows+debug" means give me all of the artifacts that
> exist only in both (intersection) configurations windows and debug.  If I am
> trying to build a windows debug version of my module, than I don't want all
> the windows artifacts and all the debug artifacts.  All the windows
> artifacts will give me release artifacts too.  All the debug artifacts will
> give me other platforms artifacts too.  Since I am building my module in
> debug mode, release artifacts do me no good.  Since I am building on
> windows, linux artifacts do me no good.  Therefore, the only way for me to
> get exactly what I want is the intersection notataion of windows+debug.
>

Shawn, this may be a precious distinction. But what I think Garima is trying
to say is that, *strictly on the face of it*, "windows+debug" is useless and
meaningless when the artifact is specified as "windows,debug". It's only by
doing the exercise of going through the artifacts and producing the
intersection that you're able to obtain just that one file, art1d.dll.

So this brings me to the error condition. If the client were to specify
"windows,debug", they would get something that, in your own example, is
incorrect. Therefore, you're relying on the consumer to specify things
correctly.

What troubles me is that you can have an *artifact *specification that,
standing by itself, is inaccurate. The following, by itself, is inaccurate:
<artifact name="art1d" type="dll" conf="windows,debug" />

This artifact should not be available in the union of windows and debug but
it is. Shawn, would you agree with that narrow statement?


>
>
> 2. "So again, let's either implement configuration intersections fully or
> remove configuration intersections entirely from Ivy."
>
> I requested this feature.  I have a real world use case for it as described
> above.  It solves my problem beautifully.  Its existence in ivy does not
> hurt anybody if they don't use it.  Removing it only hurts me and doesn't
> help anybody else.


Shawn, I appreciate that Garima's message was a lot to digest. But it looks
like you're grabbing a bit of devil's advocacy and taking it out of context.
I think Garima has made it clear as day that she too believes configuration
intersections are a great and necessary feature and that the idea of
removing it is not the path she wants to go down.

It so happens that I myself am facing a real-world use case for
configuration intersections and that I myself find the current support for
the feature overly complex and an invitation for trouble. Maybe this is an
admission that I'm not too bright, but I would hate to have to look at a
single *artifact *element, see the union of confs, and not be aware that the
artifact actually should *not *be delivered in that situation--and that I'm
going to have to go through a little mathematical exercise to figure out
what should be delivered when.

>
>
> ---
> Shawn Castrianni
>
>

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