Converting from one format to another is not like a version control system at all. With multiple branches you have to do work manually, with a tool to convert them you make one change and it's available in all of them. You can support another assembler by just changing the tool, if a new version of an assembler adds functionality that you want to support then you can just change the tool. Trying to solve the problem of assembler compatibility with source control is like http://en.wikipedia.org/wiki/Law_of_the_instrument On 30/12/2014 11:40, Marko Mäkelä wrote: > Hi Ruud, > >>> I initially did version control by a compile-time constant, and it >>> got messy as soon as there was some refactoring of the code. >> >> Same problem over here. But then I wrote a little program that >> created the individual versions out of the main one. > > So, in essence, you reinvented another part of a version control > system (checking out a branch from a repository). > >> And if I want to study something, I take one of those generated >> files, not the original one. > > This is the same with a version control system: you do not access the > repository directly. > >> And if I see an error or want to change/add comment, I only have to >> edit the main source code and to run the program again to get all >> files up to date. > > This would be easier with a version control system that supports > branches (such as svn or git). You would commit the changes to one > branch and then merge it to related branches. When doing this, you > would also create change history with some comment about the change. > Access to the revision history can be useful for example if some time > later you do not understand or remember what the change was about. > > This is a hobby, and it is of course OK to do whatever makes you > comfortable. I also have no right to complain here, because I have not > done anything for the 8-bit systems lately, due to my day job > demanding all the coding capacity of my brain. :( > > Maybe after more than a decade of professional software development, I > have a more dull view, preferring to use widely used freely available > tools instead of rolling my own. > > It is somewhat sad that there is no single established standard for an > assembler, not even for contemporary systems (even if we ignore > Windows, where many things are done differently by convention). Some > projects use the GNU assembler, others use NASM, and so on. > > Marko > > Message was sent through the cbm-hackers mailing list Message was sent through the cbm-hackers mailing listReceived on 2014-12-30 12:02:14
Archive generated by hypermail 2.2.0.