Is there a way to specify where the `runs` directory goes?

[hpretl]

I have not found a good way with the given possibilities in the YAML. Is there a way to specify it, and especially how it is named? (I want to name it _runs for example.

[mole99]

Not yet, but this is definitely something that is needed. Especially if CACE is used together with OpenLane in the same directory.

What do you think about a --run-directory argument in CACE? The path to the directory should be created if it does not exist yet.

cace --run-directory _runs/

[hpretl]

I would rather have this in the YAML, because a few directories and locations are already specified there.

[mole99]

Hm, I think I disagree. For me it feels like a runtime option and not something that should be in the datasheet.

CACE already has the --max-runs argument, which it uses to limit the maximum number of runs to keep in the "runs/" folder. It would only make sense to add the --run-directory and the --run-tag from OpenLane as well.

[hpretl]

In the end, both are fine with me. The argument options means I have to use a wrapper script, because I don't type this all the time. If in the YAML I need only do cace file.yaml. This makes usage simpler.

[mole99]

That's right, I hadn't thought about that yet. But then the datasheet is slowly becoming more of a configuration file, which perhaps it already is 😄

@RTimothyEdwards What do you think?

[RTimothyEdwards]

@mole99 : I think you know my opinion is that it's the programmer's job to make life easier for the end-user, not the other way around, and that if it is necessary to write spaghetti code to keep things simple for the end user, then so be it.

On basic principles, I would agree that the "paths" in the configuration file should tell CACE where to find files that already exist, and so where the run-time files go is definitely more of a run-time option. But Harald has a good point, too, about ease of use for the end user.

My solution would be to allow either one: If it's not specified, use the default "runs/". If it's in the YAML file, then use what's in the YAML file. And if it's specified on the command-line, then that overrides what's in the YAML file. There are other things in the configuration file, like "skip", that are handled the same way: First, default behavior; second, behavior as specified in the YAML; and third, behavior as overidden by a command-line option.

[hpretl]

@RTimothyEdwards That sounds like a good proposal!

[mole99]

Overriding the behavior via the command line arguments sounds alright to me. Added to my to-do list 👍

[mole99]

Implemented in #113.