gsKit with some bugfixes, features, and stuff

[dlanor]

I'm not sure what you mean when you say my method conflicts with established usage of PS2SDK. I follow the FHS

Perhaps I'm completely ignorant of established usage of others, but I am not aware of how this standard "should" be applied to PS2 development setups. Never heard of that before...

as best I can when managing my ps2dev tree. All the projects' source releases go into ps2dev/src with them mirrored in ps2dev/src/clean in case I taint any source in some non recoverable way, where 'svn revert -R *' doesn't work. As far as I know, it's impossible to mess up the functionality of any project by doing that unless it has no 'install' or 'release' rule.

The large majority of PS2 projects that I've seen follow extremely lax practice, and do indeed have no 'install' or 'release' rules whatsoever.

gsKit depends on this standard,

That was the basis of my objection. Using that standard is one thing, making an existing project dependent on it, which it was not in earlier versions, is another thing.

This means that users of the existing versions will have problems upgrading now, since their setup does not conform to the new requirements.

I am not really objecting to using this standard, but merely saying that it must be clearly documented, so that no one can miss it, that people need to impose this standard on their existing setup, before they can use your updated lib properly.

Best regards: dlanor

[ragnarok2040]

gsKit was dependent upon the destination and source directories not being the same before I touched the source, the only thing I neglected to do was to either comment the PS2DEV variable, remove it, or change its definition back to /usr/local/ps2dev. radad's already fixed the Makefile.pref so PS2DEV isn't changed if it's already defined, though.

I didn't touch the 'clean' or 'install' rules in any of the Makefiles at all, except to add libgskit_toolkit.a as one of the files to install, so LIBGHSI's problem with doing "make install" to install from /usr/local/ps2dev/gsKit to /usr/local/ps2dev/gsKit should've appeared with older versions of gsKit as well. cp will always error out when asked to copy from SOURCE to DEST if both paths are the same, even with the --update flag.

I only suggested looking at the standard because it's a simple way to keep things in order and not encounter problems. The only part that really needs to be read is the part about the /usr/local directory.

LIBGHSI, is there anything you want implemented? Like an install rule for the examples or something? I'm not sure what the reasoning is behind needing both the binaries and source in the same directory.

[cosmito]

I'm not sure what the reasoning is behind needing both the binaries and source in the same directory.

I believe the issue is that many people (at least some, me included) wasn't aware of the beneficts of have the distributions kept separate. Has you pointed out, it's a must for the sdk itself and that's why I would like to see the recommendation mentioned at the toolchain README or additionally done by the toolchain script by checking out the source to a dedicated folder (ps2sdksrc for example).

These good pratices should be clear for ps2sdk starters and nothing better than a README file to assure this information. Worst is getting posts about some irx or lib that makes the screen blank or crashes the PS2 due to an unhealthy sdk...

[dirsors]

I'm having trouble compiling SDL and I guess it has something with this new version of gsKit since before the 'update' everything was working.
gsKit compiles OK, but after this

Code: Select all

svn co svn://svn.ps2dev.org/ps2/trunk/ps2sdk-ports/sdl
cd sdl
make all install

I'm getting this:

Code: Select all

video/ps2sdk/SDL_ps2video.c:172:70: macro "gsKit_init_global" passed 1 arguments, but takes just 0
video/ps2sdk/SDL_ps2video.c: In function `PS2_VideoInit':
video/ps2sdk/SDL_ps2video.c:172: `gsKit_init_global' undeclared (first use in this function)
video/ps2sdk/SDL_ps2video.c:172: (Each undeclared identifier is  reported only once
video/ps2sdk/SDL_ps2video.c:172: for each function it appears in.)
make[1]: *** [video/ps2sdk/SDL_ps2video.o] Error 1
make[1]: Leaving directory `/home/usr/sdl/src'
make: *** [all-src] Error 2

also, gsKit installs on c:\msys\1.0\local\ps2dev\gsKit instead of C:\msys\1.0\local\ps2dev\ps2sdk\ports\gsKit

[LBGSHI]

As cosmito said, the main problem was simply lack of documentation concerning the separation of source and compiled libs. Some libs will compile without incident in the same directory, and work perfectly, while others (gsKit included) will not.

I also agree with cosmito that a simple ReadMe section consisting of a standard of sorts for organization of the SDK, particularly in terms of separation of source and compiled libraries, would suffice.

And...my name is LBGSHI :)

[ragnarok2040]

I changed the gskit_init_global() function because the mode argument is no longer needed, since it has integrated auto mode detection for PAL or NTSC interlaced field mode, which are the modes most used by legacy gsKit apps. The easiest fix is to change the macro in the gsInit.h header to define gskit_init_global() as gkit_init_global(mode). I also listed some methods to fix SDL's auto mode support at http://forums.ps2dev.org/viewtopic.php?t=11573. I also included an explanation of how to set custom video modes using gsKit, in case anyone wants to modify SDL's underlying implementation for more variety. That explanation could probably be copied and pasted into the FAQ thread as well, since it applies to all gsKit development, generally.

also, gsKit installs on c:\msys\1.0\local\ps2dev\gsKit instead of C:\msys\1.0\local\ps2dev\ps2sdk\ports\gsKit

gsKit installs to its own directory because it's a separate unique library for the PS2 and not a ported library. The README states that it was originally planned for gsKit to be integrated with ps2sdk, after it was done, but it's still incomplete. I believe the original author is still working on VU0/VU1 support. More info here, http://forums.ps2dev.org/viewtopic.php?t=7856. Coding for them actually looks somewhat similar to programming shaders from what little I've seen of that in Wine's code.

These good pratices should be clear for ps2sdk starters and nothing better than a README file to assure this information.

I agree, but it's generally for users of MSYS especially. There should be a explanation of why such standards exist as well, so I'll try as best I can to explain. Perhaps it can also be copied and pasted into the FAQ thread.

In Linux, compiling can be a fickle issue, as "make" can execute shell commands from Makefiles, like "mkdir" "cp" "rm", so you never do it as a superuser or with superuser privileges unless absolutely neccessary. The various rules in a Makefile have the possibility of passively creating root-only permissions on files or directories or destroying critical system files without error because every command in the Makefile would be all separate processes using superuser credentials. The FHS details proper directory permissions, but, to skim it down for ps2dev, this generally means you never compile inside of the /usr/local/ps2dev directory which is owned by root. This requires always compiling in a user owned directory, and then using "su" or "sudo" to "make install" as the final step. For most people, they usually get used to doing most things within directories under their $HOME directory as that's where they have permission to create/move/modify files without hassle. Some PS2 projects probably don't adhere to this as the developers have probably used "chown" to change the owner of /usr/local/ps2dev to their user account which is a bad practice. This is because the root-only write permissions keeps the ps2dev environment unchanged unless installing ps2sdk releases or gsKit releases, limiting changes to the basic sdk and toolset. I believe Cygwin emulates all of this as well but it's been years since I tried it and it's not a supported platform anymore for ps2dev.

MSYS, when I used it, didn't implement support for root/group/user permissions so it's like you're always "root". Running "make" in MSYS is simpler because all permissions are the same and generally only affect files and directories in the C:\MinGW directory, although the entire Windows filesystem is accessible by using /c. With uniform permissions, though, you never get used to being "jailed" in $HOME so new users build generally everywhere which kind of makes the hierarchy messy after a while. There's also no "stop and think" chances when issuing commands so you have to be careful, but problems with permission errors will generally never happen, except on Vista, like for programs or scripts with "install" in their name. If something does break, you can always reinstall.

I hope that's kind of understandable and I think I've covered the basics.

And...my name is LBGSHI :)

Oops, sorry about that, LBGSHI, :D. I guess I sorted GH alphabetically.

[LBGSHI]

Oops, sorry about that, LBGSHI, :D. I guess I sorted GH alphabetically.

And turned me into a library [LIBGHSI] :)

No problem. Yes, we should add that, and probably a concise sentence of instruction ("Compile gsKit in a directory other than ps2dev, preferably in a directory you've set aside to compile other libraries, where you keep copies of their respective sources, such as local/ps2dev/libsrc").