PCSX2 Daily development builds
#21
Is it feasible to have linux builds of pcsx2 in Orphis?
Reply

Sponsored links

#22
(06-05-2011, 05:08 PM)pcsx2fan Wrote:
Code:
del pcsx2.exe

attrib +h plugins\*-r*.dll
del /Q plugins\*
attrib -h plugins\*

Why not just "del plugins\*-r*.dll" ? And If I haven't done it, that's because I think it should be fixed in the solution and that an automated process should create the release folder ready to archive.

And a Linux build is possible, although, redistribution of a Linux software is problematic as it needs to be static. It's better to rebuild it on your computer everytime, once the initial setup is done, it's quite easy to do. A simple utility shell script might help though.
Reply
#23
(06-06-2011, 04:35 PM)Orphis Wrote: Why not just "del plugins\*-r*.dll" ? And If I haven't done it, that's because I think it should be fixed in the solution and that an automated process should create the release folder ready to archive.

i believe the duplicate plugins/exe is done on purpose.
the version without the revision number is handy for devs so they can recompile their plugins and have pcsx2 always load the latest one with the same name w/o having to configure pcsx2 to use the new revision number every commit.

the pcsx2.exe w/o revision number is useful for shortcuts and w/e scripts someone has.
anyways its not going to be fixed in the solution because it was intentional and has its uses.
Check out my blog: Trashcan of Code
Reply
#24
I agree with you, it has some clear benefits to have the duplicate plugins and that's why I didn't change or really complained about it. Only the users do Tongue2
Reply
#25
its absolutely unneccessary duplication and can be resolved in the project file by creating a second release profile
Reply
#26
And it needs to be maintained too and that's unnecessary duplication too.
It doesn't hurt in any away, you can still select whichever plugin you want and it adds new functionality as you don't have to rename the plugins to have multiple versions side by side in the same folder and you've got a sure way to use the latest one (if you only put newer versions in the folder).
Reply
#27
(06-06-2011, 04:35 PM)Orphis Wrote: And a Linux build is possible, although, redistribution of a Linux software is problematic as it needs to be static. It's better to rebuild it on your computer everytime, once the initial setup is done, it's quite easy to do. A simple utility shell script might help though.

Orphis, sorry to bring you of windows builds topic, but how about a shell script that automates generation (build?) of a source code tarball from svn releases. Could this tarball be made available in your site by this bot?
Reply
#28
I don't want to release a tarball of the source code. It's too big and can be easily retreived from the svn repository.

To build pcsx2 on Linux, I *guess* you'll need something like "svn checkout -r 1234 http://pcsx2.googlecode.com/svn/trunk/ pcsx2 && cd pcsx2 && cmake && make". I haven't tried to do it, or ever compiled pcsx2 on Linux, but there should be a guide somewhere telling you the right steps.
Maybe a "make clean" could help, maybe you'll need to pass some options to cmake.
Of course, you also need to install what you need on your distribution first to build pcsx2.
Reply
#29
(06-08-2011, 12:15 PM)Orphis Wrote: I don't want to release a tarball of the source code. It's too big and can be easily retreived from the svn repository.
If size is the major problem, gregory made a fine piece of script that gets the source and remove uneeded stuff for linux compilation and the result is a 3.6MB tarball - same size as the windows binaries in your site.

Steps to reproduce:
- Get "create_pcsx2_tarball_from_svn_repository.sh" from /trunk/debian-upstream/
- execute it with "4715" as argument
- the result is "pcsx2_0.9.8.orig.tar.gz" with 3.6MB

(06-08-2011, 12:15 PM)Orphis Wrote: To build pcsx2 on Linux, (...)
I know, thanks. I'm the packager of PCSX2 for Archlinux (here). In matter of fact, it would help me a lot have a tarball available online to use in my package's build script (PKGBUILD).
Reply
#30
I personnaly agree with Orphis. It would take lots of room for little value. How does others package work inside Arch. Few project create tarball snapshot of repository. The few one that do it, only keep the latest one. On debian, package are directly sync on the repository. Some directly package the repository (so the package contains all metadata of the db), others create a tarball from it. IMHO, looking how work similar snapshot package will be a good idea.

By the way I really need to improve this script, I can probably shrink the size of 33%
Reply




Users browsing this thread: 1 Guest(s)