Enhancement Request for Ephemeral Working Directory

[bobnewgard]

Issue - invoking the "autofpga" make target results in changes to git status. Intentional manual changes by a developer to the repo may be camouflaged by the automatic changes.

Request - instead of modifying in place the files under rtl/, sim/, and sw/, copy these directories to an ephemeral directory (e.g. ./tmp/) and work with them there. The imported wb2axip and dbgbus repositories would also go into the ephemeral directory.

Regards, Bob

Details: https://github.com/ZipCPU/autofpga commit f89d4dce81baed312c843c8554923fee7750d0a1 https://github.com/ZipCPU/axidmacheck commit 4e7923db87edee141b9f8164b9ab5d84c25d7abf

[ZipCPU]

Isn't this what you'd want though? I've kept AutoFPGA working this way so that the design is always kept in git at its latest build--including any AutoFPGA products so that they'd be available for a user who might not have AutoFPGA. Ideally, if you don't want these files updated, then ... just don't run AutoFPGA, no? Or is the problem that AutoFPGA runs by default?

[bobnewgard]

Of course, you must run your repository as you see fit. I should have centered my message on what I encountered, and my confusion, instead of going directly to my "solution".

I love git. I love that its primary use case is to retain a history of developer intent. Other changes to the repo, like those generated by autofpga, should be ignored (i.e. .gitignore'd) so there is no chance of them becoming part of repo history.

Perhaps for me, since autofpga runs as part of the testbench build process, I assumed that autofpga was mandatory. I had just cloned the repo and was unfamiliar with the repo contents.

Anyway, your published work is clearly a win for me, so thanks. My confusion was temporary; I worked around it by simply not staging the autofpga changes.

[ZipCPU]

I guess I'm always afraid that some minor change in AutoFPGA will break something. There's been more than once in the past where change obsoleted previously built designs. It then takes me a bit before I can re-updated everything that depends upon it. Keeping the files built by AutoFPGA in the repository is valuable for that purpose.

I suppose the "right" answer might be to take the auto build of AutoFPGA out of the test bench build process, although this would be annoying here since I use AutoFPGA so regularly with this design. I think I'm going to instead leave it as it is, and note your (very valid) concerns.

I'm glad the repository has been useful for you. Thank you for your feedback!

Dan