Enh: additional CMake build system (Linux)

[GoogleCodeExporter]

hallo,

I wrote a few config files based on CMake.

It is everything else but not perfect, consider it as an alpha version, :).

Anyway, I read, you are considering to create a new build system, so I
though, I publish the config files I use to build pcsx2 on my Linux-machine.

A few things are broken, others do not compile, but it works, somehow, at
least on my notebook.

My System:
Debian GNU/Linux Squeeze (Testing)
Kernel: 2.6.30-2-686

I used cmake 2.8 - docu, but set the required version to 2.6, I am not sure
if this works.
I made it with support for different platform in mind, but atm only Linux
should work, didn't even tried to run it on windows, don't have MSVC.

A few things are bad written, for example CXX_FLAGS compiler flags, this is
only a quick and dirty solution to get the system working, will be changed,
as soon as i figuired out, how to do is better.

Patch is made against revision 2391, but with disabled newVif.

Patch is attached, feel free to test, comment or delete it.

Athos

Original issue reported on code.google.com by Atho...@googlemail.com on 24 Dec 2009 at 12:41

Attachments:

• addBuildSystem.patch

[GoogleCodeExporter]

Original comment by arcum42@gmail.com on 24 Dec 2009 at 1:23

• Changed state: Accepted
• Added labels: Maintainability, OpSys-Linux, Priority-High, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

"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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• addBuildSystem1.patch

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• addBuildSystem2.patch
• addBuildSystem2.tar.gz

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• addBuildSystem3.patch
• addBuildSystem3.tar.gz

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• CMakeSVNPA.patch

[GoogleCodeExporter]

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

[GoogleCodeExporter]

@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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

@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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

I think now cmake build system is done and user friendly.

Original comment by gregory....@gmail.com on 4 May 2011 at 10:10

[GoogleCodeExporter]

Original comment by gregory....@gmail.com on 4 May 2011 at 10:10

• Changed state: Fixed