- With simple XSLT processor and XSL file, we can transform the XML Project file to anything else (like TPR, Makefile etc..)

... oh, yes, good idea

- XML is handled in a numerous lib (in .Net, Java, even C/C++ !) and we don't need to write a parser and any file verification functions

Well, so is the Properties format, used in TPRs

- XML is text, so human readable- XML is extensible, so even if we add new non critical functionality and that we done it correctly, old version of GCC4TI could use new XML Project files

Yes.

For example, Makefile files are really horrible to parse and is, for me, not useable for storing project informations. Maybe Ant files, but it's a bit too tied to Java. CMake files are more like Makefiles..

Ant and Maven are generic build systems with a plugin architecture... but they have a verbose XML syntax, and they're rather heavyweight (especially Maven). Not to mention writing plugins for them plain sucks.

But with XML we need to make and publish it the XSchema of the XML Project file to validate them, and it's really a boring task...

As squalyl mentions, a DTD would probably be good enough at first: it's less powerful, but easier to write IMO.
But I agree, neither DTDs, nor XML Schemas, nor RelaxNG descriptions (I'm told that the latter has advantages over XML Schema) are fun to specify and write...

Not really linked with this topic, but, I think that if we post a lot of topic about trac ticket, it will be more correct to add a new category, even if the forum is not really hyperactive, for storing them...

Why not

And I think that it could be a good idea if trac can post automaticaly new tickets (and comments on trac) in the good forum.. (but this will need an autorisation from yAro like for PocketMag's forum)

+1.


./3: if it weren't that Code::Blocks or similar well-featured IDEs are rather heavyweight, and complex for beginners (not to mention it adds complexity to the install process, something we've loudly complained about when Kevin told he wanted KDEWin for KTIGCC 3... we should be coherent), I'd say in a heartbeat:
'screw our small IDE: we should care only about making plugins for other IDEs, that add them TIGCC project handling and VTI/TIEmu communication (the only distinctive features of TIGCC IDE / KTIGCC).
That would enable us taking advantage of better IDE environment than TIGCC IDE or KTIGCC are, without having to reimplement the wheel (multiple targets, project groups, project dependencies, etc.)'