Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
official source tarball (NOT git)
11-30-2012, 05:28 PM
Post: #16
RE: official source tarball (NOT git)
Alright, done. In the future I'll run this script after every release, right now it has the latest code from git instead of 0.31:

http://ppsspp.org/files/ppsspp-src.tar.gz
Find all posts by this user
Quote this message in a reply
11-30-2012, 07:32 PM
Post: #17
RE: official source tarball (NOT git)
Thank you. This is great. I would suggest giving the distfile a name with the version, like ppsspp-src-0.31.tar.gz to distinguish between versions. Source-based package systems like pkgsrc and FreeBSD's ports keep distinfo files for package distfiles and patches. They look like this (for VBA-M):

http://cvsweb.se.netbsd.org/cgi-bin/bsdw...xt%2Fplain
http://svnweb.freebsd.org/ports/head/emu...iew=markup

As you can see, there are checksums for the distfiles which would change which each version. However, if you just replaced the distfile, this would cause a checksum mismatch and the build would stop. The package maintainers would contact you asking for an explanation of why the checksum had changed. This is to prevent an attack vector for trojans. If you version the distfile as shown above, this won't happen. The distinfo will just get updated when a new version is released.

Here's the build log of ppsspp-0.31:

http://pastebin.ca/2259508

I'll be happy to test any patches before the next version of ppsspp is released.
Find all posts by this user
Quote this message in a reply
11-30-2012, 07:53 PM
Post: #18
RE: official source tarball (NOT git)
OK, I'll add the version number next time.

Feel free to work on fixing the build, just send pull requests with your changes on github.
Find all posts by this user
Quote this message in a reply
11-30-2012, 08:09 PM
Post: #19
RE: official source tarball (NOT git)
Well, I'm a bit stuck at this point. In the build log, you can see where it errors out. I added what I thought would fix it and that resolved one block of errors, but there are still more, which I'm not sure what's causing it, given the changes I made to the file in question.

Additionally, I see you're one of the founders of dolphin. I would package it as well, but the development team was not very helpful in providing a distfile like you did. I've a keen interest in older video game emulators, and have packaged several already. If you can persuade them to provide a distfile for the stable and/or development version of dolphin, I'd gladly start working on it as well.

Best regards,
Find all posts by this user
Quote this message in a reply
11-30-2012, 08:14 PM
Post: #20
RE: official source tarball (NOT git)
I can probably do that yes. But let's start with PPSSPP.

One problem might be that you're compiling with GCC 4.5. PPSSPP only supports GCC 4.6 and higher, because we use a few selected C++1x features like "auto". Also looks like some define or compiler flag related to unicode or wide chars might be set wrong?
Find all posts by this user
Quote this message in a reply
12-01-2012, 10:22 AM
Post: #21
RE: official source tarball (NOT git)
I've generated and uploaded http://ppsspp.org/files/ppsspp-src-v0.4.tar.gz .
Find all posts by this user
Quote this message in a reply
12-01-2012, 12:00 PM
Post: #22
RE: official source tarball (NOT git)
Thanks for the info on GCC 4.6. I've added it to the build. Here's the latest build (and work) log from the latest version you posted:

http://pastebin.ca/2262230

It still fails in the same place after patching Common/ABI.cpp. At the end of that file is the last bit from work/.work.log, which show the particular command sent to the C++ compiler. I have some suggestions based on that command:

1) Have the CMake configure stage test for: a) sha1 b) libzip c) zlib d) glew e) rapidxml just like it does for pthread, SDL, libXext, MesaLib, libX11, libICE, etc. This test could possibly be extended for stb_image, stb_vorbis, etcpack, and libkirk.
2) If it finds any of those libraries, it will use the system/builtin version of those libraries. If not, it can use the ones bundled with ppsspp;
3) Have a CMake argument to specifically enable building with the bundled versions of those libraries, even if the system/builtin ones are found;
4) Document somewhere, in the README, on the website, or wiki, that this package needs GCC >= 4.6;

I'll wait to hear what you have to say about those compiler flags before continuing to test.

Thanks,
Find all posts by this user
Quote this message in a reply
12-02-2012, 11:48 AM
Post: #23
RE: official source tarball (NOT git)
You won't need libzip on desktop, it's only used on Android.
Find all posts by this user
Quote this message in a reply
12-25-2012, 11:18 AM
Post: #24
RE: official source tarball (NOT git)
(12-02-2012 11:48 AM)Orphis Wrote:  You won't need libzip on desktop, it's only used on Android.
That's not relevant. pkgsrc is getting to a point where it will be able to cross build packages. Nothwithstanding, what i said in my previous post about library detection is still pertinent.
Find all posts by this user
Quote this message in a reply
02-07-2013, 05:21 PM
Post: #25
RE: official source tarball (NOT git)
Hi,

I haven't had much time to follow this recently, but did have a few minutes today. I'm still wondering why you're including things like cityhash, zlib, libzip, snappy, and glew. All of these package have shared libraries and it's really not necessary to bundle them with the package, only find them during configure and link to them during the linking stage. Even sha1 is on most systems, and rapidxml can be provided as a package (at least in pkgsrc). All you'd have to do is look for it in the system paths rather than looking for it in native/. There's really no reason for this package to have a dependency on git. Rather, consider bundling only what's necessary in your native/ directory in the distfile.

The build of 0.6.1 fails when trying to find cityhash, which we have installed as a shared library (with the city.h in include/). I would recommend just bundling etcpack, stb_image, stb_vorbis, and libkirk for the time being.

Best regards,
Find all posts by this user
Quote this message in a reply
02-07-2013, 06:50 PM
Post: #26
RE: official source tarball (NOT git)
There is one very good reason to include them - most contributors, including me, develop on Windows and there's no sane dependency management there. Sorry about that, but there's not really any way around it. I can't require everyone to manually install all this stuff to build.

Also, the mentioned libraries are all very small and I don't find them a nuisance to have them in the git, it's not like we're gonna upgrade them all the time.
Find all posts by this user
Quote this message in a reply
02-08-2013, 01:53 PM
Post: #27
RE: official source tarball (NOT git)
(02-07-2013 06:50 PM)Henrik Wrote:  There is one very good reason to include them - most contributors, including me, develop on Windows and there's no sane dependency management there. Sorry about that, but there's not really any way around it. I can't require everyone to manually install all this stuff to build.

Also, the mentioned libraries are all very small and I don't find them a nuisance to have them in the git, it's not like we're gonna upgrade them all the time.
Well, can you at least add a test in configure to look for the files in the system first before falling back to finding them in native/? Can you bundle native/ in the source tarball instead of requiring the dependency on git to fetch them? I'm rather interested in this package after having successfully ported yaupspe.
Find all posts by this user
Quote this message in a reply
02-08-2013, 02:26 PM
Post: #28
RE: official source tarball (NOT git)
If you look in the tarball ( ppsspp.org/files/ppsspp-src-v0.61.tar.gz ), you'll find that native is already included in it.

I don't know how to make such a test, feel free to send a pull request. I'm focusing on developing the emu, not the build system, I rely on contributions for building the emu on other platforms than Windows and Mac.
Find all posts by this user
Quote this message in a reply
03-02-2013, 12:42 PM
Post: #29
RE: official source tarball (NOT git)
(02-08-2013 02:26 PM)Henrik Wrote:  If you look in the tarball ( ppsspp.org/files/ppsspp-src-v0.61.tar.gz ), you'll find that native is already included in it.

I don't know how to make such a test, feel free to send a pull request. I'm focusing on developing the emu, not the build system, I rely on contributions for building the emu on other platforms than Windows and Mac.
Sorry, i was using the 0.6.1 tarball from the github, as that source file you referenced wasn't mentioned on the homepage. I've created a simple patch (i'm not really good at CMake) that finds GLEW, sha1, cityhash, zlib, and snappy and falls back to the bundled versions if they're not found. I will eventually modify it to search for RapidXML and libzip too. When the build works well (everything links correctly), i'll send this patch to you for review.

However, the build is still failing in the same place. Check this log:

http://pastebin.ca/2327352

the command from where came that error is:

/usr/pkgsrc/wip/ppsspp/work/.gcc/bin/g++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED -D__BSD_VISIBLE=1 -mfpmath=sse -msse3 -march=native -I/usr/pkgsrc/wip/ppsspp/work/.buildlink/qt4/include -I/usr/pkgsrc/wip/ppsspp/work/.buildlink/include -I/usr/pkgsrc/wip/ppsspp/work/.buildlink/include/freetype2 -I/usr/pkgsrc/wip/ppsspp/work/.buildlink/lib/libzip/include -I/usr/pkgsrc/wip/ppsspp/work/.buildlink/gcc46/include -I/usr/pkgsrc/wip/ppsspp/work/.buildlink/gcc46/lib/gcc/x86_64-unknown-netbsd6.0.1/4.6.3/include -std=c++0x -I/usr/pkgsrc/wip/ppsspp/work/ppsspp -I/usr/pkgsrc/wip/ppsspp/work/ppsspp/Common -I/usr/pkgsrc/wip/ppsspp/work/ppsspp/native/ext/etcpack -I/usr/pkgsrc/wip/ppsspp/work/ppsspp/native/ext/stb_image -I/usr/pkgsrc/wip/ppsspp/work/ppsspp/native/ext/stb_vorbis -I/usr/pkgsrc/wip/ppsspp/work/.buildlink/qt4/include/QtOpenGL -I/usr/pkgsrc/wip/ppsspp/work/.buildlink/qt4/include/QtMultimedia -I/usr/pkgsrc/wip/ppsspp/work/.buildlink/qt4/include/QtGui -I/usr/pkgsrc/wip/ppsspp/work/.buildlink/qt4/include/QtCore -I/usr/pkgsrc/wip/ppsspp/work/ppsspp/native -I/usr/pkgsrc/wip/ppsspp/work/ppsspp/native/ext/rapidxml -I/usr/pkgsrc/wip/ppsspp/work/ppsspp/ext/libkirk -Wno-multichar -fno-strict-aliasing -ffast-math -Wno-psabi -msse2 -o CMakeFiles/Common.dir/Common/ABI.cpp.o -c /usr/pkgsrc/wip/ppsspp/work/ppsspp/Common/ABI.cpp -L/usr/pkgsrc/wip/ppsspp/work/.buildlink/lib

Any ideas/suggestions? I end up patching a lot of C/C++, but am not really good at it nor keep up with all the latest standards. I know you're focused more on correct emulation. Perhaps, one of your other devs who is more involved with the build could check this if you don't have time?

Thanks,
Find all posts by this user
Quote this message in a reply
03-03-2013, 12:00 PM
Post: #30
RE: official source tarball (NOT git)
Sounds good!

File a pull request or just an issue on our github page with that, it will get more attention than here in the forum.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump: