fusesoc
fusesoc copied to clipboard
Wildcards/regex for filesets ?
Hi
Is there some way to use wildcards for file-names within filesets ? Or maybe a way to pre-evaluate a regular expression ?
People have asked for this before, but in my view the added complexity doesn't make up for the benefits. I think it would be cool however to have some semi-smart tool that can automatically create an initial core file by traversing a directory
I wonder if this could be implemented using a generator? This might depend on https://github.com/olofk/fusesoc/issues/365 if you wanted to make a generalised one, though.
The idea of adding files by hand isn't compatible with TB libraries, where there are many files. Also, it's going to really hurt refactoring, when changing class (and implicitly file) names would require manual changes to the core file.
So is it set in stone that there will never be a wildcard based way of specifying files?
Nothing is set in stone, it's software after all! I guess all constraints have been articulated already. Let's continue the discussion in a pull request!
As was mentioned earlier, it might be possible to do with a generator too. If that is sufficient, it will probably get the job done sooner, since I suspect there are some fine points to discuss with wildcards.
Also, do you just have a lot of files, or are the file names changing a lot? If it's the former, then I usually just do e.g. find -name '*v' and put this list into the core file and never think about it again. If the file names are changing a lot, I can see why you want something more dynamic
Adding. renaming, and removing are regular operations, so the .core file has to change way too often. It's annoying enough that the IDE we use doesn't provide enough support for these operations (particularly when renaming), but having to also change the .core file every time would lead to significant resistance to these refactoring practices.
I don't think there are that many issues to discuss with wildcards. It's possible currently to define more files than needed (i.e. files that were abandoned), without knowing it.
Format-wise, I imagine the single * wildcard is sufficient (not ** to descend into directories). A typical SV TB core would probably look like:
filesets:
main:
files:
- src/main/sv/*.sv
- src/main/sv/*.svh: {is_include_file: true}
- src/main/sv_headers/*.svh: {is_include_file: true}
file_type: systemVerilogSource
With the extension in #398:
filesets:
main:
files:
- src/main/sv/*.sv
- src/main/sv/*.svh: {is_include_file: true, scope: private}
- src/main/sv_headers/*.svh: {is_include_file: true}
file_type: systemVerilogSource
With the extension in #397 (and a core that contains include paths with directories):
filesets:
main:
files:
- src/main/sv/*.sv
- src/main/sv/*.svh: {is_include_file: true, scope: private}
- src/main/sv/some_dir/*.svh: {is_include_file: true, include_path: some_dir, scope: private}
file_type: systemVerilogSource
A full fledged example with both extensions would then be:
filesets:
main:
files:
- src/main/sv/*.sv
- src/main/sv/*.svh: {is_include_file: true, scope: private}
- src/main/sv/some_dir/*.svh: {is_include_file: true, include_path: some_dir, scope: private}
- src/main/sv_headers/*.svh: {is_include_file: true}
file_type: systemVerilogSource
If a file matches multiple wildcards: jail! We just throw an error message and tell the user to fix it.
If you really want to go for the gold (which is not absolutely necessary):
filesets:
main:
files:
- src/main/sv/*.sv
- src/main/sv/**/*.svh: {is_include_file: true, include_path: $group1, scope: private}
- src/main/sv_headers/*.svh: {is_include_file: true}
file_type: systemVerilogSource
where $group1 is some fictive syntax to specify what matched the **. Here I would say we're getting into "a lot of things to discuss" territory.
I'm marking this as an enhancement for now. I am personally not too sold on wildcards but let's discuss it to iron out any particular problems