John Tytgat wrote:
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.
I'm not sure you're adequately distinguishing between the different
contents of this directly. On my setup, there are no less than 80
scripts there, which are used for library configuration purposes.
In fact, I don't think we should be installing RISC OS binaries at all
here, and I'm tempted to modify ro-install to ditch any such binaries
placed here, since they have no purpose.
I disagree that we are "fighting" anything - this is just how it
works out with the extant build systems, many of which know
nothing about cross compilation.
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.
It has to be in the path - or something does - to pick up the above
scripts, and occasional binary.
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.
All RISC OS binaries should end in ,e1f - so unless qemu is somehow
picking these up, I don't see this scenario - in any case, this can
be avoided by not installing the RO binaries in the first place.
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.
Well, there are actually other scripts in env itself, and
we could move things there if that was really your objection. However
enforcing this in general is a bit tricky, although it's only
a couple of cases.
_______________________________________________
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
