Lionel DebrouxLe 26/01/2009 à 10:37
Thanks for posting your opinion.
Yes, otherwise I wouldn't have done it
Some of the reasons why it makes sense to Thomas and me have been detailed in ticket #42, https://trac.godzil.net/gcc4ti/ticket/42 . Another one is below.
That the tools are part of the GCC4TI repository doesn't prevent anyone from making them a standalone package
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 ? We're looking at easing the user experience, see also ticket #30 ( https://trac.godzil.net/gcc4ti/ticket/30 ).
Well, these tools are very low maintenance. In years, the only modifications have been:
* 64-bit compatibility;
* the recent improvement to ttbin2str which enables readding it in the suite;
* addition of ttsetname;
* deletion of ttdasm. 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 ?
A duplication of efforts on that item would mean that there's no cooperation between TIGCC and GCC4TI on that item, and that would not be good. As I already wrote multiple times, having different goals & timelines, and disagreeing on various technical matters, doesn't mean that TIGCC and GCC4TI can't cooperate (in fact, they do, !).
OK, there has been a duplication of effort on stdint.h. That one was really unintentional, and the blame lies on both side: we didn't open the GCC4TI infrastructure soon enough - we did less than two weeks later, along with the first public release - and you didn't install a feature request tracker that would have enabled us to post the feature request itself and that we worked on it. And I started attending #tigcc in order to try avoiding reoccurrence of this.
I was not aware of that.
I disagree, see above
(To me, the step backwards was dropping the tools in 0.96 Beta 7 r1
)
We may rename "GCC4TI Tools" to "GCC4TI/TIGCC Tools" or "TIGCC/GCC4TI Tools", if that's a problem for you. 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).
What about backwards compatibility if we remove ttppggen ?
Do you really think this makes sense?
Yes, otherwise I wouldn't have done it
Some of the reasons why it makes sense to Thomas and me have been detailed in ticket #42, https://trac.godzil.net/gcc4ti/ticket/42 . Another one is below.
Much of the tools suite can be used with no toolchain at all, so I think having it as a standalone package is much more useful.
That the tools are part of the GCC4TI repository doesn't prevent anyone from making them a standalone package
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 ? We're looking at easing the user experience, see also ticket #30 ( https://trac.godzil.net/gcc4ti/ticket/30 ).
In addition, it would make it easier to use the same tools with TIGCC and with GCC4TI and prevent a completely useless duplication of efforts.
Well, these tools are very low maintenance. In years, the only modifications have been:
* 64-bit compatibility;
* the recent improvement to ttbin2str which enables readding it in the suite;
* addition of ttsetname;
* deletion of ttdasm. 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 ?
A duplication of efforts on that item would mean that there's no cooperation between TIGCC and GCC4TI on that item, and that would not be good. As I already wrote multiple times, having different goals & timelines, and disagreeing on various technical matters, doesn't mean that TIGCC and GCC4TI can't cooperate (in fact, they do, !).
OK, there has been a duplication of effort on stdint.h. That one was really unintentional, and the blame lies on both side: we didn't open the GCC4TI infrastructure soon enough - we did less than two weeks later, along with the first public release - and you didn't install a feature request tracker that would have enabled us to post the feature request itself and that we worked on it. And I started attending #tigcc in order to try avoiding reoccurrence of this.
Also note that TIGCC/*nix used to bundle the tools suite and I dropped that in 0.96 Beta 7 r1.
I was not aware of that.
What you're doing is a step backwards.
I disagree, see above
(To me, the step backwards was dropping the tools in 0.96 Beta 7 r1
)
We may rename "GCC4TI Tools" to "GCC4TI/TIGCC Tools" or "TIGCC/GCC4TI Tools", if that's a problem for you. 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).
What about backwards compatibility if we remove ttppggen ?