-
Notifications
You must be signed in to change notification settings - Fork 242
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
Make fusesoc more decentralized #128
Comments
Hi, Yes, this is already possible, but since the documentation is almost non-existent, I'm not surprised you could not find it. I actually took this as an opportunity to write a bit more documentation, so check out https://github.com/olofk/fusesoc/blob/master/doc/fusesoc.adoc#core-search-order where this is described now. So no more forks of orpsoc-cores. Instead, do one of the following. If it's a remote core (i.e. with a [provider] section), you must first download the repository specified in the provider section. After that you can copy the .core file from orpsoc-cores into the downloaded repository and remove the [provider] section to avoid FuseSoC from trying to download it again. Some cores already have .core files in their repositories and in those cases, you don't need to copy the one from orpsoc-cores. You now have a local cores and can use the instructions outlined above. Hope this helps and let me know if I can add anything else to the documentation to make this clearer |
Oh, that's exactly what I needed! Thank you for the documentation, it's clear enough for me at least |
Sorry if this is the wrong channel for this kind of request; would it be possible to design fusesoc to be more flexible in terms of where it sources repositories? Currently the only way (AFAIK) to hack on some of the components is to maintain a fork of orpsoc-cores and modify the system and core files there. Would it be possible to allow fusesoc to source system and core files from other repositories? So instead of a single repository holding all the dependency and build information, it could keep using that one repository, but users can create their own systems and cores in separate repositories that they can source from as well. This seems really rigid compared to the package management and build systems in a lot of other languages, where you can basically source packages from arbitrary repositories if you give the package manager the address of it
Sorry if this is already possible, and thank you for your time!
The text was updated successfully, but these errors were encountered: