Conversation
| help='Environment variables passed directly to ' | ||
| f'{RUNNER} -e') | ||
| parser.add_argument('--ccache', action='store', | ||
| help="Use given directory as a cache for ccache") |
There was a problem hiding this comment.
I would rather use a docker volume for that, unless there is a point to access the ccached data from outside a container?
There was a problem hiding this comment.
I use it to check how well that works with CCACHE_DIR=... ccache -s. Also, that allows a caller to have its own management of the lifecycle of this cache like other standard directlries, whereas I understand a docker volume would be in docker/podman's own data store.
There was a problem hiding this comment.
Ok, maybe get the value from an environment variable, so we don't have to always pass it on the command line then.
There was a problem hiding this comment.
That would sure mirror the behavior of ccache, which tends to use a single cache dir, though I've mostly used it separate cache dirs for building different packages. I guess both usages make sense, and I'm wary of having 2 ways of passing the info - but for the bitbake use-case I kind like the simplicity of just appending options with:
XCPNGDEV_BUILD_OPTS:append = " --ccache=${TOPDIR}/ccache/${PN}"
If we want to add an envvar, at first I wondered whether simply using CCACHE_DIR here would be a good idea, rather than introducing a brand new one.
OTOH CCACHE_DIR was mostly designed as a way to pass a parameter, transparently to the compiler CLI to avoid modifying a build system. In fact I'm a bit unsure of the use-case you have in mind - just making sure all invocations are reusing the cache by adding it in your .profile?
There was a problem hiding this comment.
Just to avoid passing it by hand and take advantage of the cache when rebuilding a package
| os.makedirs(args.ccache, exist_ok=True) | ||
| docker_args += ["-v", f"{os.path.realpath(args.ccache)}:/home/builder/ccachedir", | ||
| "-e", "CCACHE_DIR=/home/builder/ccachedir", | ||
| "-e", "PATH_PREPEND=/usr/lib64/ccache", |
There was a problem hiding this comment.
any reason to hardcode path "/usr/lib64/ccache" here ?
unsure it will be portable in all systems but this is fair enough
There was a problem hiding this comment.
Whereas it's usually added to PATH when we login, when running commands that way it is not, so we have to add it to benefit from the transparent compiler wrappers.
Now yes, hardcoding the path is rather hackish and will cause issues for aarch64. I'm not sure if we (want to) introspect the container image to determine it, so we can probably get away with a conditional depending on release and arch.
| } | ||
|
|
||
| if [ -n "${PATH_PREPEND}" ]; then | ||
| PATH="${PATH_PREPEND}:${PATH}" |
There was a problem hiding this comment.
nope - if it's already exported we're in big trouble anyway :)
(I've always wondered why so many textbook examples insist on using export on this variable 😉)
There was a problem hiding this comment.
At startup, bash automatically maps the environment variables as variables and marks them as exported. When a variable is modified inside the bash process, bash passes the new value as an environment variable to the sub-processes.
I still use export anyway—for clarity and as a habit, I guess.
There was a problem hiding this comment.
The underlying issue is that there is a single syntax for 2 different things :)
Quite necessary for upcoming rebuilds of the kernel package. Includes a new PATH_PREPEND interface to the container. Signed-off-by: Yann Dirson <yann.dirson@vates.tech>
3 participants
Quite necessary for upcoming rebuilds of the kernel package.
Includes a new PATH_PREPEND interface to the container.