Good luck to all the awesome 68k programs!

Ditto.

Here's a list of the program names with authors and "affiliation" (the forum they're mainly on):

Air Mission: Vincent Corfdir (Ti-Gen, username: Orage)
Astrosmash: David Randall (TICT HQ, username: Ranman)
Atomic Arena: Link: Vincent Corfdir (Ti-Gen, username: Orage)
ClosedGL: David Teitlebaum (neutral) (*)
Corridor 99: Jeff Wilcox (TICT HQ, username: Kimbett)
FlashZ BomberMan: Flavien Racine (yAronet, username: FlashZ)
FreeFlash: Olivier Armand (neutral, username: ExtendeD) (**)
gb68k: Ben Ingram (TICT HQ, username: MastaZog)
grav: bobti89 (Ti-Gen, yAronet)
Hawk: Olivier Givaudan (Ti-Gen, username: Nul)
Kirby's Quest: Krzysztof Rodak (TICT HQ, username: krodakus)
M4r10: Jean-François Geyelin (Ti-Gen, username: JfG, Jyaif on TICT HQ)

(*) I'd definitely not vote for this one, closed-source static libraries are just asking for compatibility problems later on! It's definitely not encouraged or supported by the TIGCC Team. Static libraries have to be rebuilt sometimes for ABI changes in TIGCC itself, compatibility with newer calculator hard- and software etc. (For example, Xlib and GraphX are essentially useless these days.) The static library mechanism is intended to save compilation time, not to let you keep your source secret.

(**) What makes FreeFlash interesting is that V200 and Titanium FlashOS support in TIGCC would be essentially useless without it.

PS: TICT HQ / TIGCC message board rulez! But I'm not telling you what to vote, am I? ;-)

You're always funny ^^

Why do you have to turn everything into a political argument? GPL isn't the "one true way". Closed source libraries don't necessarily cause incompatibilities, either. People with closed source libraries can document the APIs and keep the behaviour consistent. Depending on undocumented behaviour of closed source libraries is what causes compatibility problems. We all link against OS libraries on Windows, MacOS and Solaris. The OS vendors make an effort to maintain compatibility, and it works.

There are probably more compatibility problems with different versions of open source libraries. (glibc, I'm looking at you)

There is another issue: when a new TI hardware or software (AMS) appears, compatibility may be broken if the lib isn't maintained anymore and the source closed.
Anyway since this lib is (to me) more a technological demonstration than something potentially useful, it doesn't really matter.

Or a new version of TIGCC. We have never promised binary compatibility, only source compatibility (which we are working hard to maintain), and this policy isn't going to change any time soon. But even if it did, TI's upgrades would remain a problem.

If you break binary compatibility, it's TIGCC causing the compatibility problems, not the library itself. Not promising binary compatibility is like saying "we reserve the right to screw users of our product".

No, it's saying: We reserve the right to move on with technology. Given that source compatibility is maintained, building your program with a new version of TIGCC is just a matter of recompiling. (Even the TIGCC 0.6 example programs still work (though one needs a #undef jmp_buf to work around a name conflict which was unavoidable because of ISO C compatibility)!)

We assume that people using TIGCC are developers who use source code. Closed-source libraries ARE NOT and WILL NEVER BE supported. DON'T use them, if you get screwed by binary compatibility issues, it's your own damn fault for using closed source. Static libraries need to be recompiled from time to time. Static libraries are precompiled only to save compilation time, not to allow you to hide the library's source code.

Now if you still feel like whining about binary compatibility breakage, complain to TI, not us, they've caused far more breakage (requiring a recompile or patches like the Voyage 200 Executables Patcher or GhostBuster) than TIGCCLIB ever did.

I happen to be a professional full-time developer. I make my living this way. Open source might be a noble ideal, but the fact is, a lot of businesses would never make money that way. IP protection is important. I work hard, and I expect something to be able to feed my family at the end of the day. Open source also create a huge support burden when people expect you to help them with modified versions of your software.

And before you bitch that I've never worked on open source, I've contributed to ytin (ytin.sf.net) and other projects, and pretty much built e606iokit (e606iokit.sf.net) by myself. Of all the e-mails I get about open source software I've written, 99% are pure bitching. Almost no-one wants to contribute, but everyone thinks I have an obligation to implement their pet feature, or fix their pet bug. It's a frustrating experience that doesn't help anyone in the end.

> I happen to be a professional full-time developer. I make my living this way.

But not on calculator software, do you? I wish anyone trying to make a living out of calculator software good luck, they'll need it. And IMHO trying to make a living out of TIGCC static libraries is just insane, so that's really not a good reason to make them closed source.

> Open source also create a huge support burden when people expect you to help them with modified versions of your software.

I just tell them to use my official version or get lost.

> Of all the e-mails I get about open source software I've written, 99% are pure bitching. Almost no-one wants to contribute, but everyone thinks I have an obligation to implement their pet feature, or fix their pet bug. It's a frustrating experience that doesn't help anyone in the end.

While you're not entirely wrong, your whine about binary compatibility is part of the problem, not the solution. It's "bitching" for a "pet feature" too.

>>It's definitely not encouraged or supported by the TIGCC Team.

The royal plural? For all intents and purposes isn't the tigcc team currently only you Kevin?

But I won't for it because it lacks double buffering.

What does it matter anyways, Kevin is doing a good job keeping TIGCC together for being by himself for the time being. Besides, if it wasn't for Kevin and the TIGCC Team, most of this stuff here wouldn't exist :)

Currently, it's essentially just me, but it wasn't always like that, and I'm still hoping for better times. Jonathan Holbrook has offered help on the documentation and has started doing some work, let's see what will come out of that.

How long are you willing to keep up the project?

I have no plans to stop working on TIGCC right now. (I didn't do much TIGCC work the last few weeks though, I hope I'll have more time soon.)

What kind of help do you need? I don't always have a lot of time, but I'd be happy to help when I do…

Well, what skills I have a use for:
* documentation maintainer(s) -> please coordinate with Jonathan Holbrook,
* a Delphi coder to maintain TIGCC IDE and tigcc.exe -> mostly keeping stuff up to date, not much work, but you need Delphi 6 or higher installed and probably some (at least basic) Delphi experience,
* C++/Qt coder(s) to help me out with KTIGCC (TIGCC IDE for KDE) -> needs Linux, Qt, KDE, some Linux development tools (I'm currently using Anjuta and Qt Designer), preferably some Qt experience (though I don't really have any and I still get along by looking up stuff in the docs), and most importantly you'll have to coordinate with the other coders (currently just me, but at least one person already offered help),
* possibly some plain C stuff or even on-calc C/ASM stuff (TIGCCLIB) too, to discuss per e-mail.

I'm trying to work on a TIGGC IDE for Mac OS X in Cocoa. I have the basics together, but I'm still learing Cocoa. Writing the KTIGCC would be good for that. One possible problem: I use Gnome (in Ubuntu). Also, I'm having troubles installing packages ouside of the package manager. TIEmu and TiLEM say my gpp isn't sane. And for some reason, the skinedit for TIEmu is in the package manager, but TiEmu isn't.

You can:
apt-get install kubuntu-desktop
to get the main KDE packages installed. You'll probably also have to fetch a few "-dev" packages, and the "qt-assistant" package. They should be all in the Ubuntu repos, at least in "universe".

You'll also want to register for a free SourceForge account so I can give you CVS access.

As for TiLP and TiEmu: if you're running Ubuntu on an x86 machine, you can try to run alien on my binary RPMs. I'm not sure how well it will work (the main problem is that while the files and the pre-/post-install scripts are converted, and while an attempt at adjusting file locations is done, some stuff still assumes a Red Hat setup; there may also be library incompatibility issues, there's no way I can guarantee that my binaries run on anything other than Fedora Core 4), but it's worth a try.

If alien doesn't work or if you're trying to install things on Ubuntu on your PPC Mac, then you won't be able to get around building from source. But if you want to develop software, you'd better learn how to get compilations working anyway. ;-)

Oh, and one thing I should warn about: KTIGCC assumes KDE or at least Qt all over the place, so you won't easily be able to port the existing code to Cocoa. At best, you can try to #ifdef in the use of Cocoa dialogs instead of KDE ones (maybe just using the Qt classes will work, AFAIK Qt uses native dialogs everywhere except on Linux), but you won't be able to get rid of the Qt dependency without rewriting everything, and getting rid of KDE would also mean rewriting all the syntax highlighting support, which is based on the Katepart. The best course of action to get KTIGCC working on OS X quickly will probably be to target KDE running on the native Qt/Mac (not Qt/X11).

>> apt-get install kubuntu-desktop

thanks

>> You'll also want to register for a free SourceForge account so I can give you CVS access.

I'll probably have to do some poking around SourceForge - I'm not very familiar with it.

>> As for TiLP and TiEmu: if you're running Ubuntu on an x86 machine, you can try to run alien on my binary RPMs.

Ha! I'm using PPC Ubuntu. I guess that probably means "have fun getting anything at all to work".

>> If alien doesn't work or if you're trying to install things on Ubuntu on your PPC Mac, then you won't be able to get around building from source.

I thought that's what I was doing with ./configure . Bummer.

>> Oh, and one thing I should warn about: KTIGCC assumes KDE or at least Qt all over the place, so you won't easily be able to port the existing code to Cocoa.

Oh, I just want to get familiar with TIGCC as a dev. environment - I haven't ever used it, and I figured I'd make a crappy IDE if I've never used it. I am planning on writing it totally new in Cocoa, using its advanges.

The usual ./configure; make; make install routine is indeed building from source. If that isn't working, then:
* check the error messages you get,
* if it complains about missing components (either during a configury or during linking), please install what's missing and retry,
* if there are other errors, please report them to gtktiemu-devel@lists.sf.net and I'll look at them (and maybe Romain will, too).

I have an account, sending an email.