All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorn Potter <lpotter@trolltech.com>
To: openembedded-devel@lists.openembedded.org
Cc: openembedded-devel@openembedded.org
Subject: Re: CROSS_DIR
Date: Thu, 29 Nov 2007 06:13:08 +1000	[thread overview]
Message-ID: <474DCBD4.6060605@trolltech.com> (raw)
In-Reply-To: <1196248199.8098.13.camel@localhost.localdomain>



Richard Purdie wrote:
> On Wed, 2007-11-28 at 14:50 +1000, Lorn Potter wrote:
>> Was CROSS_DIR changed somewhat recently (last 2 months or so) to link 
>> the includes and lib dirs to staging?
>>
>> If so, why? This means I cannot distribute this toolchain to other 
>> machines, and makes the entries in the pkgconfig files wrong.
> 
> It was changed, yes. The reason was to remove duplication of files
> between staging and cross. There are various reasons for doing that
> including faster builds, less error prone builds (file duplication means
> both copies have to be kept the same) and that cleaning this up assists
> some future planned developments (e.g. sysroot and packaged staging).
> 
> The symlink is intended as a transition fix and ultimately we can switch
> to the sysroot option of the toolchain for everything but gcc 3.3 and
> earlier. Poky already has done so and it is *much* cleaner.
> 
> I have seen the pkgconfig problem and its unfortunate, I didn't realise
> until it was too late. Its not more wrong than pointing at staging
> really though. The good news is that it goes away entirely when we
> switch to using sysroot options for pkgconfig.

If CROSS_DIR is simply a symlink to staging, whats the point? I see no 
point in setting this if it doesn't work as it used to, and put the 
toolchain somewhere else, otherwise it's redundant and pointless.


> 
>> CROSS_DIR should mean just that - this is where I want the toolchain to 
>> be - like it used to do.
> 
> Well, the cross toolchain components are still there. The target system
> header/libraries (glibc and libc-headers-linux) only get installed to
> the target system staging directory now though.
> 
> CROSS_DIR is not meant to be a toolchain you can transfer between
> machines, its meant to be the cross components of the builds. If you
> want a toolchain to transfer between machines you can build one with
> meta-toolchain.

You guys must like doing things the hard way. As per the old method, 
CROSS_DIR can be used as a distributable toolchain. Now, _everything_ 
and their sister are there, which is not what a toolchain should be.

What is the path to whatever meta-toolchain creates? is it CROSS_DIR? or 
somewhere in the build directory? which could very easily be in 
someone's home directory, and not redistributable. Is there an good way 
to set the path to it?



-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, MES, Trolltech



  reply	other threads:[~2007-11-28 20:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-28  4:50 CROSS_DIR Lorn Potter
2007-11-28 11:09 ` CROSS_DIR Richard Purdie
2007-11-28 20:13   ` Lorn Potter [this message]
2007-11-29  1:45     ` CROSS_DIR Richard Purdie
2007-11-29 20:03       ` CROSS_DIR Rodrigo Vivi
2007-11-30  0:21         ` CROSS_DIR Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=474DCBD4.6060605@trolltech.com \
    --to=lpotter@trolltech.com \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.