Suggested change to psp-config: symlink expansion

[zino]

Rational:

I would like psp-config to expand symlinks so that the real installation directory is found. I use a package system that installs several versions of sofware in parallell and offer a symlink form to the default version of those packages. unwinding the symlink makes the psp-config work in my setup.

Suggested change (minus the huge comment):

--- tools/psp-config.c.orig 2005-06-29 23:34:23.000000000 +0200
+++ tools/psp-config.c 2005-06-29 23:35:51.000000000 +0200
@@ -135,6 +135,11 @@
int suffix_len;
int path_len;

+ /* unwind links to get to read installation, allowing
+ for several installation with links to the default
+ one from for example /usr/local */
+ while(readlink(path, path, MAX_PATH) != -1);
+
suffix_len = strlen(PSPDEV_PATH_SUFFIX);
path_len = strlen(path);

[mrbrown]

Hmm, Ok. Once I figure out how to make it portable I'll put it in. Thanks.

[mc]

psp-config is already unportable, since it uses getopt_long...

I use a simple shellscript instead.

[mrbrown]

psp-config is already unportable, since it uses getopt_long...

I use a simple shellscript instead.

And which systems don't have getopt_long()?

[mc]

Solaris < 10 for sure. I'd _assume_ that IRIX, AIX, UNICOS et al don't have it either, but my test machines seem to be inaccessible at the moment. getopt_long() is a GNUism to begin with.

[Guest]

Ok, I am a big fan of Solaris. But my god, who the heck develops homebrew ps2dev on Solaris, Irix, AIX, or...unicos ? :) Solaris I can almost see due to its widespread popularity as a commercial OS, but Irix is almost dead, and AIX tends to be on more expensive servers and the rare workstation.

[mc]

I do. Solaris 9.

[Nick Fury]

It's time you discovered an updated OS my friend.

[crazyc]

getopt_long is in libiberty.a if your platform libc doesn't have it. That goes for mingw also, as msvcrt lacks getopt_long (and getopt also).

[mrbrown]

We'll come up with something. readlink() won't be used unless it was detected at configure time, and getopt_long() may be replaced, dunno yet.

[mc]

Seing as only one option is supported anyway, it shouldn't be a major issue to do without the call to getopt_long()... :-)

Code: Select all

/* Process the arguments */
int process_args(int argc, char **argv)
{
    int i, ret = 0;
    g_printpath = 0;

    for&#40;i=1; i<argc; i++&#41;
         if&#40;!strcmp&#40;argv&#91;i&#93;, "-p"&#41; || !strcmp&#40;argv&#91;i&#93;, "--pspsdk-path"&#41;&#41;
         &#123;
             g_printpath = 1;
             ret = 1;
         &#125;
         else
         &#123;
             fprintf&#40;stderr, "Invalid option '%s'\n", argv&#91;i&#93;&#41;;
         &#125;

    return ret;
&#125;

Hm, I need to make a proper patch for the endian conversion code in (un)pack-pbp.c too. It uses "NXSwapInt()" without defining it...

[mc]

It's time you discovered an updated OS my friend.

I see you are making a valuable contribution to making the SDK more portable. Keep up the good work.

[mc]

getopt_long is in libiberty.a if your platform libc doesn't have it.

Yes, but the SDK does not link against libiberty. This can be fixed of course, but since libiberty might not be installed either, a better idea might be to include the getopt_long source from libiberty into the PSPSDK distro, and compile it if needed. libiberty is LGPL, so it should be possible (I haven't studied the AFL which the SDK is under to see if it's compatible though).

[mrbrown]

libiberty is LGPL, so it should be possible (I haven't studied the AFL which the SDK is under to see if it's compatible though).

PSPSDK is actually BSD-licensed :). Yeah, I was thinking of just grabbing the source to getopt_long(), but anyone else is welcome to step in and fix it.

[mc]

I can do it if you give me write access. ;-)

Here's a patch for the endianness issue with (un)pack-pbp.c:
endian.patch

config.h.in will have to be regenerated too (is it a mistake that it is under version control? I expect so...).