Re: another proposed crosstool project

["Jonathan S. Shapiro" <shap at eros-os dot com>]

I agree, but it would not require a large change to Robert's approach to
have a makefile that sets the name of the top of the sysroot tree.

We aren't doing a network-provisioned tree, but we do generate
cross-tool RPMs. These have essentially the same path canonicalization
issues. Our practice is as follows:

  /coyotos        -- top of tree (can be moved if you build your own)
    host          -- all host binaries live here. Includes compiler
                     and tool binaries.
      bin,lib...  -- ARCH-VENDOR-OS-gcc, ARCH-VENDOR-OS-as, etc.
                     Also some additions of our own.
        ARCH-VENDOR-OS/  Links for CCS tools for appropriate target. We
                         do not currently rely on these.
    sysroot-ARCH  -- target binaries, objects, and libraries.

In hindsight, sysroot-ARCH is misnamed. For coyotos we are the only
vendor, and coyotos is the only OS, but for a general solution you would
probably want sysroot-ARCH-VENDOR-OS.

In practice, we also support cross tools for the CapROS effort. The
reason we don't hit any issues there is that their cross tools live
under /capros/

Other than the nits above, the main issue with this is that there is no
release number anywhere in the path structure. For us this is not an
issue, because we are using RPM as our distribution mechanism and we
push the updates to our users. We want all of our users on the latest
tools, and we can use the rpm command set to find out what versions they
are running. For releases that aren't using a packaging system it might
be desirable to put a version number somewhere in the root directory
path.
  

On Sat, 2007-05-05 at 18:55 -0700, David Kahn wrote:
> Robert P. J. Day wrote:
> 
> >  for
> > instance, the toolchain would be hardcoded to be "sysroot"ed since
> > that's just plain better than *not* being sysrooted.
> 
> That wouldn't work for me.
> 
> The x-tools that I build are used for projects and the tools
> have to be put in accessible places on the network, and used
> by those projects in consistent ways. For example,
> /ws/sysfw-tools/...
> 
> But if you think that works for you, have at it. Just understand
> that because of that, and probably because of not downloading
> all the packages needed, it won't have all that much generic
> use. And I can't imagine that there's just one set of option
> choices that work in all cases.
> 
> KISS is good. Unfortunately, it's just not that simple
> of a process to support all the variants of hosts and
> targets.
> 
> -David
> 
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC


--
For unsubscribe information see http://sourceware.org/lists.html#faq