Open scharch opened 4 years ago
There's no error message, scons seems to think that it already ran partis.
I can reproduce this if I run with any output directory not under /linearham
, e.g.:
--outdir=/linearham_analysis
but it seems to not be the case when using an output dir under /linearham
, e.g.:
--outdir=/linearham/linearham_analysis
I don't understand why this is and am trying to figure it out but hopefully this unblocks you for now.
I'm assuming this stopgap worked for chaim, so changing title, but lmk if not.
Haven't tested this specifically, but I'm pretty sure this because you copy all the contents into the container into /linearham. Then you change your working directory to /linearham.
Why not replace COPY . ./linearham
with COPY . .
and remove the WORKDIR
line completely. That way everything is relative to root inside the container. This would at least throw a more useful error b/c the user is trying to write above root directory? Just a thought.
That sounds good to me, that would be amazing if you could switch it to that. This issue was just blocking me from running something last week.
update: this happens also outside of docker, so seems likely unrelated to dockerfile, and maybe is a more fundamental scons thing. I haven't managed to google anything useful about decoupling scons work vs build dirs, so maybe it's not possible? Could probably also just make the various linearham scripts/binaries work from outside the linearham code dir, then have scons cd to the output dir and run from there.
In any case it works ok to handle with linking (e.g. this and this), although is a bit complicated and error-prone.
Anyway for now I think it's better to just leave as is.
@psathyrella Not sure my neural pathways stuck around for this - can I be of assistance? Happy to look into it again.
@jgallowa07 no thanks, it seems likely it's not fixable.
I think this is the closest i've come to an explanation for why things may not be working. That link, at least, boils down to scons being designed around backward compatibility with old compilation tools. Which is a little unsatisfying since we're not even compiling anything, but, oh well, the workaround works for now, and sounds like eventually we'll be using a different approach.
Next problem:
Where do I look for an error message?