ABCDEFG
1
IDVotesType/MemberMilestonePriOwnerSummary/Comments
2
3
25810DEFECTtriageP2issues@sconsAlias looking like a file gets ignored when chaining aliases
4
2.x p4 SK
5
6
Bill
7
David
8
GaryProbably defining them in reverse order would work or something. But it is odd. Ideally SCons should warn if an Alias overlaps a file.
9
Greg2.2p3 or p4who?Hmmm... I know that an Alias "wins" over a Node for the initial lookup, but I wasn't aware that it didn't work for any subsequent levels. I doubt it's a regression, so I can't see a high priority, but it's something we should tackle relatively soon. @Gary: There's some history for using an alias with the same name as a file: using a simple name for the output from Program(). On *IX, the filename is the same as the alias. In that case, a warning would be surprising. The problem now, as I understand it, is that it's not consistent whether the alias or the filesystem name wins.
10
JasonOdd, I normally get an error in Scons when in Parts a Part Alias is defined with the same value of the program() it builds on posix systems. I have not seem this behavior.
11
Jim
12
Ken
13
Sergey
14
Steven2.xp3sk?Looks like another example of our bad order-dependence in Alias definition. Looking at the code, I bet that it works if you switch the order of the calls so the '/tmp/b' Alias is created first. The Alias() builder is using Node.FS.Entry as its factory, and for this to work correctly, it would need to be some other factory that delays disambiguation *and* allows for the string to be later translated into an Alias. That's probably moderately painful given our current inheritance-based Node architecture.
15
16
26090DEFECTtriageP3issues@sconsAIX xlc TypeError: cannot concatenate 'str' and 'list' objects
17
one last try for more info
18
19
Bill
20
David
21
Garymore infoAgree w/ Greg; the logic as it stands looks OK. env.get at line 44 of aixcc.py should be a string, then it passes that string to SCons.Platform.aix.get_xlc. Not sure where it's going wrong. I asked him for more info.
22
Gregmore infoWe can't see what his complete command was, so we can't see if he passed in a command override. If he did, it's his responsibility to pass a string or list as needed. Yes, it's not consistent from tool to tool and this is one thing we should fix as part of the toolchain work.
23
Jason
24
Jim
25
Ken
26
Sergey
27
Stevenmore infoagree with g + g
28
29
26101DEFECTtriageP4stevenknightEvil DOS characters breaks Java builder!
30
research p4 SK then pass to Mike Fowler with notes
31
32
Bill
33
David
34
GarySomething (swig?) is getting output with extraneous newlines in it. I have no idea where to start with that.
35
Gregwhatever DOS guys agree onEntirely too much information in a bug report. It took me three readings to find the ^M causing the problem. Who's generating that file? Does opening the file with universal newlines fix the problem? Do we even support Cygwin for this?
36
Jasonditto .. newlines.. not sure what this would break the builder.. should it not be ignored??
37
Jim
38
Ken
39
Sergey
40
StevenSmells like a Cygwin interaction issue. Gah. Those file names look duplicated, it's almost like it's reading them from stdout of some command. It just needs some elbow grease to debug, but not sure who should take that up.
41
42
25720DEFECTtriageP4issues@sconsInner-inner anonymous classes in Java
43
consensus: INVALID
44
45
BillinvalidConcur w/ Greg.
46
David
47
GaryinvalidConcur w/ Greg.
48
GreginvalidNo response from user, so assume it worked.
49
Jason
50
Jim
51
Ken
52
Sergey
53
Steveninvalidagree w/greg
54
55
25760FEATUREtriageP4issues@sconsDefault manifest generated by Jar is not good
56
consensus: WORKSFORME, see Steven's comment
57
58
Bill
59
David
60
Garyclose?Sounds from Russel's comment like this issue can be closed and we use the page he references to collect Java refactorings (plus his original report was overblown by his own analysis)
61
Gregclose?How does Mike Fowler enter in this mix? If Russel is willing to make this one of the things in the JavaSupport wiki page, I think that's a perfect solution, so let's close this issue.
62
Jason
63
Jim
64
Ken
65
Sergey
66
StevencloseInvite re-opening with more specific info + suggestions if we missed the boat.
67
68
25870DEFECTtriageP4issues@sconsSpurious dependency change when binary appears multiple times in PATH
69
ALREADY CLOSED BY GARYO
70
71
Bill
72
David
73
GaryworksformeMy discussion w/ him in the ticket didn't lead anywhere; close until he has a repro case
74
GregworksformeA better workaround is to use the built-in Touch action, and we should close this issue with that workaround, but I just don't understand how what he reports could occur in the first place. I'm reluctant to let it go, but if he can't get us a better example, I don't see how we can chase it.
75
Jason
76
Jim
77
Ken
78
Sergey
79
Steven
80
81
25880DEFECTtriageP4issues@sconsUnexpected behaviours when source or target omitted
82
research p2 Garyo until test case added, then 2.x p3 +Easy
83
84
Bill
85
David
86
GaryGreg: are you sure this is what's happening? He's using source=None. I think we should wait for a repro case.
87
Greg2.2p4who?The underlying problem is that the same Node appears as a source and a target. We can and should detect this; it's a clear error of some sort. @Gary: Either he's overriding the None somehow or SCons is ignoring it. It's clear from the message that the same node is in both the source and target lists, and that's something we can detect.
88
Jasonditto.
89
Jim
90
Ken
91
Sergey
92
Steven2.2p4 +EasyI think Greg's right. What's going to happen here is that we're going to intuit the source from the target (or vice versa) and if the Builder doesn't have any suffix mangling, you can end up with the same file name as both target and source. A better error message when we detect the case (after running through emitters) sounds like a good idea and pretty easy.
93
94
25890ENHANCEMENTtriageP4issues@sconsBuilder lacks a "no source accepted" declaration
95
consensus: WONTFIX
96
97
Bill
98
David
99
Garyasked for more info. Could be dup or invalid. Update: agree w/ Greg.
100
GreginvalidUse an emitter. I can't image that this is common enough that we need a flag.