search

olofk / fusesoc

Package manager and build abstraction tool for FPGA/ASIC development
BSD 2-Clause "Simplified" License
1.17k stars 242 forks source link

How to use fusesoc.conf with RCS? #603

Open shareefj opened 1 year ago

shareefj commented 1 year ago

I've just started trying to use fusesoc.conf to manage libraries and am not sure I'm using it correctly. My aim is to check in the configuration file such that when a user checks out a clean repo and uses fusesoc, all libraries that are missing get populated.

Running something like fusesoc library add idex_generators https://github.com/idex-biometrics/fusesoc-generators results in a configuration file as follows:

[library.idex_generators]
location = fusesoc_libraries/idex_generators
sync-uri = https://github.com/idex-biometrics/fusesoc-generators
sync-type = git
auto-sync = true

but if I commit that file and run fusesoc as normal I get a warning about:

WARNING: Failed to register library 'fusesoc_libraries/idex_generators is not a directory'

The fusesoc library sub-command does have an update argument but that seems to incorrectly identify the library as local:

$ fusesoc library update
WARNING: Failed to register library 'fusesoc_libraries/idex_generators is not a directory'
INFO: /home/shareefj/git/GN-651 : sync-type is local. Ignoring update

Perhaps that's the issue? Is running update the correct way to populate the libraries but it's not working due to a bug in determining the sync-type?

olofk commented 1 year ago

I guess the main problem is that checking in fusesoc.conf is not an intended use-case. It does seem like it almost works though, so let's try to make what you're trying to do possible.

Yes, that looks like a bug. There are some heuristics involved here and I'm frankly not super familiar with that part of the code as I didn't write it myself. I think it's a fair assumption that fusesoc library update, but I wonder if that INFO message is really related to the same library as was mentioned in the warning.

What I guess happens is that FuseSoC tries to go into the library and run git update and fails because the library doesn't exist. I think we could change that to instead do a fresh clone in that case, which would probably solve your use-case

shareefj commented 1 year ago

So is the original use case that a user should always run fusesoc library add on each clean checkout?

I can take a closer look at the code and try and work out what's going on.

olofk commented 1 year ago

Library managment in FuseSoC could need some more love in general. The use-case you describe just wasn't considered by anyone. The assumption was that the workspace directory is a throw-away directory that isn't under version control. But I do see the benefit of checking in a base workspace dir, especially if you want to put some utilities and stuff inside that.