Lionel Debroux (./2) :
Not that either Thomas or I really see the point, though. These tools are small, and still used by multiple active developers (to name three of them: Ranman, Lachprog, Folco) as part of build scripts.What's the point of requiring users to go fish themselves for yet another set of tools ?

I don't see how yum install tigcc-tools-suite is a problem. Even on W32 you just have to download and unzip a zipfile, the TIGCC Tools Suite doesn't even have an installer. And having them be separate packages allows using one without the other. Not all uses of the tools are in conjunction with TIGCC, and not all TIGCC users need the tools either.

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.

We may rename "GCC4TI Tools" to "GCC4TI/TIGCC Tools" or "TIGCC/GCC4TI Tools", if that's a problem for you.

What about a neutral name like "TICT Programming Tools Suite"? Having "TIGCC" in the name occasionally confused some users (they didn't understand that TIGCC Tools Suite != TIGCC - the same goes for "GCC4TI"), and also as I said, those tools can be used without TIGCC. (The eBook tools you removed are perfect examples, but there are more tools which can be used without TIGCC. For example, ttbin2str may be useful even for TI-BASIC programmers.)

But having them within TIGCC / GCC4TI makes sense for reducing present (pucrunch-related code in ld-tigcc code, I didn't even think of it) and preventing future (e.g. variable name checking code) duplication.I'd tend to see the reduction of the ttppggen / ld-tigcc code duplication the other way round, i.e. modifying ld-tigcc to use chunks of ttpack/ttppggen code in a way or another (either as an external executable, or as embedded code, since most tt* are meant to be embedded in other C files).

The problem is that this makes standalone releases out of the version in your repository, as you suggest:

That the tools are part of the GCC4TI repository
doesn't prevent anyone from making them a standalone package

very hard. 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. But sharing code across components makes that hard.

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

What about backwards compatibility if we remove ttppggen ?

ttppggen should definitely stay, it's also useful to compress somebody else's program without needing to recompile it. But it belongs into the separate "TICT Programming Tools Suite" package, not TIGCC nor GCC4TI. TIGCC/W32 never included ttppggen. TIGCC/*nix did, but didn't use it internally, it was just including the entire tools suite. It no longer does.