fadden / 6502bench

A workbench for developing 6502 code
https://6502bench.com/
Apache License 2.0
169 stars 32 forks source link

Object code moved ... #128

Closed BacchusFLT closed 2 years ago

BacchusFLT commented 2 years ago

When I created my most recent project, I had the binary in the root of my project when I created it but then I moved it to a subfolder. Opening the project again, I get an error that the binary isn't found. I open a file requester, locate it and all is fine. Opening the project again, the same process appears again. Is there an issue updating the path to the binary in the project? The selection following selecting the path seems not to be preserved.

fadden commented 2 years ago

The issue is that the path to the binary is not stored in the project at all... https://6502bench.com/sgmanual/mainwin.html#starting-new :

The data file's name is not stored in the project file, so if you pick a different name, or save the project in a different directory, you will have to select the data file manually whenever you open the project.

I decided to retain nothing of the filename for data files (and only partial pathnames for .sym65 / .cs). This way, if you want to rename your project and data file, you just rename them and everything works without having to go through broken-link resolution. The only case I know of where this is a limitation is when you have multiple project files for the same data file, which I do for a set of failure tests (https://github.com/fadden/6502bench/tree/master/SourceGen/SGTestData/FunkyProjects).

BacchusFLT commented 2 years ago

Shall I take this as I need to have the reassembly in the same folder as the binary?

fadden commented 2 years ago

"Need" is a strong word. :-) However, the alternative is living with the annoying find-the-file prompt.

The binary and project file are a pair; without the binary the project file is meaningless. My expectation was that they would always be next to each other. SourceGen doesn't modify the original binary, so having a copy tucked away isn't as useful as it might be with a different tool.

FWIW, while there's some value in checking in the generated assembly sources -- it lets viewers of the source repository see the disassembly without having to download the project -- there's no need to check in the output of the cross-assembler. If it isn't byte-for-byte identical with the original binary, SourceGen isn't doing its job.