Remove "resource" submodules as FIRRTL compile dependencies

ucb-bar / chipyard

An Agile RISC-V SoC Design Framework with in-order cores, out-of-order cores, accelerators, and more

https://chipyard.readthedocs.io/en/stable/

BSD 3-Clause "New" or "Revised" License

1.56k stars 618 forks source link

Remove "resource" submodules as FIRRTL compile dependencies #174

Open abejgonzalez opened 5 years ago

abejgonzalez commented 5 years ago

See #171

When you run the FIRRTL/barstools compiler, it needs to depend on all SBT projects that do an addResources or setResources call (needs to add the other SBT projects to the compiler classpath in order to access src/main/resources folder on a getResourceAsStream call). However, this causes the compiler to be rebuilt everytime one of the other projects changes... which is unnecessary since the compiler only depends on FIRRTL and Chisel.

Is there an effective solution to remove the compile dependency but leave the "I must build the other projects first" dependency?

grebe commented 5 years ago

If I understand correctly, a somewhat brute-force way to do this would be to use unmanaged dependencies:

Each build.sbt should produce a jar and not depend on any subprojects
Make targets depend on jars, symlink in a lib/ dir to all your projects (be sure to .gitignore them!)

I think it's bad to add more make to my scala, but i think it's an option.

Perhaps the better way to go is to not invoke firrtl/barstools separately- just invoke chisel one time and produce firrtl, conf, verilog, etc from one sbt invocation. I think that's the better approach.

davidbiancolin commented 5 years ago

My read is that if we are going to resort to building projects independently we should just go all in on wake. But to you earlier point, I think adding jars as unmanagedDeps to these projects that only need access to resources is the right call and doable from SBT, should we be so inclined.