All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <jacmet@sunsite.dk>
To: buildroot@busybox.net
Subject: [Buildroot] ccache directory
Date: Sun, 24 Jul 2011 18:06:13 +0200	[thread overview]
Message-ID: <87zkk3wtmy.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <874o2byhax.fsf@macbook.be.48ers.dk> (Peter Korsgaard's message of "Sun, 24 Jul 2011 14:49:42 +0200")

>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes:

Hi,

 Thomas> Another solution is to remove the hardcoded cache directory,
 Thomas> use the CCACHE_DIR environment variable, but let buildroot set
 Thomas> that variable based on BR2_CCACHE_DIR (a configuration
 Thomas> option). This addresses Thomas' point regarding mixing
 Thomas> environment variables and configuration options, and my request
 Thomas> of being able to change the cache directory and making sure
 Thomas> these changes are automatically in effect.

 Thomas> What do you think?

 Peter> Yes, something like:

 Peter> # use BR setting if not set in environment
 Peter> ifndef CCACHE_DIR
 Peter> CCACHE_DIR:=$(call qstrip,BR2_CCACHE_DIR)
 Peter> endif

 Peter> export CCACHE_DIR

 Peter> in the toplevel Makefile.

Except that doesn't work. The GENTARGETS stuff for ccache already
creates a CCACHE_DIR variable for the ccache build directory, and the
export line only gets evaluated just before the targets are executed :/

As variables are automatically reexported when they were set in the
environment, this also means that we would always clutter the CCACHE_DIR
environment setting.

It's furthermore not easy to handle a BR_CCACHE_DIR variable containing
shell variables (like $HOME) that should get expanded before make
handles it.

So that leaves either:

- Keep things like they are

- Add a BR2_CCACHE_DIR but tell people that they cannot use $VAR in it

- Patch ccache to look for another environment variable

- Rework GENTARGETS to not use <pkg>_DIR, but several packages would
  need to be updated, and users might rely on it for local packages

- Rename ccache package to something else, breaking existing .configs

I think option two (defaulting to ~/.buildroot-ccache or perhaps
~/.ccache) is probably the best option, followed by 1.

-- 
Bye, Peter Korsgaard

  reply	other threads:[~2011-07-24 16:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-20 15:42 [Buildroot] ccache directory Thomas De Schampheleire
2011-07-20 16:19 ` Thomas Petazzoni
2011-07-20 20:49   ` Peter Korsgaard
2011-07-21  5:58     ` Thomas Petazzoni
2011-07-21 10:48       ` Michael S. Zick
2011-07-21 16:11         ` Peter Korsgaard
2011-07-24 11:23       ` Thomas De Schampheleire
2011-07-24 12:49         ` Peter Korsgaard
2011-07-24 16:06           ` Peter Korsgaard [this message]
2011-07-24 19:21             ` Thomas De Schampheleire
2011-07-24 20:07               ` Peter Korsgaard
2011-07-24 20:12                 ` Yann E. MORIN
2011-07-26  7:38                 ` Thomas De Schampheleire

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=87zkk3wtmy.fsf@macbook.be.48ers.dk \
    --to=jacmet@sunsite.dk \
    --cc=buildroot@busybox.net \
    /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.