Lionel Debroux (./4) :
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.

The code isn't symlinked, it's forked. The code portions from libtifiles2 are modified and the unneeded parts ripped out, likewise the integer type definitions from ld-tigcc.

I could support building against a system libtifiles2, but for the few functions I'm using from it, I don't see how it's worth it. It'd also drag in libticonv and glib2 which aren't used by dasm-tigcc at all. For the other copied/forked stuff, there's no system library I could link against, it's all portions of application source code. (Well, I guess strictly speaking I could build a shared copy of libopcodes, but there's no such shared version of it, and I use differently-patched copies of libopcodes for assembling (GNU as) and disassembling (TiEmu, dasm-tigcc): the instruction tables for disassembling contain the dots to make the disassembler output nicer - it's not easy to automatically add them because e.g. no.p or rt.s doesn't make sense -, but those dots break the assembler.)

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]" ?

It's OK, but isn't the word "Additional" redundant? You can add "Developer" or something like that if you think "TI-68k Tools Suite" is too generic. Or "TICT TI-68k Tools Suite" maybe?

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;

I wouldn't lose too much time on "shrn" if I were you, it's inferior to ttunpack-small in all metrics. I originally investigated it for licensing reasons, but the ttunpack-small license is now actually more liberal (LGPL with exceptions vs. LGPL without exceptions - a pstarter built against shrnklib cannot be legally distributed in binary-only form, you have to provide a way to relink which, given how the code is included, is the whole pstarter source code). And the shrnklib algorithm is slower and both the decompression code and the compressed executables (in most cases) are larger. So I don't see much benefit in supporting it. Maybe the best thing to do is to just cvs rm it. I don't know anybody who ever used it, other than me, for testing only (and I quickly discarded it as crap).

By the way, the LZMA code should probably get updated to the latest LZMA SDK, which is now public domain. That should clear up any questions on whether we can allow unmodified launchers with LZMA support to be distributed without source code. (The LZMA SDK originally had an exception similar to ours and our copy is modified to save as much size as possible, so we would have needed permission from the author to extend the exception to our version.)

* ttmem is useful for testing under low-memory conditions (I remember someone fixing bugs in his memory handling code after using ttmem);

All the tools are useful. That doesn't mean it makes sense to ship them with the toolchain.