Build system gets confused if IOP_BIN is set in the environment

[uucidl]

The PS2SDK default Makefiles proceed to run if the user has set a IOP_BIN variable in the environment, but may have unexpected results.

For instance doing:

export IOP_BIN=

before running the makefiles, will result in iop targets not being built.

[uyjulian]

That will be fixed in the Makefile rewrite coming this weekend.

[sp193]

But what does that mean? What is the purpose of setting IOP_BIN globally? Why doesn't it work when it's set? Perhaps it will cause those Makefiles that conditionally set IOP_BIN to get confused. But isn't that its function, to allow IOP_BIN to be overridden?

[uucidl]

@sp193 let me describe what happened.

I downloaded ps2sdk, then thought, hum I must ensure the iop and ee binaries are in the path somehow. So I did this:

export IOB_BIN=<path-with-iop-binaries>
export EE_BIN=<path-with-ee-binaries>
export PATH=$IOP_BIN:$EE_BIN:$PATH

Basically at that point I had completely forgotten that IOP_BIN was used somewhere in the ps2sdk Makefiles.

Then I attempted to compile ps2sdk, which lead to a weird error.

Then I turned IOP_BIN "off" by doing export IOP_BIN= (my mistake was to think this would act as if the variable had been unset)

At that point when recompiling the ps2sdk, it looked like it had succeeded but then I got a weird error about an irx missing. This is when I opened the Makefile for that target that I noticed the IOP_BIN ?= and it struck me.

Now as to whether environment variables are a good UI for interacting with a build system. I find that they're good to communicate something about the environment, say, where the toolchains are, or which compiler to use or to add additional flags. But essential aspects like the target name? I'm not so sure. And even then I'd suggest the Makefile to require an explicit override in the command line, like so:

make TARGET_OUTPUT_FILENAME=<foo> <target>
# i.e. not TARGET_OUTPUT_FILENAME=<foo> make <target>

with

TARGET_OUTPUT_FILENAME=<canonical_name>
# instead of TARGET_OUTPUT_FILENAME?=<canonical-name>

[uyjulian]

Did you not follow the instructions in ps2toolchain?

[uucidl]

I got the toolchain for win32 from another source, I think it was emoon. (I'm developing on windows)

[uyjulian]

Follow the instruction in ps2toolchain, or you can follow this tutorial:
http://psx-scene.com/forums/f19/quick-dirty-tutorial-install-ps2sdk-windows-subsystem-linux-2017-a-157028/

If you are using mingw32, things may or may not work. It's best to use WSL to have a consistent environment.

If you are referring to this: https://github.com/emoon/ps2dev_tools then things may not work correctly. It hasn't been updated in 7 years.

[TnA-Plastic]

Even tho' you already closed the issue, I thought I would add some more informations...

The WSL-Tutorial is a bit outdated. I wrote it in the infancies/beginning of WSL (~half a year after it's Beta-Introduction in the insider-builds...)!

A lot of it got easier: -WSL and Ubuntu (or other distributions) can be easily installed (via Windows-Features and the Market) -the initial (root-)user-config got quite automated and easier -etc.

Since you closed this issue, I suppose you succeeded. ;) You might also take a look at the optional things to install, like a Dual-Desktop (Windows + Linux), or running ELF64-Linux-Apps in Windows on Windows + Links to it, like to EXEs, etc.

AFAIK, WSL (and thus these visuals) are currently not (yet) hardware-accelerated, but... oh well... I can watch YT, via Firefox in it (on a 2008-PC) so it is not so slow...

[uucidl]

@TnA-Plastic I appreciate the help given. Maybe info could be moved to a document in the ps2toolchain and ps2sdk with up-to-date info?

[TnA-Plastic]

Well, the info would need to be updated for any environment, where all that stuff is installed into (WSL, LINUX, MSYS, CYGWIN, ETC.), so I think it is better to keep these tutorials to the various boards/forums. ;)

On another note: The other features I've mentioned and how to set them up, are also all included in the WSL-Tutorial!

[sp193]

I have made a modern pre-built MinGW package, available for download from the ps2toolchain releases page.

[uucidl]

Thanks @sp193 that's super helpful :)

[TnA-Plastic]

Is it possible to autobuild a mingw/msys-package (via a script), without too much hastle/work involved?

[sp193]

The script set is ps2toolchain. The problem is that you need to find an old version of MinGW today, since it somehow now has the same problem as Cygwin: compiling GCC stage 2 will result in an Internal Compiler Error (ICE) in haifa-sched.c.

Then of course, Windows users like me may prefer to not waste time in struggling with dependencies and building stuff, so the solution here is a pre-built package.

[uyjulian]

Of course, with pre-built stuff, not all of the features and optimizations of your processor may be used, so it may be slower on other architectures.
Also, on Windows, filesystem access times, process launching times, and forking times are much slower compared to other POSIX-based systems.
With WSL, Vagrant, or Docker, you can get a consistent environment, so it is easy to recover from a bad Windows 10 update. Also, if you have any problems, it is much easier for other people to assist you, since you have the same environment.

[sp193]

Yes, but it'll work out of the box. There are only two architectures for the PC anyway: i686 and amd64. The amd64 target (MinGW/Cygwin target) is not supported by our old toolchains and I cannot imagine how we'll make it build properly anyway (due to the issues that new MinGW & Cygwin releases have with correctly building our GCC).

Just because the tools are meant for *nix, does not mean it is always worth the hassle to install yet another OS. I won't go into the details here, but sometimes it is just more convenient to work from Windows. Like if you want to make one build.

Another reason why I am for a pre-built binary, is so that it'll likely work out of the box. No need to worry about whether you got the right tools for building it, and spending an hour, waiting for MinGW to build things slowly. The only likely way (IMO) for this to not work, is that MinGW's libraries become incompatible with Windows, maybe in the distant future (i.e. like how Windows 95 software may not work well on Windows 7). Even if it does happen, we have WSL. So this release is more for users of Windows 7 & 8, which do not have WSL.

[uucidl]

By the way I got the toolchain to work without really having to go inside msys, by simply adding the msys /bin directory into the PATH and then using ee-gcc.exe, iop.gcc.exe etc. This makes it easy to use from anywhere

[sp193]

Some people do that. I used to do that in 2010 when I was still using a Pentium III, since the MSYS shell is slower than CMD. However, the MS-DOS shells are not always compatible with the POSIX stuff, so beware.