(and welcome to those who have known of GCC4TI through ticalc.org )
A few weeks ago, we've requested, on multiple message boards (TIGCC/TICT, here, TI-Freakware), comments on whether to keep Windows 9x/ME support in TIEmu and TILP. We're now requesting comments on another aspect of TIGCC & GCC4TI: their set of tools, and organization (modularity, etc.) thereof.
Again, the reason why we're asking the community is that the community members can (and do) give us some input about what tools they currently use, and how they use them (perhaps in interesting ways that are not currently planned). They can (and do) also give input on what they would like to do.
In this post, we'll try to present things both from a user's perspective, and from the toolchain maintainers' perspective.
(if you don't feel like reading my large block of text, you can skip to the last paragraph )
In the current state of TIGCC / GCC4TI, there are multiple occurrences of code duplication. Both TIGCC and GCC4TI would like to solve the problem, in order to reduce maintenance and most of all, ease new development.
Let's go into more detail:
____* TIGCC IDE (Delphi) vs. KTIGCC 1 & KTIGCC 2 (C++).
* other tools:
____* tigcc command-line tool: there's a Delphi version for Windows and a C version for *nix...
____* ld-tigcc (TIGCC linker), ar-tigcc (TIGCC archive creator): used as a DLL on Windows, as standalone executables on *nix. The Delphi interface to the DLL sucks, triggers code duplication of its own, and makes further development harder...
____* patcher: this simple tool is embedded as Delphi code in both the Delphi IDE and the Delphi tigcc command-line tool. It's a standalone executable on *nix.
____* tprbuilder: overlap between the functionality of tprbuilder (written in C) and the TPR building code embedded in the Delphi IDE and KTIGCC 1/2 (written in C++). tprbuilders and the IDEs are not fully compatible, though: it's definitely possible to make TPRs that work in one kind of tools, but not in the other.
Advantages of the Delphi IDE:
____* users don't have to install a framework.
Drawbacks of the Delphi IDE:
____* Windows-only (though it runs on Wine - note that I have never tried communicating with an emulator or a real calc under Wine).
____* written in a lesser-known language, poorly commented code.
____* code is not modular at all, see "other tools" above. Let's also mention the Windows-specific emulator & real calculator linking code (which does not support some cable models).
Advantages of KTIGCC:
____* when both KTIGCC 3 and KDE 4 for Windows are ready, a single code base could work on both Windows and *nix.
Drawbacks of KTIGCC:
____* two incompatible code bases, both of which need to be maintained for a while because they have different sets of users:
________* KTIGCC 1: uses Qt/KDE 3.x, *nix only. Usable on GNU/Linux distros which focus on stability (e.g. Debian Etch, the upcoming Debian Lenny, and derivatives thereof). Given the rate of Debian releases (20-23 months for the three last releases), this should be maintained for more than two years;
________* KTIGCC 2: uses Qt/KDE 4.x, *nix only. Usable on GNU/Linux distros which focus on making their users test out the latest technologies (e.g. Fedora). Kevin wrote that KTIGCC 2 is not feature-complete, IIRC. KTIGCC 2 with fixes for non-portable constructs will become KTIGCC 3.
____* on Windows, and a number of GTK+/Gnome-based *nix, users have to install Qt and the KDE framework. On Windows (majority of the user base, as far as we can tell), kde4win is currently far from production quality...
Though KTIGCC 1 & 2 use external standalone executables, which is definitely a step forward, linking to emulators & real calculators is not externalized, and the functionality of tprbuilder is partially rewritten in C++.
To sum things up...
* KTIGCC is definitely a step towards more maintainable code. However, we (GCC4TI) feel that:
____* it's a leap backwards in the footprint of the TIGCC environment (we're talking dozens of megabytes of framework to run a small IDE which has few features that other IDEs don't have, and misses a number of features that common IDEs have...) and the complexity of the installation process. All the more there's already GTK+ for TIEmu and TILP, another *nix-originating framework that yields non-native applications.
____* it doesn't go far enough for modularity and flexibility.
* as a native program, the Delphi IDE is more user-friendly (native UI, no framework installation process). However, it's in dire need for a software re-engineering. No Delphi expert has manifested him/herself to aid in re-engineering...
In another (French-speaking) section of yAronet and on the GCC4TI feature request tracker (between others), we have discussed several ways to go forward from that situation:
* move enough things outside from the Delphi IDE so that it becomes little more than a graphical front-end to tools that do the actual work (and thus, it becomes rather low maintenance). This is a pattern commonly used on *nix, because it is well suited to both scripted use and interactive use, and yields low code duplication rates: let's mention only cdrtools, Sleuthkit, Nmap, MPlayer, Git and their graphical front-ends K3B/Brasero/etc., Autopsy, Zenmap, KMplayer, git-gui&gitk.
____* ld-tigcc, ar-tigcc, patcher (TIGCC and GCC4TI agree that all three should be external executables on all platforms, even if that means slower operation on Windows 9x/ME);
____* tprbuilder, to which a compatibility mode for the IDEs' behaviour should be added (so as to preserve backwards compatibility with both the IDEs' and tprbuilder's behaviour);
____* <to-be-named> application for emulator & real calculator linking. TILP's GUI-less mode can be a first step.
(and keep KTIGCC for *nix platforms, maybe with a bit of code de-duplication)
* scrap both the Delphi IDE and KTIGCC, and rewrite the IDE in C++ with a dependency on Qt only. We lose some convenience classes, but we don't depend on something which won't work well for quite some time.
* scrap both the Delphi IDE and KTIGCC, and rewrite the IDE in C#/.Net. Portability would be good (through the use of Mono), but from a user's POV, that's trading a non-default-installed framework with another non-default-installed framework (only a different group of people would be inconvenienced).
With the two latter solutions, it would be easier to introduce a better project format than TIGCC's proprietary build system (TPR) is, than modifying the existing code to try to handle both TPRs and a better project format. The general inflexibility (convoluted ways of doing things that are simple when using the tigcc command-line tool) and incompleteness (there are things that TPRs just cannot do) of TPR have been known for years to multiple developers. That's the topic of ticket #14, https://trac.godzil.net/gcc4ti/ticket/14 .
So, users... in your opinion, should we give up on lightweight IDEs for the Windows platform, even if KTIGCC 3 won't be too usable before months, or even a year ? (there are many other tickets on the todo/wish list, don't worry )
Is there someone knowledgeable in Delphi who would like to - and have enough free time to - help with re-engineering the Delphi IDE ?
Thanks in advance a lot for your feedback (and your contributions, if any)