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
next prev parent 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.