editlist2007q2
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
$
%
123
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
|
 
Still loading...
ABCDEFG
1
IDVotesType/MemberMilestonePriOwnerSummary/Comments
2
3
16150DEFECTtriageP3stevenknightFortran scanner not picking up #include statements
4
consensusDONE
5
6
Bill
7
Brandon
8
Gary1.xp3agree
9
Greg1.xp3cournape1862 is a dup of this issue; it's 1.x p3 for David, which seems reasonable.
10
Jim
11
Ken
12
Sohail
13
Steven1.xp3cournapeAgree
14
15
16170DEFECTtriageP3stevenknightProblem using MSVSPROJECTSUFFIX in MSVSSolution with Visual Studio 2005
16
consensusDONE
17
18
Bill
19
Brandon
20
GaryLooks like it just needs that suffix to vary depending on MSVS version? Anyway, easy workaround so should be low pri.
21
GregAnother not-research for Steven?
22
Jim
23
Ken
24
Sohail
25
StevenresearchstevenknightVisual Studio cleanup
26
27
16320DEFECTtriageP3stevenknightPrecompiled headers fail with whitespace in the directory path
28
consensusDONE
29
30
Bill
31
Brandon
32
Garyagree w/ everyone else
33
GregresearchJim("1632" is the name of an outstanding novel by Eric Flint.) Yet another whitespace problem for Jim; it may well be already fixed.
34
JimresearchJimDon't think it's fixed, but not certain. I'll add it to the list to check out.
35
Ken
36
Sohail
37
StevenresearchJimagree w/Greg
38
39
16350DEFECTtriageP3stevenknightBuildDir causes strange, undocumented behaviour in MSVSProject builder
40
consensusDONE
41
42
Bill
43
Brandonresearch
44
Gary
45
GregAnother not-research for Steven?
46
Jim
47
Ken
48
Sohail
49
StevenresearchstevenknightVisual Studio cleanup. I need to give these a keyword so they can be perused cleanly
50
51
16420DEFECTtriageP3stevenknight--dry-run does not report all executing statements
52
consensusRobDONE
53
54
Bill
55
Brandonresearch
56
GaryresearchSounds from the report like it's a strfunction+dry-run bug.
57
GregPDF() suggests Rob, but --dry-run is a Taskmaster thing. I don't have TeX installed on my machine, so I can't troubleshoot it to see where the problem lies (or even if it still exists). Ask Rob to research it?
58
Jim
59
Ken
60
Sohail
61
StevenresearchRob Managanjust to investigate where it really belongs
62
63
16430DEFECTtriageP3stevenknightInconsistent behavior of CheckLib
64
consensus
65
66
Bill
67
Brandon1.x or 2.xsee bug for updated analysis
68
GaryBrandon: I don't see the updated analysis. ? Agree w/ Steven, don't even know if these are in the same run every time or not.
69
GregI don't have LAPACK so my attempt to reproduce it failed, Otherwise, no clue.
70
Jim
71
Ken
72
Sohail
73
Stevenresearch?may need to kick it back to filer, there's not a lot of info here. Are those two calls within the same context, applied to different environments, or...?
74
75
16440DEFECTtriageP3stevenknightLINKFLAGS and RPATH conflict
76
consensusDONE
77
78
Bill
79
Brandon1.x
80
Gary1.xp2Steven: I presume the solution would be to put $__RPATH directly in LINKCOM instead of in LINKFLAGS?
81
Greg1.xp2cournapeDavid's analysis is spot-on and, yes, I agree that the solution is to move $__RPATH to LINKCOM.

Moreover, I believe that ALL the "public" variables (CFLAGS, CXXFLAGS, CCFLAGS, LINKFLAGS, YACCFLAGS, whatever) should start out empty; if a Tool or Builder wants to put specific values on the command line, they should use something else to insert it.
82
Jim
83
Ken
84
Sohail
85
Steven1.xp2cournapeDavid's already added a comment diagnosing this, and he's correct, our behavior here is stupid. It would be good to solve this sooner rather than later after 1.0 is out
86
87
16460PATCHtriageP3stevenknightEnable SCons to Handle Big (>200MB) Files
88
consensus
89
90
Bill
91
Brandon2.x
92
Gary1.xp2I'd be in favor of a special-purpose MD5 code for big files even if it's a hack; this is an obvious memory waster esp. now that targets get MD5ed by default. Don't need fancy generators etc., just a special case for MD5 of big files (typically that's the only use of get_contents() on a giant binary, or at least the most common case IMHO).
93
GregGSoCLudwigThis should be part of Ludwig's GSoC project. I promised he'd be assigned some issues; here's the first.
94
Jim
95
Ken
96
Sohail
97
Stevenresearch?I think this comes after Ludwig's memory work. How to do this without causing us to go to disk re-read smaller files multiple times (with the attendant performance hit) will require some visibility into where the memory is actually going.
98
99
16600FEATUREtriageP3stevenknightSource directory must be under top of build tree. - Why ??
100
consensus
Loading...
 
 
 
Sheet 1