Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The same source code in different folders? #6

Open
serge-nikulin opened this issue Nov 6, 2017 · 12 comments

Comments

@serge-nikulin
Copy link

commented Nov 6, 2017

Let's assume I have exactly the same source code in folders A and B.
I build source code in folder A.
Then I build the source code in folder B.
During build of B in Stashed Stats I see a lot of cache misses (e.g. 1000 misses vs 24 hits for a small project).
Is it expected?

Thanks!

@jsmouret

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2017

Yes it is expected for the moment because we use the full source path to identify a job.

We are working on a feature that rewrites all paths to be relative to the current directory to support scenarios like that.

ccache uses a environment variable called CCACHE_BASEDIR that needs to be set for every project. That's tedious so we are trying to make it automatic.

I'll update this issue when we make progress on that feature.

@jsmouret

This comment has been minimized.

Copy link
Contributor

commented Nov 29, 2017

Quick update, this is still on the roadmap.
We are preparing the next big feature and it requires this too.
But it will take some time...

@manu-st

This comment has been minimized.

Copy link

commented Jan 19, 2018

Just to clarify. Does this limitation also apply to builds on the same machine or is it just for the distributed case? What if we do not use any PDB?

@jsmouret

This comment has been minimized.

Copy link
Contributor

commented Jan 20, 2018

The limitation applies to both distributed and local builds, with or without PDB.

Now that we shipped the distributed feature (the "next big thing" mentioned above), we will focus on resolving this issue. It should be ready around end of February if all goes well.

@manu-st

This comment has been minimized.

Copy link

commented Jan 20, 2018

Great. I'm looking forward to this! In the meantime, do you see something that will prevent the following to work? I was planning on trying over the week-end.

If I have:

dir1/src
dir2/src

where dir1 and dir2 are to different locations. To benefit from the caching, I would compile the project in dir that is a link to either dir1 or dir2 depending on what I want to compile. To do the link, I was planning on either using a junction or a symbolic link.

@jsmouret

This comment has been minimized.

Copy link
Contributor

commented Jan 20, 2018

Yes, that should work :)

@manu-st

This comment has been minimized.

Copy link

commented Jan 22, 2018

Confirming that it worked great.

@Justin-Randall

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2018

This is probably the most requested feature, and also the most problematic. Would everyone be OK with undefined debug behavior if the strange outcomes were well documented? Stashed has been very focused on never producing bad output, but if we tackle this, it can lead to some strange results. "Just working", "Installation without configuration" and all of the other principles that make Stashed what it is would be compromised, but there is arguably great utility in handling this case. This has been an internal debate for a while, but so many users also want this to work in spite of the side effects, it seems like a worthy change to pursue, even with the undesirable consequences.

This has come up often enough that shelving all other work seems like what most people want. Build farms and developer differences on a project make this seem like a high priority change.

@ikrima

This comment has been minimized.

Copy link

commented Dec 5, 2018

My personal opinion is I'd prefer these compromise:

  1. a manual option (eg CCACHE_BASEDIR )
  2. undefined behavior (but you have to explicitly enable this and a popup warning shows up)

I'd be highly against "undefined behavior/bad output" being something that happens by default. I'm reluctantly ok with it being something you can explicitly enable just bc violating a core principle once => many down the road but obvi your call on the product.

For example, on my end, stashed (unfairly) is the first suspect anything goes wrong with the build. I've also had it disabled for 3 months bc it was causing issues in our build (still paying license bc I want you guys to keep developing it!). Time's precious so between investigating the root cause vs. disabling, I just disable and move on. And that's my psychology given that you guys work really hard on not producing bad output. Once undefined behavior is in, all bets would be off.

@dioss-Machiel

This comment has been minimized.

Copy link

commented Dec 6, 2018

I think that having this would be a very nice feature, but it should not be enabled by default.

@zambamingi

This comment has been minimized.

Copy link

commented Feb 5, 2019

Any update? Last message says "It should be ready around end of February if all goes well" which is a year ago now.

@Justin-Randall

This comment has been minimized.

Copy link
Contributor

commented Feb 6, 2019

Still on the table, but is going to require some invasive changes. Stashed has a pretty extensive suite of tests and good coverage -- which break when taking a simple approach to the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.