Ticket #31 (closed enhancement: fixed)
Provide ar-tigcc, ld-tigcc and patcher as standalone executables on Windows ?
| Reported by: | debrouxl | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | Version 1.00 |
| Component: | project | Version: | 0.96 |
| Keywords: | Cc: |
Description
On *nix, these tools are standalone executables, called by the tigcc front-end through fork/exec.
On Windows, they are not standalone executables:
- ld-tigcc is a DLL, loaded by the tigcc front-end and called through the LinkFiles? entry point;
- ar-tigcc is the same DLL as ld-tigcc, just a different entry point: CreateArchive?;
- patcher is written in Delphi source (ParseSFile in ParsingUnit?.pas) and embedded in tigcc.
(The reason why it's done that way on Windows, is that on 9x/ME, is to minimize process creations. Process creation is significantly slower on those antiquated versions.)
Should, in your opinion, these tools be provided as standalone executables on Windows as well, so that they can be used in scripts ?
In TIGCC, these tools aren't provided as standalone executables because Kevin says that these are *internal* tools that are supposed to be called through tigcc, but not called directly.
In a way, he has a point, since tigcc acts as an abstraction layer.
There's at least one use case (whole program compilation) which would make it necessary because tigcc just isn't done for such a purpose. I tinkered with it once on TI-Chess 4.17.
However, with GCC 4.1 in TIGCC, the whole program compilation mode is not too viable an option, because the -fwhole-program --combine mode of the compiler isn't very stable. It would probably be better with GCC 4.3 and 4.4, if and when the TIGCC patch is ported to those versions.

For information, a discussion yesterday evening on #tigcc revealed that Kevin's todo list for the "Window$" / "Winblow$" version contains making tigcc and KTIGCC (and possibly the Delphi IDE during a transition period) use standalone ar-tigcc, ld-tigcc and patcher executables.