Closed GoogleCodeExporter closed 9 years ago
Original comment by arcum42@gmail.com
on 24 Dec 2009 at 1:23
Let's not fret windows for now. Most people on windows don't care much for the
convenience of a fully commandline build script (it's quite possible to
schedule MSVC
auto-builds of the PCSX2 project files already). Linux and secondly mac are
the main
focus for the cmake project. After those are working we'll see about what it
takes to
get it working on win32 also as an extra.
Original comment by Jake.Stine
on 24 Dec 2009 at 2:45
One issue I can see with this patch is that it currently doesn't work if bin2cpp
hasn't already been run on the *.png files to turn them into headers. There's
code in
there to generate them, but it fails before that code is run.
Once I manually generated those files, it seems to work, though...
Original comment by arcum42@gmail.com
on 24 Dec 2009 at 3:37
In that it generates an executable, anyways. Said executable seems to be fairly
broken right now. It gives us a starting point, though.
Original comment by arcum42@gmail.com
on 24 Dec 2009 at 3:44
"One issue I can see with this patch is that it currently doesn't work if
bin2cpp
hasn't already been run on the *.png files to turn them into headers."
This is my bad, cmake scans for target files while configuration, but these
files do
not exist at configuration time, seeem I have to remove them from the target.
I will try to improve the whole thing tonight, when I have time.
Athos
Original comment by Atho...@googlemail.com
on 24 Dec 2009 at 6:21
All right, cool. And it's easy to not notice things like that when the files
have
already been generated. That's one reason why I like to apply patches like this
to a
fresh checkout of the trunk...
Original comment by arcum42@gmail.com
on 24 Dec 2009 at 10:10
hallo,
little progress on cmake:
- reorganized the whole SearchStuff, separated in two parts (Core and Optional)
- Core: if a core dependency is missing, like wx, configuration stops and doesn't
even try to build something
- Optional: dependencys needed by plugins, if they are missing, the plugins are
not build, everything else is (pcsx2, nullPlugins, libs)
- changed linkpriority systemsibs > local projectlibs, means if cmake finds
lib-dev-header it will link againt the library installed on the system (zlib,
bzip2,
SoundTouch, X11, etc.), if they are not present, the local one is used
- more dynamic, less hard-coded
Still on my todo-list:
- find a better way to pass options/switches to compiler/linker
- versioning
- configuration
- everything you may suggest
- Windows and MacOS X support (flying blind on MacOS X)
New full patch attached, against revision 2396.
As usual, feel free to test, comment, delete this post and the patch or report
any
issues.
Athos
Original comment by Atho...@googlemail.com
on 25 Dec 2009 at 12:48
Attachments:
Haven't actually managed to get that patch to compile, but I was having some
trouble
applying the patch initially, so I could easily have messed something up. I'll
try it
again later...
Original comment by arcum42@gmail.com
on 1 Jan 2010 at 10:36
Must have been an issue applying the patch.
This time it seems to be compiling better. However, it errors out when
compiling ZeroGS on
my system. You might be able to adapt Zedr0n's ZZOgl cmake files for it:
http://quant0r.com/cgi-bin/gitweb.cgi?p=zzogl.git;a=tree
For that matter, we should probably compile zzogl if it is there. Also, it'd be
nice if
failing to build a plugin didn't halt the rest of the build.
Oh, the error on ZeroGS was:
/usr/local/src/pcsx2-cmake/pcsx2/plugins/zerogs/opengl/zerogs.cpp: In function
'bool
ZeroGS::CheckChangeInClut(u32, u32)':
/usr/local/src/pcsx2-cmake/pcsx2/plugins/zerogs/opengl/zerogs.cpp:5326: error:
can't find a
register in class 'BREG' while reloading 'asm'
/usr/local/src/pcsx2-cmake/pcsx2/plugins/zerogs/opengl/zerogs.cpp:5326: error:
'asm' operand
has impossible constraints
/usr/local/src/pcsx2-cmake/pcsx2/plugins/zerogs/opengl/ZeroGSShaders/zerogsshade
rs.h: At
global scope:
/usr/local/src/pcsx2-cmake/pcsx2/plugins/zerogs/opengl/ZeroGSShaders/zerogsshade
rs.h:29:
warning: '_CGprogram* LoadShaderFromType(const char*, const char*, int, int,
int, int, int,
int, int, int, int)' defined but not used
make[2]: *** [plugins/zerogs/opengl/CMakeFiles/zerogs.dir/zerogs.cpp.o] Error 1
make[1]: *** [plugins/zerogs/opengl/CMakeFiles/zerogs.dir/all] Error 2
Btw.
Original comment by arcum42@gmail.com
on 8 Jan 2010 at 5:35
Actually, it looks like ZeroSPU2 isn't being built quite right either. It needs:
target_link_libraries(${zerospu2Name} asound)
target_link_libraries(${zerospu2Name} SoundTouch)
Added to it's CMakeList.txt file.
Original comment by arcum42@gmail.com
on 8 Jan 2010 at 5:55
And I figured out what was causing the ZeroGS build failure. Cmake was a little
too smart, and
figured out that I was running on a 64 bit processor, and defined __x86_64__.
That triggered some 64 bit code that hadn't been removed, in case someone
wanted to build
ZeroGS as 64 bit with 0.9.5. Suppose it's time I get rid of it...
Original comment by arcum42@gmail.com
on 8 Jan 2010 at 7:18
hallo,
sorry for my late respond, I was busy lately, so I haven't time to look into
that.
I am aware of some compilation/configuration problems with cmake, but I left
them on
the side, because I wanted to get the cmake stuff finished first, then starting
to
fix compiling.
"Actually, it looks like ZeroSPU2 isn't being built quite right either. It
needs:
target_link_libraries(${zerospu2Name} asound)
target_link_libraries(${zerospu2Name} SoundTouch)
Added to it's CMakeList.txt file."
This is weird, for me it links quite well, I don't know how or why. But maybe I
just
commented something out and the made the patch, I'm not sure atm.
"You might be able to adapt Zedr0n's ZZOgl cmake files for it:
http://quant0r.com/cgi-bin/gitweb.cgi?p=zzogl.git;a=tree"
I already have one for ZZogl, I didn't attach it, because I don't know if you
are
using it or not.
"For that matter, we should probably compile zzogl if it is there. Also, it'd
be nice
if failing to build a plugin didn't halt the rest of the build."
Hmm, yes you're right this is a problem, I'll look into, maybe there is a
possibility
to bypass this.
"And I figured out what was causing the ZeroGS build failure. Cmake was a
little too
smart, and figured out that I was running on a 64 bit processor, and defined
__x86_64__"
This explains why it wasn't building on a x86_64, but I wasn't able to build it
either, and I'm on '2.6.30-2-686', this is strange, but I'll look into,
propably it
needs some testing. A few different Distros/Architectures and all issues come
out, so
I can fix them, so need more testing!!!, :)
I also worked a little bit on the cmake files and got it working on mingw,
however I
have to port pcsx2 to mingw first, it is not compiling atm, but someday. I
can't test
it on MaxOSX, don't have one, but I'll try to get in contact with zedr0n, maybe
he'll
help me out. NMake is also not working, don't have one, don't like it.
I can't provide a patch, it is not stable and a few things are missing, I hope
I can
finish it tonight, so I can provide the latest patch, and that one should be
quite
stable, at least on my machine.
If you guys need something else to include into the cmake script, tell me and
I'll
try to get it working, there are a few things I'am missing, but that should be
easy
to do.
Cmake is new for me, thats why I'am doing all this to get into it, and the best
way
is learning by doing, I'm not familiar with all cmake mechanisms, yet.
Another question: Is it possible to make a new svn branch? with all that cmake
stuff,
so I can provide patches on that? That would be easier for me to make patches
and
also to test them.
Athos
Original comment by Atho...@googlemail.com
on 9 Jan 2010 at 1:09
No problem; I certainly know how that goes.
As far as ZeroSPU2 goes, I should mention that it compiles without those two
lines,
but if you go into the plugin configuration with the generated copy of it,
it'll say
there are unresolved symbols. I put in those lines because I recognised where
the
symbols were from.
Also, as far as ZeroGS goes, while I haven't tested it, I removed all the x64
code
that was being triggered, so it should be fine on that front now.
And cmake is new to me, too, so I'm learning it as I look at your code...
As far as ZZOgl goes, I try to keep things in such a state where it'll compile
if
there's a folder in the plugin folder named 'zzogl', because while it might not
be in
the trunk, it's the main GS plugin I use.
While I could do a new branch, it might be easiest to just commit it to the
main
trunk. All the standard build systems will still be there, and I can keep
patching it
when files get deleted, renamed, or added. While a new branch wouldn't be a
moving
target, I'd have to manually sync it with the main trunk occasionally, which is
always a pain...
Original comment by arcum42@gmail.com
on 9 Jan 2010 at 1:24
Oh, and on the file for pcsx2 itself, if you do this:
set(OPTIMIZATION_FLAGS "-fdefer-pop -fcprop-registers -fif-conversion -fif-
conversion2 -ftree-ccp -ftree-dce -ftree-lrs -ftree-dominator-opts -ftree-ter -
falign-functions -ftree-sra -ftree-copyrename -ftree-fre -ftree-ch
-funit-at-a-time -
fmerge-constants -fthread-jumps -fcrossjumping -foptimize-sibling-calls -pipe
-fcse-
follow-jumps -fcse-skip-blocks -fgcse -msse -fgcse-lm -frerun-cse-after-loop -
fcaller-saves -fpeephole2 -fsched-interblock -fsched-spec -msse2 -fregmove
-fstrict-
overflow -falign-jumps -fno-dse -fdelete-null-pointer-checks -freorder-blocks -
freorder-functions -falign-loops -falign-labels -ftree-vrp -ftree-pre")
set(WARNING_FLAGS "-Wno-format -Wno-unused-parameter -Wno-unused-value -Wunused-
variable")
set(STANDARD_FLAGS "-march=i486 -msse2 -msse -m32 -pipe -fno-tree-dse
-fno-strict-
aliasing -fno-guess-branch-probability ${WARNING_FLAGS}")
you can do this:
set(CMAKE_C_FLAGS_DEBUG "-W -g ${STANDARD_FLAGS}")
set(CMAKE_C_FLAGS_DEVEL "${STANDARD_FLAGS} ${OPTIMIZATION_FLAGS}")
set(CMAKE_C_FLAGS_RELEASE "${STANDARD_FLAGS} ${OPTIMIZATION_FLAGS}")
It just might be easier then having the same flags over and over again...
Original comment by arcum42@gmail.com
on 9 Jan 2010 at 1:26
hallo,
yeah you are completely right arcum the whole flags stuff is a pain, I copied
them
from the cb project just to get things working, I figuired out a better way to
handle
them, but your idea is also good, I suppose I'll try a few things on my own,
then we
can decide which one is better for pcsx2. I'm thinking on maintance and
extensibility
of the build/cmake-system.
relating to commiting the cmake code, if it is not bothering the people it also
could
commited to trunk, I'am good with that, it would be easier for me, so I don't
have to
deal with all svn stuff on my machine, that's all
I'll write a final patch, which could be commited to svn and be a starting
'base' on
futher 'developement' of the build system, give me sime time for that, I hope I
will
be finished tonight.
One final issue I'm concerend about is how to threat zzogl, one way could be a
svn
external of zzogl if Zeydlitz is OK with this. This way, we could handle zzogl
as
another plugin and Zeydlitz can use his own svn-server, but this is just a
thought.
Athos
ps: my timezone is GMT+1
Original comment by Atho...@googlemail.com
on 9 Jan 2010 at 2:55
well, current pcsx2/mac and pcsx2 codebase are quite different and there are
quite a bit of mac-specific things
so i doubt it would be possible to adapt the build system to mac without
actually testing on one :)
I've done cmake system for zzogl, and it builds(and runs) on
mac/linux/win32(both nmake and vs2008)
successfully. I've also done cmake for zerospu2(still need to port win32 to
portaudio too though) so my guess is
i'll be doing my own cmake build system for pcsx2/mac too, just need to find
time for that :)
Original comment by Zedr0...@gmail.com
on 10 Jan 2010 at 3:23
hallo,
next cmake update. I'm sorry for the delay, but I ran into trouble, so
everything
took more time than I assumed.
I believe this is some sort of 'stable' at least on Linux.
I removed the Windows part, I need some time to get it working properly.
I think this could be commited to trunk, if there are no serious issues you
guys will
discover.
Stucture:
pcsx2Root:
cmake/ additional cmake files
cmake/SearcForStuff.cmake searches for dependencies and sets plugins to
build
-CMakeLists.txt root cmake file
build procedure:
cd pcsx2root
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release or Debug or Devel
if no build type is specified, Debug is used.
At the moment there is a problem with resources, otherwise source tree and
binary
tree are strictly separated. But this should be fine.
I looked into the problem that if one plugin does not compile the whole build
process
is stopped, I didn't find a solution for this, but I'm pretty sure cmake has no
mechanism to do this. The only way is to exclude the plugins from the main
target, so
they are not build along with pcsx2, so they have to be build manualy by
calling make
'pluginname'. In my opinion it should stay how it is now, but this is your
decision.
Current patch is attached in two versions, the first one is a diff patch, the
other
one is a archive where all CMakeLists.txt are stored, since I didn't change any
code,
decompress the archive into root dir of pcsx2 and everything should work.
I made this because patch seems to have problems in making directories.
@Arcum42:
There are a few issues with some plugins, zerospu2 and zerogs in fact. I'm not
sure
if I got all dependencies of all plugins, could you please double check that? I
would
appreciate that.
Another problem is ZZogl. I have a working ZZogl-CmakeFile, but I don't know if
the
user use this plugin or not. The folder plugins/ZZogl exist anyway, because the
CMakeLists.txt is stored there, here we need a solution. I could check if one
file
exists, if yes proceed with ZZogl, if not, leave it. This could be a solution, I
wanted to ask your opinion or a other solution.
As usual if you have any comments, issues or critism, feel free to post them.
So long.
Athos
Original comment by Atho...@googlemail.com
on 18 Jan 2010 at 1:20
Attachments:
It might be a few days before I get too much of an opportunity to play with
these files.
I did unzip it, and try making the devel version of pcsx2. pcsx2 compiled, and
I was able to
get GSnull, PadNull, USBnull, and dev9null to compile. The rest didn't for one
reason or
another.
As far as zzogl, I'd just check for a zzogl folder in the plugins folder, and
if it has one
of the CMake files in it...
I'll fiddle with it more, but wanted to let you know that I'm looking at it.
Original comment by arcum42@gmail.com
on 19 Jan 2010 at 1:51
hallo,
another small update to fix a few things that went wrong in the last patch.
- fixed config problem with a few plugins, missing include dirs
- fixed portaudio problem of zerospu2, new find module
- more dependency checks to zerogs and zerospu2
- subversion revision information written to svnrev.h
(This is only done, when svn is found on the system:
SVN_REV to last local rev
SVN_MOD to 0, because there is no 'simple' way to get the info, if local files
are
modified, one way could be: "svn status | grep 'M '"
Concerning ZZogl, let's assume we have a functional CMakeLists.txt for ZZogl,
this
file would be stored in pcsx2root/plugins/ZZogl/CMakeLists.txt, so the folde
plugins/ZZogl already exist, because of that I can't just check it, it's there,
or we
don't put that CMakeLists.txt into plugins/ZZogl, but then the user has to
create
that folder, has to get ZZogl sources and the move the CMakeLists.txt into that
folder, then it is possible to check after it.
Little out of topic: A few days ago Debian testing moved to version 2.3 of the
X11
extension x11proto-xf86vidmode. This is some sorf of major change or so, but the
include file xf86vidmode.h does not exist anymore, there is a new file called
xf86vm.h, I don't know if they just renamed it or not. But because of this, I'm
not
longer able to build zerogs, so I can't investigate build errors.
This has potential to get a major issue if people want to build against newer
x11.
"I'll fiddle with it more, but wanted to let you know that I'm looking at it."
Yeah, of course, take your time, I'm not running any where.
Patch attached in zwo version again. Diff made against r2457, but this is only
relevant if files are added or removed.
Athos
Original comment by Atho...@googlemail.com
on 19 Jan 2010 at 11:59
Attachments:
As far as xf86vmode.h, it looks to me like it was taken out of
xf86vidmodeproto-2.3 and
added to libXxf86vm-1.1.0. Always a pain when they move things around.
The plans for zzogl sound good. Also, as far as SoundTouch goes, it's actually
preferable to
use the version in trunk to newer versions, per Jake. So we may want to just
have it go
against the trunk copy, rather then checking for installed copies first.
And the subversion plans sound good, and I'll check out the new version of the
patch when I
have a moment...
Original comment by arcum42@gmail.com
on 20 Jan 2010 at 1:00
I've committed modified versions of addBuildSystem3. Everything builds, though
the zerospu2
build could be more flexible, and I can't get any GS plugins other then GSnull
to work.
(Though I got ZeroGS compiling and loading; it just crashes when run.)
The ZeroGS build needs to copy ps2hw.dat into the plugin directory, btw. I'm
not totally sure
how to do that, though.
Original comment by arcum42@gmail.com
on 21 Jan 2010 at 3:18
hallo,
"I've committed modified versions of addBuildSystem3. Everything builds", I'm
glad to
hear that, :).
"The ZeroGS build needs to copy ps2hw.dat into the plugin directory, btw. I'm
not
totally sure how to do that, though."
I'll take care of that, this is sort of problem, I can't imagine, I didn't
really
read the whole code. Another issue is, the fx files are not compiled yet, this
is
missing, too.
If you find anything else, please let me know, I'll fix it.
Athos
Original comment by Atho...@googlemail.com
on 21 Jan 2010 at 3:40
In theory, what you would do is you would compile the two source files in
ZeroGSShaders into
a n executable called zgsbuild, run zgsbuild ps2hw.fx ps2hw.dat, and then copy
the dat file
to plugins.
In practice, a copy of the dat file is in the Win32 directory, and gets copied.
:(
Oh, and theoretically zerospu2 can be compiled against PortAudio, Alsa, or OSS.
To get it
working, I made it just build against Alsa for the moment. Defining
ZEROSPU2_PORTAUDIO,
ZEROSPU2_ALSA, or ZEROSPU2_OSS switches targets, but it goes against Alsa by
default.
That's pretty new functionality, and the Alsa version is the only one with much
testing,
though, so we can get away with just making that one...
Original comment by arcum42@gmail.com
on 21 Jan 2010 at 3:52
hallo,
next patch arrives:
- SoundTouch: always use project one, link errors against newer/different
versions
- add subversion code(again, got lost somehow), does not work out-of-the-box,
svnrev.h is generated, but nowhere included, I didn't diff my changes to get it
working
- add PortAudio search module (PortAudio disabled atm)
- all CMakeLists.txt have the same structure now, easier to read/change etc.
- spu-x: CMakeLists.txt added again, but plugin itself is not compilable
- ZeroGS: ps2hw.dat is copied into plugins folder of pcsx2, is that correct???
- ZeroSPU2: linking against PortAudio is prepared, but disabled -> uncomment
when ready
MiniHowTo:
svn co 'pseudourltopcsx2sources'
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Debug or Devel or Release, case sensitive,
everything
else will end up in undifined behaviour.
If CMAKE_BUILD_TYPE is missing, Debug type is used.
make --jobs=N
N=Amount of you physical cores/cpu's excluding hyperthreading.
'make help' shows available targets to build
Attention: All plugins using PS2Ext.h are broken on Release type, something
about
inlining. Should only affect null plugins, changed a few weeks ago. Missing
define I
assume.
ZeroGS: I finally got it build, r2364 fixed it, it doesn't crash on startup,
but if I
try to click on OK in the configuration dialog, everything freezes, so I have
to kill
pcsx2.
Athos
Original comment by Atho...@googlemail.com
on 21 Jan 2010 at 9:14
Attachments:
I can´t compile with cmake on fedora 12 64 bit version i become this:
[LinuxDonald@localhost build]$ cmake .. -DCMAKE_BUILD_TYPE=Debug
CMake Error at cmake/SearchForStuff.cmake:19 (find_package):
Could not find module FindGTK2.cmake or a configuration file for package
GTK2.
Adjust CMAKE_MODULE_PATH to find FindGTK2.cmake or set GTK2_DIR to the
directory containing a CMake configuration file for GTK2. The file will
have one of the following names:
GTK2Config.cmake
gtk2-config.cmake
Call Stack (most recent call first):
CMakeLists.txt:10 (include)
-- Found SoundTouch: /usr/lib64/libSoundTouch.so;/usr/lib64/libSoundTouch.so
CMake Warning at cmake/SearchForStuff.cmake:125 (find_package):
Could not find module FindALSA.cmake or a configuration file for package
ALSA.
Adjust CMAKE_MODULE_PATH to find FindALSA.cmake or set ALSA_DIR to the
directory containing a CMake configuration file for ALSA. The file will
have one of the following names:
ALSAConfig.cmake
alsa-config.cmake
Call Stack (most recent call first):
CMakeLists.txt:10 (include)
-- Configuring incomplete, errors occurred!
Original comment by linuxdon...@gmail.com
on 21 Jan 2010 at 11:46
@linuxdonald: Right now I'm not worrying about building on 64-bit operating
systems.
Possibly later, once everything is working in 32 bits. For now, it either needs
to be
built in a 32 bit os, or a 32 bit chroot.
@Athostr: Yeah, fixing ZeroGS was a matter of having it find Cg and Glew, and
also
changing one char. in some assembly which was messing up building it. That char
causes it to use ebx in the assembly, which apparently shouldn't be done when
it's
compiled with -fPIC.
And I'll go ahead and commit the patch.
Original comment by arcum42@gmail.com
on 22 Jan 2010 at 4:31
Take the ownership.
I have plenty of things to do to square the cmake build. So expect improvement
in
coming week ;)
@linuxdonald: could you redo a test with post rev 3151. I made multiple fix, it
will
probably work better. It is ok on debian but I do not know for fedora. Moreover,
could you check where is the 32bits file wx/setup.h (mine is
/usr/lib32/include/gtk2-unicode-release-2.8/wx/setup.h) Note it must contains
the
following line: #define SIZEOF_VOID_P 4
Original comment by gregory....@gmail.com
on 4 Jun 2010 at 11:22
Just adding myself to the cc: on this issue, since I'm no longer the owner...
Original comment by arcum42@gmail.com
on 4 Jun 2010 at 11:54
Ok, in my opinion, cmake is now in a good state (post rev 3207). If people are
willing to do some testing I will be glade.
Note1: I update the linux compilation guide on the wiki to use cmake.
Note2: ZZogl assertion failure are expected with the Debug build in some
situations...
Note3: For 64bits user, I advice to use a 32bits chroot. For linux expert users
that do not want to install a chroot. You must install all (pcsx2 dependency
will be enough;) ) 32 bits library in your system. Check that 32bits
configuration for wx (ie wx/setup.h) is properly installed.
Enjoy ^^
Original comment by gregory....@gmail.com
on 13 Jun 2010 at 11:50
I had warning that zeropad wouldn't build because of unsatisfied dependencies,
but those dependencies were not reported. Install SDL-devel, (I'm on fedora 13)
seems to fix that problem.
Now I get this compile error:
[ 3%] Built target pcsx2_SoundTouch
[ 3%] Building CXX object
common/src/Utilities/CMakeFiles/Utilities.dir/HashTools.cpp.o
In file included from
/home/msp/local/pcsx2-svn/common/src/Utilities/HashTools.cpp:3:
/home/msp/local/pcsx2-svn/common/include/Utilities/HashMap.h:3:32: error:
google/type_traits.h: No such file or directory
The desired include file seems to be from this project,
http://code.google.com/p/thrust/, but I can't find a yum package for it. I just
noticed its in in 3rd party, so there must be an include path issue.
Original comment by mark.pat...@gmail.com
on 20 Jun 2010 at 5:45
Yeah, I could print dependency in messages. I was too lazy to do it before.
In debian, the package is libsparsehash-dev, it is not related to thrust.
Actually the 3rdparty is for windows...
In any case, I need to do a cmake check for these includes.
Original comment by gregory....@gmail.com
on 20 Jun 2010 at 9:28
@mark, I update cmake (rev 3257) to print some friendly messages. Thanks for
the feedback.
Original comment by gregory....@gmail.com
on 21 Jun 2010 at 2:03
I tried latest and got a useful error messages about not finding sparse hash:
Could NOT find SparseHash (missing: SPARSEHASH_INCLUDE_DIR)
I found an rpm on the sparsehash site and installed it. I was able to compile
after also installing libjpeg-devel.
The emulator seems to be working now!
Original comment by mark.pat...@gmail.com
on 22 Jun 2010 at 11:46
I think now cmake build system is done and user friendly.
Original comment by gregory....@gmail.com
on 4 May 2011 at 10:10
Original comment by gregory....@gmail.com
on 4 May 2011 at 10:10
Original issue reported on code.google.com by
Atho...@googlemail.com
on 24 Dec 2009 at 12:41Attachments: