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 22:07:52 +0200	[thread overview]
Message-ID: <87ipqrwig7.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <CAAXf6LW+awPoagLehXSVccwgGO4qJf8goaVZEoNaKeD+Q2fi1w@mail.gmail.com> (Thomas De Schampheleire's message of "Sun, 24 Jul 2011 21:21:26 +0200")

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> writes:

Hi,

 >> 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.

 Thomas> What exactly is the problem here? Other configuration options
 Thomas> can use shell variables like $(USER) without problem. The only
 Thomas> thing to keep in mind is to write these variables in make
 Thomas> syntax with parentheses, rather than in shell syntax with
 Thomas> either curly braces or nothing.

Indeed, that's the (potential) problem. People need to write the patch
in make syntax rather than shell, which may or may not be a problem if
they expect something similar to the CCACHE_DIR shell environment
variable.

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

 Thomas> How would you pass it to ccache then, given the restriction you
 Thomas> mentioned above? On each compiler command-line?

 Thomas> Or were you thinking of compiling this variable hardcoded in ccache
 Thomas> using the existing patch?

Hardcode it like it is now would be simplest option.


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

 Thomas> In itself I'm not sure whether this is a problem. With
 Thomas> buildroot-2011.05, the board support also changed
 Thomas> significantly, which required some rework in non-mainstream
 Thomas> projects. Moreover, the change would be nothing more than a
 Thomas> variable rename.

True - It would still mean that we would have to fix up a number of
packages though, E.G.:

git grep '([A-Z0-9]*_DIR)' package/**/*.mk | \
    egrep -v 'STAGING_|BUILD_|TARGET_|HOST_|DL_' | \
    cut -f1 -d: | sort -u | wc -l
34

-- 
Bye, Peter Korsgaard

  reply	other threads:[~2011-07-24 20:07 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
2011-07-24 19:21             ` Thomas De Schampheleire
2011-07-24 20:07               ` Peter Korsgaard [this message]
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=87ipqrwig7.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.