Makefile structure patch and ps2cam.irx patch

ragnarok2040 · Post by **ragnarok2040** » Mon Jan 19, 2009 2:34 am

I had some time on my hands so I went through all the Makefiles, sample Makefiles, custom Makefiles, bbq'd shrimp Makefiles, etc. in ps2sdk, and modified the rules a bit and changed some variable names around so that CFLAGS could be used both when building object files and when linking. LDFLAGS can now properly be used for just link options, instead of as a redundant CFLAGS when linking. I'm pretty sure I got everything, both EE/IOP, and all their samples. I changed some IOP rules so -c wasn't needed for a CFLAG. All changes based on rev. 1515 of ps2sdk after radad's changes :D.

I also included some changes to the iop/usb/camera project so it can build now. I added a Makefile, imports.lst, and irx_imports.h. I fixed the warnings with it as well. Judging by the header, some functions can be exported for use, but I didn't make an exports.tab because it already has an EE-side rpc client.

They're separated into two separate patches, makefile.patch and ps2cam.patch. I can apply the makefile.patch cleanly, but the ps2cam patch always applies with a fuzz of 1 for iop/usb/Makefile. It's probably a line ending issue. Also, when it's applied, "imports.c" and "ps2cam.h" need to be removed from the src directory otherwise building will fail.

http://homebrew.thewaffleiron.net/ragna ... hes.tar.gz

radad · Post by **radad** » Mon Jan 19, 2009 10:27 am

Isnt the '-c' option necessary to stop it attempting to link?

In ee/rpc/audsrv/sample/Makefile you have removed the link flags, they should probably be included as well. Actually can this makefile be changed to use the standard sample makefile include to keep things consistent?

Looking through the gcc documentation its not clear to me whether -fno-builtin should be a compile flag or a link flag?

The changes in ee/loader/Makefile are not necessary, these are definitely link flags.

You uncommented a line in ee/Rules.make, again thats not necessary, its setting a variable to itself.

In samples/Makefile.eeglobal_cpp_sample you have included the c flags on the link line but you havent included the c flags on the compile lines.

Generally though, it shouldnt be necessary to include c flags and link flags on the link line should it? Flags are either definitely for the link stage or the compile stage and not both.

ragnarok2040 · Post by **ragnarok2040** » Mon Jan 19, 2009 10:36 pm

Isnt the '-c' option necessary to stop it attempting to link?

Yes, but I put the -c flag in the rules for the object files, similar to the way EE's .o rules are written, and the -c flag when needed for projects like tcpip and such that have some custom rules for object files.

In ee/rpc/audsrv/sample/Makefile you have removed the link flags, they should probably be included as well. Actually can this makefile be changed to use the standard sample makefile include to keep things consistent?

I looked at audsrv's sample Makefile, and it's designed to compile multiple elfs. Since there are multiple samples, I'll create a directory for each one, give them their own standard Makefile and modify the Makefile to install them to rpc/audsrv directory in the $(PS2SDK)/samples directory.

Looking through the gcc documentation its not clear to me whether -fno-builtin should be a compile flag or a link flag?

The "-fno-builtin" flag is a C dialect flag as it controls how gcc optimizes code around their builtin functions. I'm not sure when this optimization occurs, when linking or during the compiling of object code, probably both, but it can't be good not to have it consistently defined during both stages. Judging by wine and other projects, they put it as a CFLAG.

The changes in ee/loader/Makefile are not necessary, these are definitely link flags.

Oops, I was testing -L as a CFLAG and forgot to revert my changes before the patch :D.

You uncommented a line in ee/Rules.make, again thats not necessary, its setting a variable to itself.

True, I think that line is just there for a placeholder in case any custom LDFLAGS are ever needed. I'll just leave it commented, then.

In samples/Makefile.eeglobal_cpp_sample you have included the c flags on the link line but you havent included the c flags on the compile lines.

I'm not sure why I did that, since it invokes g++ it should only have the cpp flags there. I must've changed it thinking it was Makefile.eeglobal for some reason and didn't notice that I'd already put cpp flags there. I had quite a few gedit windows open at the time.

Generally though, it shouldnt be necessary to include c flags and link flags on the link line should it? Flags are either definitely for the link stage or the compile stage and not both.

I thought so, too, but the GNU coding standard indicates that the same CFLAGS should be used whenever gcc is invoked, the same for CXXFLAGS and g++, whether it be when compiling or linking.

CFLAGS should be used in every invocation of the C compiler, both those which do compilation and those which do linking.

I'm pretty sure it's because of flags like "-fno-builtin" and similar that have an effect on gcc's code generation.

New patch:
http://homebrew.thewaffleiron.net/ragna ... hes.tar.gz

I removed the changes to ee/loader/Makefile, removed the cflags from samples/Makefile.eeglobal_cpp_sample, and kept the commented EE_LDFLAGS line in ee/Rules.make.
I added a samples directory in ee/rpc/audsrv that separates all of audsrv's samples into their separate directories and made Makefile.sample's and Makefiles for each of them.
Audsrv's samples will now be installed to $(PS2SDK)/samples/rpc/audsrv.
The "evillaugh.wav" file in ee/rpc/audsrv/sample needs to be placed in ee/rpc/audsrv/samples/playadpcm directory and then the old sample directory can be removed.

radad · Post by **radad** » Thu Jan 22, 2009 7:50 pm

Commited rev. 1522.

I noticed you included C_FLAGS on the link line for C projects and CXX_FLAGS and the link line for CXX projects but what if you have both C and CXX in one project?

ragnarok2040 · Post by **ragnarok2040** » Fri Jan 23, 2009 2:28 am

I'm not quite sure. There's only a brief mention of it in the standard. It's pretty much up to the person doing the mixing, I think.

Since C++ is a superset of C, my method is to define EE_CXXFLAGS as "EE_CXXFLAGS := $(EE_CFLAGS) -fno-exceptions -fno-rtti ..." etc. If, for some reason, there's a problem with that (I haven't encountered any), I'd just copy the CFLAGS I really want to CXXFLAGS. Another way would be to define another variable to put common flags there and have CFLAGS and CXXFLAGS both take its definition as well. But that's just me, and I haven't done much mixing, :D. I generally just modify any C code I have so it compiles with g++.

I think if someone were mixing C and C++ code, they would probably want a custom Makefile.eeglobal_cpp as well in order to define a custom rule for linking. The current way it's setup does allow some flexibility, though.