A | B | C | D | E | F | G | |
---|---|---|---|---|---|---|---|
1 | ID | Votes | Type/Member | Milestone | Pri | Owner | Summary/Comments |
2 | |||||||
3 | 2133 | 0 | DEFECT | triage | P4 | belley | Incorrect Dependency Cycle error |
4 | consensus | wontfix | Steven to open an enhancement for synthetic targets via Alias() | ||||
5 | |||||||
6 | Bill | ||||||
7 | Brandon | ||||||
8 | David | ||||||
9 | Gary | I'm on the fence. Running the target in AddPostAction is a common use case. What's the workaround if we don't change the behavior? There needs to be one. If we do change it, people can use Depends(), but will they think to? Probably not. | |||||
10 | Greg | wontfix | My comment is in the issue. I don't think it's a bug. He can get the same effect with a synthetic target in a separate step. | ||||
11 | Jim | ||||||
12 | Ken | ||||||
13 | Sohail | ||||||
14 | Steven | 1.0.x | p4 | I think it's too common a use case to mark invalid as is. Right now, I'm thinking perhaps an option (yay, more configurability... :-/) that specifies whether or not the AddPostAction() command gets "scanned" for the implicit dependency. My gut say 1.0.x so the common use case gets looked at sooner rather than later, but p4 because in the grand scheme of things it's not killing anyone to have to specify Depends()... | |||
15 | |||||||
16 | 2134 | 0 | FEATURE | triage | P4 | stevenknight | create public object like SCons.Util.CLVar |
17 | consensus | ||||||
18 | |||||||
19 | Bill | ||||||
20 | Brandon | 1.x | If it's cleaner to implement in python 2.x, I'd say wait for it. | ||||
21 | David | ||||||
22 | Gary | 1.x | p3 | Everyone should be using this rather than plain lists or strings, so I'm definitely in favor of it. Greg: what in python 2.x makes it easier? Seems like it works OK now. Maybe new-style classes make the syntax simpler? | |||
23 | Greg | Good idea, but when? Maybe it should wait until 2.0, when Python will have features to make this easier. (Gary: the 'attribute' machinery, which runs code when you assign to a varaible, so you could make it a CLVar for ever and ever.) Generic comment: is there a list anywhere of all the names SCons adds to the global namespace? (Should there be?) It just seems to me that it's getting a bit cluttered in there, and maybe moving some of the names into clusters might be beneficial. | |||||
24 | Jim | ||||||
25 | Ken | ||||||
26 | Sohail | ||||||
27 | Steven | 1.x | p3 | stevenknight | default reclassify-for-1.x settings | ||
28 | |||||||
29 | 2135 | 0 | DEFECT | triage | P4 | stevenknight | SConscript(variant_dir) and VariantDir() inconsistant |
30 | consensus | ||||||
31 | |||||||
32 | Bill | ||||||
33 | Brandon | 1.0.x | |||||
34 | David | ||||||
35 | Gary | 1.0.x | p2 | ok w/ me. | |||
36 | Greg | 1.0.x | p2 | One of mine. My comments are in the issue. | |||
37 | Jim | ||||||
38 | Ken | ||||||
39 | Sohail | ||||||
40 | Steven | 1.0.x | p2 | agree w/greg | |||
41 | |||||||
42 | 2136 | 0 | DEFECT | triage | P4 | stevenknight | src_dir with no variant_dir in SConscript() call |
43 | consensus | ||||||
44 | |||||||
45 | Bill | ||||||
46 | Brandon | 1.x | |||||
47 | David | ||||||
48 | Gary | 1.x | p2 | I'm OK with making this work. | |||
49 | Greg | 1.x | p2 | One of mine. My comments are in the issue. | |||
50 | Jim | ||||||
51 | Ken | ||||||
52 | Sohail | ||||||
53 | Steven | 1.x | p2 | agree w/greg. | |||
54 | |||||||
55 | 2137 | 0 | DEFECT | triage | P4 | stevenknight | User's Guide: rewrite VariantDir description |
56 | consensus | ||||||
57 | |||||||
58 | Bill | ||||||
59 | Brandon | 1.0 | |||||
60 | David | ||||||
61 | Gary | 1.0 | p3 | I love better doc, almost as much as better error messages. | |||
62 | Greg | 1.0 | p3 | One of mine. My comments are in the issue. | |||
63 | Jim | ||||||
64 | Ken | ||||||
65 | Sohail | ||||||
66 | Steven | 1.0 | p3 | agree w/greg | |||
67 | |||||||
68 | 2138 | 0 | DEFECT | triage | P4 | stevenknight | Missing () in Entry.must_be_same |
69 | consensus | ||||||
70 | |||||||
71 | Bill | ||||||
72 | Brandon | 1.0.x | p2 | ||||
73 | David | ||||||
74 | Gary | 1.0 | p2 | Pretty late to change anything for 1.0, but it looks clearly correct, and all tests pass with it on my Ubuntu box. So I vote for 1.0. I'd be even happier if there were a test case that failed with the code as is. | |||
75 | Greg | 1.0? | If he's right, this should be fixed ASAP, if not sooner. What are the potential implications of puting this in 1.0? Does this require a 0.98.6? I agree w/Gary about a test case. | ||||
76 | Jim | ||||||
77 | Ken | ||||||
78 | Sohail | ||||||
79 | Steven | 1.0.x | p2? | maybe p1? it's clearly the right fix, but i don't have a good feel for what all of the ramifications might be. | |||
80 | |||||||
81 | 2140 | 0 | FEATURE | triage | P4 | stevenknight | Automatic node re-ordering patch |
82 | consensus | ||||||
83 | |||||||
84 | Bill | ||||||
85 | Brandon | 1.x or 2.x | For a callback based mechanism I can see this going into 1.x, but for internal SCons functionality, I'd say 2.x | ||||
86 | David | ||||||
87 | Gary | ||||||
88 | Greg | I'm staying out of this one; my reservations about it have been expressed in the mailing list. In brief, I can't see wasting any core developer time on a tiny niche like this, but if an absolutely perfect patch shows up, I won't resist applying it. | |||||
89 | Jim | ||||||
90 | Ken | ||||||
91 | Sohail | ||||||
92 | Steven | 1.x | p4 | After more thought, I'm okay with some clean hook that allows for re-ordering build order between targets, like the hook that --random uses allows within a target's dependencies, along with some configurability for how many targets get examined, and a way to fetch this info (e.g. at the end of the run) for external storage. I'm no longer in favor of putting this info in the .sconsign file. Someone wants to try to make something this smart? Fine, knock yourself out, but base SCons should just stay dumb and simple about it. | |||
93 | |||||||
94 | 2141 | 0 | DEFECT | triage | P4 | stevenknight | g++ tool doesn't add -fPIC to SHCXXFLAGS as default case |
95 | consensus | ||||||
96 | |||||||
97 | Bill | ||||||
98 | Brandon | 1.0.x | |||||
99 | David | ||||||
100 | Gary |