Not all uses of the tools are in conjunction with TIGCC

You have a point there. But all this means is that the standalone version of the GCC4TI/TIGCC Tools (or whatever their name) will have to include more things than we (Thomas and I) had thought, no biggie.

and not all TIGCC users need the tools either.

That can be addressed through ticket #30, but Thomas and I are [EDIT: NOT] too convinced it's worth the trouble.

BTW, dasm-tigcc isn't in TIGCC, why is that ? I know where to download it, but is it another thing you forgot to include, like the CHM -> Qt converters ?

No, it's intentionally separate. TIGCC doesn't use or require dasm-tigcc, dasm-tigcc doesn't use or require TIGCC. To me that's the definition of separate packages.

Being separate packages for the end user is one thing, but like the tools which are the topic of this ticket, what prevents dasm-tigcc (whose help makes it pretty clear that it's for TI calculators and which imports chunks of ld-tigcc) from being part of the TIGCC CVS repository or the GCC4TI SVN repository ?
dasm-tigcc also duplicates a subset of the tilibs/TIEmu headers and code, and that is not good. Maybe you manage duplication through symlinks on your HDD (thereby triggering an update of the dasm-tigcc sources when upstream tilibs/TIEmu are modified... if CVS is smart enough), but that's not directly reproducable by others. svn:externals ( http://svnbook.red-bean.com/1.5/en/svn.advanced.externals.html ) may come to the rescue here, that said.

they didn't understand that TIGCC Tools Suite != TIGCC

Well, maybe that was because pieces of the former should have been available by default in the latter for a long time ?
(All of Thomas, the TIGCC Team and me share blame for pieces of the TIGCC Tools Suite never having been integrated in TIGCC. It's a fact it never got done, and one of the reasons of this state of things is that each of us focused on various other things.)

Depending on how you organize this, I might end up having to fork the tools suite to be able to ship a standalone package. If you want me to use it as you ship it, you need to make sure it can be built without a full GCC4TI source tree.

SVN handles symlinks within a repository. Therefore, I'd feel logical that the following setup:
* components/varnamechecking.{c,h} for the variable checking code (note that the path and name of the variable name checking code isn't set in stone for now)
* tools/varnamechecking.{c,h} -> symlink to ../components/varnamechecking.{c,h}
yields a copy of varnamechecking.{c,h} in tools when checkouting the single "tools" folder.
I've already used symlinks with SVN, but never in this situation, so I can't tell whether that actually works.

What about a neutral name like "TICT Programming Tools Suite"?

Well... IMO, it would be more important (more descriptive for users) to mention that they are for TI-68k calculators (which they are) than to mention that TICT (instead of whoever else) did the tools, wouldn't it ?
What about something like "TI-68k Additional Tools [Suite]" ?

And losing the eBook tools is a regression, will you do a standalone package with those?

Of course.
Anyway, some chunks of the Tools Suite were to permanently remain outside of TIGCC/GCC4TI, e.g. because they're experimental (a ttpack which requires less memory, etc.) or broken and outdated (tthdex on TIGCC 0.95+ / AMS 3.xx / HW3).
As written in ticket #42, if we find a valid use case for ebooks within TIGCC, we'll add the corresponding "PC" executables, ebook reader and Alice in Wonderland example as well.



BTW, I didn't write about the calctools in ticket #42, but:
* ttstart and pstarter have a LOT of code in common. That requires some changes, but it would be great if ttstart and pstarter used the same "lzma", "ttuf" and "ttup" headers (and maybe "shrn", though this one is currently commented out in ttstart). However, ttstart and pstarter themselves had better remain different source files, since mixing them up would make maintenance harder;
* ttmem is useful for testing under low-memory conditions (I remember someone fixing bugs in his memory handling code after using ttmem);
(* ttrow is a graphical version of the _rowread documentation, less useful)

[EDIT: fixed a sentence where I wrote the opposite of what I meant]