In message <[email protected]> Peter Naulls <[email protected]> wrote:
> I understand where you're coming from. But in practice env/bin contains > mostly things which are used for builds - a lot of it library config > scripts, etc. It does also contain a number of RISC OS binaries, > but their presence there is of questionable use. These are mostly > things that are library utilities, and got installed along with them. I don't think we should fight common conventions to repurpose $PREFIX/bin in builds using cross-compiler by placing native build tools there. A 'make install' installs binaries in $PREFIX/bin and those binaries are in our case RISC OS ones. Let's not contaminate that directory with host binaries. We should not have $PREFIX/bin in our PATH during Autobuild builds. If someone happens to have qemu activated with the binfmt_misc enabled for AOF/ELF binaries, you suddenly going to execute those RISC OS binaries during building which will give for sure interesting and confusing fallouts. > Finally, there are a couple of native binaries used for cross build > config - stuff like orbit-idl-2. The reason I also put 'zip' here > is that it's build as part of the autobuilder. I wanted to keep > cross/bin entirely for stuff built by the gcc4 tree. It makes certain > clean builds and stuff easier, since you can remove each directory > independently. If that's the only reason, let's create an env/bin-cross directory holding those native zip/orbit-idl etc binaries and then we avoid possible contamination of host and RISC OS binaries and by removing $GCCSDK_INSTALL_ENV you can start from a clean state as well. That's an approach I can live with. > I appreciate that there's something of a circular dependency here, > in that the packaging of GCC requires zip. A logical solution for this would be to build the RISC OS compiler using Autobuilder (probably in a mode disabling all the scripts in $GCCSDK_INSTALL_ENV). Tbh, I don't think this has a priority as we have a working solution now and I don't see any gains changing it nor solution for a problem we would have now. > However, in practice > it will also require 'make' (the RISC OS binary) and perhaps other > stuff we choose to package with the !GCC app. No, that is a different thing : we were talking about a host binary which is installed in a wrong directory, not a RISC OS binary which might or might not need to be part of !GCC. Aside: I think it should not be part of !GCC but made separately available like also the binutils and take care all those packages are easily downloadable. Don't know whether it is possible to create a metapackage for developing on RISC OS but that could be useful to address this. John. -- John Tytgat, in his comfy chair at home BASS [email protected] ARM powered, RISC OS driven _______________________________________________ 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
