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.castria...@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 > >
