One of the most annoying things I’m starting to see are bogus way to check for presence of compilers or lib for SPU support…
Since it is almost the last day of the year here the top annoying pratices list:
– misnaming: ppu- isn’t a valid prefix, powerpc64-unknown-linux-gnu- is, anyway if is the native compiler gcc would do perfectly, if isn’t someone would provide it to configure so. PLEASE AVOID PPU-
– misnaming: spu- could be a partially valid prefix, _maybe_ spu-elf- is the correct one . TREAT SPU AS A CROSS TARGET, ALWAYS.
– bad assumption: I may have a valid spu compiler but _MAYBE_ I didn’t registered elfspe or elfspe2 on binfmt so I cannot automagically run spu binaries or maybe I don’t have spufs mounted. TREAT SPU AS A CROSS TARGET, ALWAYS.
– picking cflags from env: the spu-elf-gcc and the native gcc may not share the same cflags, make sure your configure could pick CFLAGS_{powerpc,powerpc64,spu} as they fit.
– hardcoding paths: the ibm and the sony sdk are for non native system with non default cross paths, I know beside gentoo and few other crazy people nobody is using alternate paths, still since maybe native system should be expected and _maybe_ less custom paths could appear, please do not hardcode /opt/${STI_SDK}/blah as include/lib path in your applications or applications patches (like the one for lame). PLEASE KEEP THINGS CLEAN.
Here a top5, luckly there aren’t that many annoyances =)
Have a great new year.