It's yet another of my (emphasis mine) projects you're forking...
No. Rather, we're de-forking your (improved, it's a fact !) fork of one of the projects we're maintaining: besides having the same switches as ttdasm, dasm-tigcc uses some code from ttdasm. Fact, acknowledged in the copyrights.
What you're calling a fork of dasm-tigcc (if any: the command-line compatibility between dasm-tigcc and ttdasm would make it possible to make the new ttdasm just start dasm-tigcc...) is actually reintegration to upstream by the upstream maintainers
I don't remember dasm-tigcc being contributed to the former TIGCC Tools Suite, and I can't find a mail whose body contains "dasm" in my whole inbox (which contains mails since the end of 2005, i.e. before dasm-tigcc existed).
Yes, "we" and a plural for "maintainer": by me importing the "GCC4TI Tools" -> "TI-68k Developer Utilities" into GCC4TI, the list of upstream maintainers has expanded. And unlike your fork, the upstream ttdasm will be maintained in a public SCM repository, not in a closed fashion somewhere on your own computer...
Now, it's a fact that we're going to fork dasm-tigcc. Blame yourself for this, not us: we wouldn't have to fork dasm-tigcc if you developed it in cooperation with both your users and other developers
As you remember, the dasm-tigcc patch I sent you on 20080525 (before we decided to create GCC4TI) that I mentioned in ./8, was a PoC patch for an alternative, default-disabled, '%'-less syntax. Being trivial, the patch makes it clear how easy it is to program a multi-year-old (and multi-person) tiemu-gdb feature request.
And what happened ? You dismissed the patch outright in a one-liner e-mail that read (in French) that it had zero usefulness...
I don't see the point of supporting all those compression methods, there should be one default (ttunpack-small or LZMA),
There IS one default. ttstart has supported ASM + ttunpack since before ttunpack-small existed. I chose to keep ttunpack (-fast in your terminology), because the newest version of it is smaller and faster than the older, pre- Greg Dietsche / myself / Samuel Stearley versions, and because sizeof(ttstart_asm_ppg) < 2 * sizeof(pstarter).
people who want another one
ttstart maintainers belong to that group of people...
should just change the parameter in the TPR and rebuild.
That's pretty inefficient (and therefore stupid) of a suggestion: the automated, GUI-less build of all four possible versions of pstarter + all eleven versions of ttstart, through the `tigcc` tool (instead of `sed`/`perl` + `tprbuilder` to modify the TPR) takes less than two seconds on my computer.
ttstart 2.x has the capability of handling multiple compression formats in a single executable. That must be tested, right ?
(I guess that the testing work can be narrowed a bit down from 11, or 23, executables, but that's still some testing work).
Every few days, `cvs up -d` on the TIGCC repository and `find . -iname "*chm*"` tell me that you still haven't added the chm2dcf ("slooooow") et dcf2adp tools at the .../doc/converter where they belong, three weeks after I privately reported you the problem (20090109). It's not that you haven't had time for this until now, but you decided to spend it writing FUD against GCC4TI and its developers (20090113 onwards)...