Issues 2008-09-22
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
|
 
Still loading...
ABCDEFG
1
IDVotesType/MemberMilestonePriOwnerSummary/Comments
2
3
21980PATCHtriageP4issues@sconsSlimmer Node class/instance
4
consensus
5
6
Bill
7
Brandon
8
David
9
Gary1.2p3LudwigOK w/ me. Wasn't sure about his .sources and .implicit removal but if you guys understand it, then fine.
10
Greg1.2p3LudwigNeeds to be checked for 1.5.2 compatibility, but if there are no impediments, go for it.
11
Jim
12
Ken
13
Sohail
14
Steven1.2p3Ludwigagree w/Greg
15
16
21990ENHANCEMENTtriageP4issues@sconsFunctions to manipulate filesystem names
17
consensus
18
19
Bill
20
Brandon
21
David
22
Gary1.xp3GregNice idea.
23
Greg1.xp4hmmm...My issue, spun off from 2192. Needs a design, then an implementation. Not too urgent, but would make it easier for people converting from GNU Make.
24
Jim
25
Ken
26
Sohail
27
Steven1.xp3Greg!
28
29
22000DEFECTtriageP4issues@sconsExecute() should be told about affected Nodes
30
consensus
31
32
Bill
33
Brandon
34
David
35
Gary2.0p3LudwigI like #2 because #1 still leaves users to find the bug (we could warn if no target specified? Then I'd accept #1.) #2 implies not caching at all during the SConscript-reading phase if even one Execute is run though, right? In any case I'm getting scared about amount of work to be done before 2.0, so I vote to defer this. But I'll go along with 1.x.
36
Greg1.xp3/4LudwigI like variant one, but the parameter name should be 'affects' rather than 'target'. If variant two is chosen, maybe all that is needed is to reset the cache if an (unknown) Execute() is performed.
37
Jim
38
Ken
39
Sohail
40
Steven1.xp3LudwigI like variant #2, because even though it's a bigger problem, it would help clean up things. I think the performance impact of clearing this on Execute() (which I believe is used rather sparingly) would be pretty much in the noise range, and that we should therefore Do the Right Thing.
41
42
22010DEFECTtriageP4issues@sconsExecutor memoize
43
consensus
44
45
Bill
46
Brandon
47
David
48
GaryAsked Jean for a testcase.
49
Greginvalid?I'd like to know more about why he thinks this, since we shouldn't be using any memoized values in an Executor, yes?
50
Jim
51
Ken
52
Sohail
53
Steven1.xp3LudwigI think this is valid. add_sources() can get called more than once for builders like Tar() (and for batch builders, once we add them).
54
55
22040ENHANCEMENTtriageP4issues@sconsImprove error message from Program(DIRECTORY)
56
consensus
57
58
Bill
59
Brandon
60
David
61
Gary1.2p3stevenFunny, I think a user here *just* got this same error! +1 on at least throwing a real scons error here.
62
Greginvalid?I'm not sure how to implemente this. Sometimes directories are valid inputs to builders, so you can't trap it in one place.
63
Jim
64
Ken
65
Sohail
66
Steven1.2?p3??I think this could be handled in arg2nodes(), which could at least catch the TypeError (actually, we should create a SConsNodeTypeError or something and not overload the native Python TypeError) and do something more inteligent. At that point, arg2nodes() has the Builder's factory and the result of the lookup, so it should be possible (wave hands, mumble mumble)
67
68
22050DEFECTtriageP4issues@sconsGetBuildFailure returns wrong object
69
consensus
70
71
Bill
72
Brandon
73
David
74
Gary1.x or 2.xp3There's another bug ticket like this too iirc. #1957 I think. (something other than BuildError getting returned from GetBuildFailures) I have code to trap various things that come out of that method.
75
Greg2.xp2Rare, so not urgent.
76
Jim
77
Ken
78
Sohail
79
Steven1.xp3I'd like to see it fixed sooner rather than later (stack traces are ugleee) but don't see it as high priority.
80
81
22070DEFECTtriageP4issues@sconsIOError trying to access a broken symlink with Java()
82
consensus
83
84
Bill
85
Brandon
86
David
87
GaryInvalidI think it's OK as is. Dangling symlinks shouldn't just be silently skipped; they probably should be pointing at something. Better error message at most.
88
GregLooks like a pretty trivial change, but I don't think we should silently bypass files. Also, wouldn't f.exists() work just as well for the existence test?
89
Jim
90
Ken
91
Sohail
92
Steven1.xp4Like the previous, i'd like to see trivial stack trace fixes make it sooner, but not necessarily high priority.
93
94
22080FEATUREtriageP4issues@sconswarn if duplicate=0 and a copy of a source file is in the variant_dir
95
consensus
96
97
Bill
98
Brandon
99
David
100
Gary1.xp3?YES -- this used to bite me! I think I even filed a really ancient bug on it. (Years ago)
Loading...
 
 
 
Sheet 1