[ccache] Migrating to ccache 4: a "drop-in replacement"?

[Steffen Dettmer]

Hi!

Thanks so much for all your detailed and helpful answers!

On Sat, Dec 5, 2020 at 3:30 PM Joel Rosdahl <joel at rosdahl.net> wrote:

> On Thu, 3 Dec 2020 at 11:28, Steffen Dettmer wrote:
> > a "plug-in replacement"?
>
> Yes to all instances of the question.
>

Wow, I didn't hope that it could be that great! Thanks so much!


> There is no difference in how cleanup works between old and new versions.
> In
> other words, both new and old ccache versions will clean up files
> generated by
> both new and old versions.
>

Ohh that is great news too!


> > [...] release notes tell that if ~/.ccache/ccache.conf exists, it will be
> > used (release notes are not clear for me if only as fallack or in any
> case
> > when it exists).
>
> See
> <
> https://ccache.dev/manual/4.1.html#_location_of_the_primary_configuration_file
> >.
>

ahh silly me, I had looked there for myself. Thank you, this is very clear.

> Also CCACHE_CONFIGPATH could be set to point to it if needed, but it is
> not
> > needed.
>
> There is almost never a reason to set CCACHE_CONFIGPATH. Instead, just set
> CCACHE_DIR to ~/.ccache if you want the old behavior.
>
> >   $ grep -v '^#' ~/.ccache/ccache.conf
> >   cache_dir=/...shared_local_path.../tmp/ccache
>
> This won't have any effect. cache_dir only has an effect if set in the
> secondary (system-wide read-only) configuration file (typically
> /etc/ccache.conf) or in the environment variable form ($CCACHE_DIR).


I just tested with ccache 3.7.12 and "ccache -s" that it seems to work as I
expect,
like:

  $ $path/bin/ccache -s|grep "config"
  primary config                      /nfshomes/sdettmer/.ccache/ccache.conf
  secondary config      (readonly)    /usr/local/etc/ccache.conf
  $ file /usr/local/etc/ccache.conf
  /usr/local/etc/ccache.conf: cannot open `/usr/local/etc/ccache.conf' (No
such file or directory)

  $ grep ^cache_dir ~/.ccache/ccache.conf
  cache_dir=/tmp/sdettmer/ccache
  $ $path/bin/ccache -s|grep "cache directory"
  cache directory                     /tmp/sdettmer/ccache

  $ grep ^cache_dir ~/.ccache/ccache.conf
  cache_dir=/tmp/ccache-all/ccache
  $ $path/bin/ccache -s|grep "cache directory"
  cache directory                     /tmp/ccache-all/ccache

What do I miss?


(off topic)

> NB: Our reference system is "Devuan 2.0 ASCII", a Debian fork without
> > SystemD.
>
> Sorry to hear that (SCNR).
>

Thank you for sharing your expertise! Although not ccache specific,
I'm glad to get your input because your input usually is just great!

Do you think this is bad or could cause problems?
Do you have someone concrete in mind?

As far as I know, our main reason was, that our embedded systems don't
have SystemD but use init.d scripts, so we made the development ref sys
also don't having SystemD, assuming it would avoid trouble (SystemD is
said to boot faster, but boot time was no issue for us).

Much information about SystemD pros/cons in the web [1] seem to be
very polarized and was not found to be sufficient.

I'm afraid just because all major distros use it, avoiding it could
cause trouble[2].

What do you think, should we better use a mainstream distro
(Debian or any clone, Mint or whatever)?

Let me close with an old joke:
Finally SystemD now is almost feature complete!
Just an integrated kernel and a decent browser are missing. :-)

Steffen

[1] Good example is
http://0pointer.de/blog/projects/why.html which shows properties many
consider disadvantages ("Interfacing via D-Bus", "Shell-free bootup",
"fsck handling"...) as "features" -- but it contains no single feature
SystemD has not ("customisation without being C programmer",
"indepentent small building blocks leaving the choice", "deterministic",
"easy to trace", "simple to understand", "applications don't need to
depend on it", "no hardcoded DNS IPs"...).

[2] such as what we had:
that ssh-agent did not work anymore, because gnome-keyring
overwrote its env but did not work, because the xinitrc forcibly
loads gnome-keyring with shell code that was hacked to work for
Wayland and in short only works with SystemD, and all that because
Wayland with SystemD does not work with ssh-agent because user processes
are not forked from the xinit'd process.
I'm not sure but I think it somehow worked with systemd (someone else
had reported I think).