include Git hash in d64 ; calculate TAG variables once

jkotlinski / durexforth

Modern C64 Forth

Other

233 stars 28 forks source link

include Git hash in d64 ; calculate TAG variables once #345

Closed cminter closed 3 years ago

cminter commented 3 years ago

include Git hash in d64 after version string (for traceability)
use lower case 'm' in d64 (was 'M') for warning that repo files were modified as d64 was generated (looks better when listing disk in upper case mode)
calculate TAG variables only once using shell command (previous form was just text in a variable that was not executed until later during each command which obfuscates the flow)

cminter commented 3 years ago

Below is what the directory looks like. E.g. Git hash 36e3593

0 "durexforth      " DF 2a
154   "durexforth"        prg 
1     "=-=-=-=-=-=-=-="   seq 
1     "v2.0.0-m"          seq 
1     "  36e3593"         seq 
1     "=-------------="   seq 
19    "base"              prg 
8     "debug"             prg 
...
1     "=-=---=-=---=-="   seq 
83 blocks free.

polluks commented 3 years ago

If prefer cc1541 because of DEL entries instead of SEQ.

cminter commented 3 years ago

If prefer cc1541 because of DEL entries instead of SEQ.

Good point. I agree that would be better. Any ideas for making it happen with c1541?

Looks like it could be done with bpoke. Below is the version entries.

bpoke 18 1 66 128
bpoke 18 1 98 128

cminter commented 3 years ago

The second commit I pushed (3d9bf96ca2d67db27546f4f4fcafaa6657b623ad) makes the version look like below. Notice inserted .65 and -m since I had modified again after the commit.

0 "durexforth      " DF 2a
154   "durexforth"        prg 
1     "=-=-=-=-=-=-=-="   seq 
1     "v2.0.0.65-m"       seq 
1     "  3d9bf96"         seq 
1     "=-------------="   seq 
19    "base"              prg 
8     "debug"             prg 
...
1     "=-=---=-=---=-="   seq 
83 blocks free.

jkotlinski commented 3 years ago

Looks like there are merge conflicts now. Is it good to go otherwise?

cminter commented 3 years ago

Looks like there are merge conflicts now. Is it good to go otherwise?

I see. I fixed the merge confusion from Github. I will pull and test.

cminter commented 3 years ago

Looks like there are merge conflicts now. Is it good to go otherwise?

I see. I fixed the merge confusion from Github. I will pull and test.

It is good to go.