core-v-verif
core-v-verif copied to clipboard
openhwgroup
make clean doesn't properly clean a built
make clean doesn't properly clean a built
Task Outcome
As a user, I would expect make clean to revert everything that make does. Currently, it seems to only clean the results.
Hi @christian-herber-nxp, you are correct about that and it is by design. make clean reverts results only; make clean_all deletes everything.
ok that is reasonable. had a look at it, but it doesnt seem to clear the cloned git repository under core-v-cores, so it doesn't go back to distribution state
That would be a bug! Can you issue a PR to fix? (and thanks for the catch)
I cannot at this point, as the contribution to this repo is still a pending topic. Such a cleaning would also me much easier, if the repos where cloned into a location inside the core specific directory instead of core-v-cores. Maybe that would also be a needed change when separating core-v-verif towards cores. Is there a benefit of cloning things into a shared place?
I cannot at this point, as the contribution to this repo is still a pending topic.
Can you expand on this? Are you saying that NXP is still trying to decide whether to contribute to CORE-V-VERIF, or that there is something gating NXP from doing so now?
if the repos where cloned into a location inside the core specific directory instead of core-v-cores
That was a subject of some debate when this environment was being implemented. At the time, the majority vote was to keep all RTL in one place (core-v-cores). I do not recall having a strong preference, but I see no reason to change it.
Is there a benefit of cloning things into a shared place?
Not in my view. This would place restrictions on how members use CORE-V-VERIF and due to the wide variety of users in the OpenHW community it would be difficult to support. It would also make it impossible to support local testing of fixes before committing. Saving a few tens of megabytes is not worth the additional complexity.
Not in my view. This would place restrictions on how members use CORE-V-VERIF and due to the wide variety of users in the OpenHW community it would be difficult to support. It would also make it impossible to support local testing of fixes before committing. Saving a few tens of megabytes is not worth the additional complexity.
on this one in particular: I would add another parameter that just gives a path to a directory that contains the cores rtl, which overrules all others. if you spec a repository, branch etc, i would expect things to be run from the upstream repo and not local stuff.
on this one in particular: I would add another parameter that just gives a path to a directory that contains the cores rtl, which overrules all others. if you spec a repository, branch etc, i would expect things to be run from the upstream repo and not local stuff.
Hi, Already available with CV_CORE_PATH variable. I am using it a lot ...
ok, that sounds great.
If you are asking my opinion, anything the make clones should really be in a subdirectory of the core in some build directory and should be cleaned on a make clean.
anything the make clones should really be in a subdirectory of the core
Keep in mind that the current structure of CORE-V-VERIF is such that is it a distinct rep from the cores and we "bring the cores to the testbench". This was a deliberate strategy from day one.