On Thu, 2010-01-07 at 09:08 -0800, Peter Naulls wrote: > Just some observations as a follow on from IRC discussion: > > Any symlinks probably need to be entirely in RISC OS format. This > is because other non-UnixLib components (such as various modules > or even RISC OS itself) might try to use them in future. Such > an enforcement might require some assumption changes in UnixLib.
That should be fine, providing that arm-unknown-riscos-ln performs the appropriate path munging when invoked on a unix host. I really don't want to have to add even more special casing for RISC OS in my buildsystem. > Cross compiled libraries will almost always have Unix format > sonames and symlinks, since they'll come out of existing > build systems for Unix. But we might occasionally see RO > format sonames, for whatever reason - e.g, native Makefiles. Given that sonames are essentially just a string, it probably makes life simpler all round if we just specify that they should be unix format. As I've already said, RO format sonames simply don't work at all right now. > symlinks via SunFish are just viewed as the file itself. This is > mostly of consequence in development rather than deployment. Well, that'd be an issue for SunFish, surely, and thus mostly orthogonal to the issue of generating RO symlinks on a Unix host. Note that, if I'm installing into a cross-compilation environment, I'd expect native symlinks to be generated. With my buildsystem, this is achieved by it using the native ln by default. If I'm actually generating a package to be installed on RO, I simply override LN in the environment. I'm pretty sure the exact same thing can be achieved for most autoconf-based buildsystems. > We can put extra logic in the package generation and library > packaging easily enough to properly ensure RO style symlinks > and RO format filenames in the symlinks should that be required. > 'zip' itself has some unhelpful behaviour here, so any checking > we do would be good. I'm not sure that I see a problem with zip in this case: on a unix host, RO-style symlinks, as generated by arm-unknown-riscos-ln, are just normal files. Thus, zip shouldn't ever have a problem with them. > For the sake of clarity to anyone who is not familiar, the > RISC OS symlink setup is more akin to the Windows ".lnk" file > than the Unix symlink file, and so a RISC OS symlink generated > under Unix will be an explicit file, ideally with a ,1c8 > extension. Well, that's another thing for arm-unknown-riscos-ln to be doing :) Upon reflection, I'm pretty sure that all of the problems I had can be solved by making ln more intelligent wrt paths. J. _______________________________________________ GCCSDK mailing list [email protected] Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
