On 10/5/15, 2:00 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
>So flex-falcon relys on flex-asjs for tests and flex-asjs relys on >flex-falcon and flex-falcon relys on flex-sdk ... Hmmm And flex-sdk relies on flex-tlf and flex-blazeds, IIRC. >You know how it sounds now having to delete the flex-sdk in order for the >flex-asjs to download some binary deps, to reuse? I’m only asking you to delete flex-sdk so we can start from a known place to try to find out why your build fails but mine doesn't. I’ve never had to delete flex-sdk myself. But I am asking you to test out a recent script I committed since I think it might help other folks as well as you get going with the source from the repos. So I am more interested in fixing issues where the ‘all’ target fails to do what I think it should. >Why not directly rely the flex-asjs on these binary resources? By doing >this, you would remove the circles. That’s a possibility. However, sometimes, a change to flex-asjs requires a synchronized change to flex-falcon. A bug or feature might just require a change in both places since both code bases are under significant development. So relying on an already-built binary might help, but not always. I haven’t looked around to see if there is precedence in other projects and how they handle it. Google Closure Library and Google Closure Compiler often need to be upgraded together as well. Maybe the answer is that test failure shouldn’t fail the build but mark it as ‘unstable’? I think I see that happening in flex-blazeds. What do others think? -Alex
