Linux - Compile Guide and Support

[gregory]

Hi,

May be you already have something similar. Anyway I attach a small script that detects missing .cpp/.h file in CMakeLists.txt. It is propably not perfect but it could be handy for maintainning the cmake file.

Example of use:
% detect_missing_file_in_cmake.sh -h
This script detects '.cpp/.h' files that are in directory (and sub) but not in the current cmake.
options:
-dir : give the directory to check. Default '.'
-help : print this help message and exit
-max_depth : how many depth to check missing file. Default 1
-skip : skip the check of '.h' file. Disable by default

% detect_missing_file_in_cmake.sh -m 3 -dir $PWD/pcsx2 -skip
....../pcsx2/gui/CpuUsageProviderMSW.cpp is missing in CMakeLists.txt
....../pcsx2/IopModuleNames.cpp is missing in CMakeLists.txt

Note All options have default values. To select the option you can use either the full name (-help) or the first letter (-h).

Enjoy.

[gregory]

I saw potentially 2 last issues with the current cmake include systeme (actually not cmake specific) : bad mixing of include between internal and external lib and not standard include path in source code. See below for details. What is your opinion on that ?


* bad mixing of include
By default we include 3rdparty directory, so all .h are taken in this directory with higher priories.
If you build against systeme libraries, include are taken in 3rdparty. Here a proposal of what we can do to improve this situation.
Rename or create sub-directory, to include each 3rdparty separately.
Just an example
-> Soundtouch: we can include in gcc 3rdparty/SoundTouch_internal/ (it will also fix the second issue see below)
3rdparty/SoundTouch_internal/soundtouch/....
-> Zlib: not need to change, we can include in gcc 3rdparty/zlib/
3rdparty/zlib/....

Note: to avoid the breaking of everythings on both windows and linux, some symlinks could be created to ensure compatibility. When codes (build system) are ok, remove the symlink.


* Not standard include path: worth to be fixed to ensure easy swicth between internal include and external include. I hope the path does not depend on distribution. If I do not mistake, Windows guy uses internal lib in all cases.
Example: zlib.h
External include -> /usr/include/zlib.h (gcc use /usr/include)
Internal include -> 3rdparty/zlib/zlib.h (gcc use 3rdparty)
The issue is the code source uses #include "zlib/zlib.h" so the compilation will always uses the internal include. But it can be linked agains syteme library. For example commit 3049 of Jake will not properly work because the include is not aligned with the library. It will also avoid complaint of people building the source without 3rdparty, so less support

Libraries affected (on my debian distribution).
zlib: include the sub directory
bzip: same as zlib
Soundtouch: use minor case for soundtouch dir. So #include "soundtouch/SoundTouch.h" instead of "SoundTouch/SoundTouch.h"
liba52: use a52dec directory instead of liba52 directory

[gregory]

Hi, I thinks you forgot one line in commit 3056. Please find attached a small patch (not tested) that updates the default build type.

[cheako]

I would sure like to help out. Would building a debian folder with a working rules file be a good start? I'm running Karmic and I can test on Lenny.

The package list in the INSTALL file is hard to navigate. Perhaps there should be a script that detects weather yum or apt is executable and then uses "yum provides" or makes a best guess on what the apt pkg names are.

[cheako]

This seams to work as a pkg list for Karmic, some of the deps are not called at all the same thing so they were dropped.
bzip2 libjpeg62 glew-utils libxxf86vm-dev x11proto-xf86vidmode-dev automake autoconf libasound2-dev joystick

For instance did I need libjpeg62-dev and I'm sure I have gtk2, but did I need a -dev pkg? If so what other names would gtk go by?

The INSTALL file could be word wrapped also.

[cheako]

Are the developers using svn?
There are two issues.
1. With the current directory structure there is no way to make tags or branches.
Solution:
svn mkdir trunk
svn mv * trunk; # Every thing except trunk, do this as you'd like.
svn mkdir tags branches
Note:
Making a tag or branch might be done like so:
svn cp trunk tags/pcsx2-1.0
svn cp tags/pcsx2-1.0 branches/pcsx2-1.x
2. svn props are your friend.
Todo:
svn ps svn:excecutable \* build.sh test.sh test.bat
Note:
Make sure if you plan to use svn:eol-style... and as this is a linux/dos effort I suggest you do. You also set a svn:mime that TortesSVN(and others) will detect as being a text file, that is some times you just have to say it's text/plain even when it's not(I.E. *.cpp). Not setting both causes strange problems all over the place that can't then easily be corrected.
This list of props is awesome. If you use it you should not have any problems.
http://www.bioperl.org/wiki/Svn_auto-props


cheako@overrun:~/src/pcsx2/pcsx2$ echo 'svn:eol-style=native; svn:keywords="Author Date Id Rev URL"; svn:mime-type=text/x-sh; svn:executable=\\*' | tr -s '; =' '\n ' | { while read ech; do eval svn ps $ech build.sh test.sh test.bat; done; }
property 'svn:eol-style' set on 'build.sh'
property 'svn:eol-style' set on 'test.sh'
property 'svn:eol-style' set on 'test.bat'
property 'svn:keywords' set on 'build.sh'
property 'svn:keywords' set on 'test.sh'
property 'svn:keywords' set on 'test.bat'
property 'svn:mime-type' set on 'build.sh'
property 'svn:mime-type' set on 'test.sh'
property 'svn:mime-type' set on 'test.bat'
property 'svn:executable' set on 'build.sh'
property 'svn:executable' set on 'test.sh'
property 'svn:executable' set on 'test.bat'
cheako@overrun:~/src/pcsx2/pcsx2$ svn diff
Index: test.bat
===================================================================
--- test.bat (revision 396)
+++ test.bat (working copy)
@@ -1,3 +1,3 @@
-set PATH=./testtools;%PATH%
-bash --noprofile --norc --login -i test.sh
+set PATH=./testtools;%PATH%
+bash --noprofile --norc --login -i test.sh
pause
\ No newline at end of file

Property changes on: test.bat
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ text/x-sh
Added: svn:keywords
+ Author Date Id Rev URL
Added: svn:eol-style
+ native


Property changes on: build.sh
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ text/x-sh
Added: svn:keywords
+ Author Date Id Rev URL
Added: svn:eol-style
+ native


Property changes on: test.sh
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ text/x-sh
Added: svn:keywords
+ Author Date Id Rev URL
Added: svn:eol-style
+ native

[cheako]

This seams to work as a pkg list for Karmic, some of the deps are not called at all the same thing so they were dropped.
bzip2 libjpeg62 glew-utils libxxf86vm-dev x11proto-xf86vidmode-dev automake autoconf libasound2-dev joystick

For instance did I need libjpeg62-dev and I'm sure I have gtk2, but did I need a -dev pkg? If so what other names would gtk go by?

The INSTALL file could be word wrapped also.

This should replace glew-utils.
libglew-dev libgtk2.0-dev
This should replace bzip2.
libbz2-dev
Would this sound like it supplies cg.h? I can't find a package that has this.
http://packages.ubuntu.com/lucid/libvxl1-dev

[gregory]

Cheako

Well, I actually build pcsx2 as a debian package (sid version). It is far from perfect (pre-alpha) but the main thing working. I attached it, so you can play with it. It need version 3062 for the debian patches. For convenience I also attached a small script that download the good revision (only linux plugins) and strip others things to build a .orig.tar.gz, you still need to update the ROOT_DIR parameters.

To build the stuff directly in amd 64 we will need to add more lib in ia32. Just for information the dependancy lib on debian sid (note maybe version can be older).

debhelper (>= 7.0.50), dpkg-dev (>= 1.15.7.1), cmake (>=2.8),
gcc-multilib [amd64], g++-multilib [amd64],
zlib1g-dev (>=1:1.2.3.4) | lib32z1-dev (>=1.2.3.4) [amd64],
libbz2-dev (>= 1.0.4),
libsdl1.2-dev,
libjpeg-dev,
libwxbase2.8-dev (>=2.8.0),
libwxgtk2.8-dev (>=2.8.0),
libgtk2.0-dev (>=2.10),
liba52-0.7.4-dev,
portaudio19-dev,
# version not yet in debian
# libsoundtouch1-dev (>= 1.4),
# I patch the source (remove feature) to compile with version 1.3
libsoundtouch1-dev (>= 1.3),
libsparsehash-dev (>=1.6),
libxxf86vm-dev,
libglew1.5-dev (>=1.5.1),
nvidia-cg-toolkit (>= 2.1.0017.deb1)


Enjoy.

PS: Your missing package is nvidia-cg-toolkit

[arcum42]

@gregory: I think I've got most of the patches committed except for the new spu2-x asm fix, the ndebug ones, and the zzogl -fPIC one. Haven't gotten to the former, and I think the latter I needed to look closer at, because I ran into issue.
And, in Windows, it uses internal libraries for exerything. For now, on Linux, I'm aiming at using the internal version of Soundtouch, and external versions of everything else.

And I can see the concern about internal vs external headers. I'll have to think about that a bit.

One other thing I've been thinking about is the ability to compile pcsx2 by itself, and individual plugins by themselves, because I know some distributions like to have separate packages for each plugin and the main program...

@cheako: Any help is appreciated. We do actually use svn, branches, and tags, btw. Using Gentoo, I don't know much about Debian packaging, but looks like gregory's got you covered.
And yeah, zerogs/zzogl needs nvidia-cg-toolkit.

[cheako]

@cheako: Any help is appreciated. We do actually use svn, branches, and tags, btw.

Where is the path for the branches/tags, please? Can the props be set?

If I had to guess this was in CVS but then got migrated?