[mOved] Ticket #14 "(Improve|create new) TIGCC project format": discussion... - Page 1

Discussion for ticket #14: http://trac.godzil.net/gcc4ti/ticket/14

The combination (TIGCC IDE|KTIGCC) + TPR has several well-known drawbacks. (At least) the following shortcomings of (TIGCC IDE|KTIGCC) + TPR should be addressed:

[ul][li]behaviour with relative paths...[/li]
[li]the '1 project = 1 compilation of a given program' mantra is horrendous when there are MANY programs (ExtGraph: 33 demos + 1 other test program, this number will increase);[/li]
[li]TPRs don't make it simple to compile subsets of the program with different compilation options (TI-Chess). I mean, multiple TPRs that make function archives and link everything together is rubbish [/li]
[li]TPRs are not designed for multiple compilations, e.g:
[ul][li]on-calc-incompatible programs (mostly all TICT programs);[/li]
[li]multiple language localizations (TI-Chess, TICT-Explorer).[/li][/ul]
[li]Handle 'verbose' mode of tprbuilder and the tools it calls. The current KTIGCC doesn't understand verbose mode and thinks many things went wrong...[/li][/ul]

About XML, even if you think that it is a bit bloated for what we need, there is at least some reason that can led to use XML instead of another format :

- With simple XSLT processor and XSL file, we can transform the XML Project file to anything else (like TPR, Makefile etc..)
- 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
- 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
- and more

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.. No seriously I can't see anything else that can surpass the XML...

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...

---

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...

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)

We don't need any schema and dtd at the beginning even if it's a good thing to do

Lionel Debroux (./1) :
the '1 project = 1 compilation of a given program' mantra is horrendous when there are MANY programs (ExtGraph: 33 demos + 1 other test program, this number will increase);

No problem we can have project groups and project dependencies
Code::Blocks is my inspiration there

We can also define several targets in project files, that have different compilation options / files

XML is also well supported by Qt so I won't have any problem to use it in the IDE (yes it's sleeping but I'm not leaving it, I want a clear specification before coding ^^)

Oops, I went posting the link of this topic in the topic that lists them, and I forgot to post squalyl's message...

some propositions
[ul][li]gcc4ti projects should be in xml form[/li]
[li]gcc4ti projects should not decorrelate physical directories and project directories (this one is really ugly X_X)[/li]
[li]gcc4ti projects should support relative directories, based on project file path. When adding source files (c/h/s/asm), path mode should be relative. When adding library files, the user should have the option to choose between relative and absolute paths. (inspired by codeblocks)[/li][/ul]

I replied that I tend to agree on all three items, even if I'm not extremely fond of XML for simple usages (which Godzil replied to in ./2).

- 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.)'

so, what IDE are you thinking about?

Eclipse => huge
Netbeans => idem
No java please it's not beginner friendly to have to install a huge framework. Maybe the KDE libs are better than having Eclipse, the java runtime, and all the mess to write a plugin, 68k asm support, etc.
Ant => maven => rather complicated. And we can generate build.xml or other things using a simpler 'master' project file.

Code Blocks? We have to write 68k assembly support, syntax highlighting. Using external makefiles is not an option. And this ide is made to be generic, it's not specific to gcc4ti and all his options, etc.

Others I don't know?

I'm starting to write some bits using Qt. Qt already has xml support, is not so big and is cross platform. This way, we can have all the features we need without dragging a huge "usine à gaz".
About the XML format, I want to make it simple, ie writable by hand. I DONT want machine readable XML that no one can understand by looking at it. It's a design decision. Do we really need an xml schema or anything like that? Even a DTD is sugar. The IDE can simply fail when it does not find the required xml elements.

Lionel Debroux (./6) :
(multiple targets, project groups, project dependencies, etc.)'

All these features are rather simple wheels if designed properly. I'm not fond of taking a lot of time to dive into an unknown code, we'll never find it 100% suited for our needs, and all the required fixings will be hacks, patches, and problems with upline synchronizations and etc, which will make unmaintainable code.

so let's agree on required features for the project format:
-human readable
-multiple projects runnable with a single command -> project groups
-relative filename support
-multiple targets with different file sets and options
-build has to be done on real FS paths even if files are displayed in virtual directories.

I was thinking mostly of Code::Blocks, which you introduced me to
But if we have to do more things than just writing an add-in to the project management for handling TIGCC project specificities (if possible at all) and handling IDE <-> VTI/TIEmu communication, it becomes less interesting...

DTD, XML Schemas and/or RelaxNG can be used by some programming environments for partial generation of code that can handle the corresponding XML data, not to mention it helps validation.


Agreed on those five features. Relative filenames should be supported as much as possible (or the user should be asked whether to store an import as relative or absolute filename, as you mentioned somewhere).

-human readable
-multiple projects runnable with a single command -> project groups
-relative filename support, at the user option (default relative for source files, can be made absolute; default absolute for libraries, can be made relative)
-multiple targets with different file sets and options
-build has to be done on real FS paths even if files are displayed in virtual directories.

Remember that most of the time, these xml files will get generated by the IDE. They will be generated as valid
And validation can be made programmatically, structure will be kept simple.
I will only implement an automatic xml validation if it's faster, lighter and simpler that verifying the structure by myself. I already programmed an xml loader without any dtd: I just reported an error when some necessary element was not found. If the user wants to embed invalid elements, do we really care? Example: I really don't care to have a <toto> element in a list of <source> elements

my main goal is: be useful to the user. The user don't care about xml internals, he cares about a project file that works.

I will only implement an automatic xml validation if it's faster, lighter and simpler that verifying the structure by myself. I already programmed an xml loader without any dtd: I just reported an error when some necessary element was not found. If the user wants to embed invalid elements, do we really care? Example: I really don't care to have a <toto> element in a list of <source> elements

Agreed for the handling of superfluous elements and of missing mandatory elements
Programmatic validation is necessary to check types (e.g. if expecting a boolean, then it must be either the "true" or "false" strings in XML; if expecting an integer, then it should be an integer), though.


For GCC4TI Projects (.gpr ?), I guess we could find inspiration in the syntax of Code::Blocks projects (which, er, don't seem to have a DTD or XML schema ). Maybe I'd nest some items a bit less thoroughly, e.g.

<Compiler>
    <Add option="-O2" />
    <Add option="-W" />
    <Add option="-Wall" />
</Compiler>

could be made with a single
<compileroptions><![CDATA[-O2 -W -Wall]]><compileroptions>
but that's just a matter of taste.

[EDIT: make my example well-formed XML ]

yes no problem with that.

and yes c::b has a nice project format.
it also has a workspace concept which is a group of project with dependency management among projects.

what about keeping a one-file one-project-and-many-targets fashion, and a separate program group concept, which load existing projects? (this is the code blocks model)

for genlib you would have a genlib-main project, a series of genlib-example-* projects and a genlib project group which gathers all projects?

this gives me the idea of virtual projects that only have dependencies (to build all projects at once) and no source files. what do you think?

sample xml file in my view:

<project name="toto" type="binary|staticlib|kernellib|...">
<!-- files for all targets-->
<file name="../src/main.c" />
<file name="../include/lib.h"/>
<file name="../src/asm/target.s" />
<lib name="/usr/lib/ti/libmath.a" />
<target name="ti89-debug" model="ti89">
<file name="../src/ti89.c" dispfolder="platform/ti89" />
<lib name="/usr/lib/ti/libalacon-89.a" dispfolder="libraries" />
<compiler options="-g -DTI89" />
</target>
<target name="ti92-debug" model="ti92p">
<file name="../src/ti92p.c" dispfolder="platform/ti89" />
<lib name="/usr/lib/ti/libalacon-92p.a" dispfolder="libraries"/>
<compiler options="-g -DTI92PLUS" />
</target>
</project>

<project type="group">
<ref project="library.gpr" />
<ref project="example1.gpr" depends="library.gpr" />
<ref project="example2.gpr" depends="library.gpr" />
<virtual name="all examples" depends="example1.gpr example2.gpr" />

seriously, we need to define the syntax more precisely.


-human readable
-multiple projects runnable with a single command -> project groups
-relative filename support, at the user option (default relative for source files, can be made absolute; default absolute for libraries, can be made relative)
-multiple targets with different file sets and options
-build has to be done on real FS paths even if files are displayed in virtual directories.
-project groups in separate files
-virtual projects in project groups, only have dependencies, used to build groups of projects in one command
-project extension .gpr, project group extension .ggp, .gpg, .gpx (?)

what about keeping a one-file one-project-and-many-targets fashion, and a separate program group concept, which load existing projects? (this is the code blocks model)

I'm for it
I'm positive Code::Blocks isn't the only IDE that has this model.

for genlib you would have a genlib-main project, a series of genlib-example-* projects and a genlib project group which gathers all projects?

Looks sensible to me.
The concept of example series could make sense (but how to define that ?): I'm not really eager to trade a scalable pair of simple script/batchfiles, that build one executable at a time, for n different (sub-)projects (currently, for ExtGraph, n=33)

this gives me the idea of virtual projects that only have dependencies (to build all projects at once) and no source files. what do you think?

On the one hand, it shouldn't be hard to code, and it would enable users to use even fewer non-GCC4TI tools to get things done (making the user experience more seamless).
On the other hand... that's extra trouble on us; scripts/batchfiles that build multiple projects with tprbuilder (gprbuilder) are easy to make (and having to make them would teach users that scripting languages are useful).

seriously, we need to define the syntax more precisely.

Er... I won't be able to resist...
That's a possible usage of DTDs, XML Schemas and RelaxNG definitions, you know

(DTDs, XML Schemas and RelaxNG definitions are not exactly easy to read, I know )

-project extension .gpr, project group extension .ggp, .gpg, .gpx (?)

.gpg cannot be used, what about .gpw (for workspace) ?
For the record, Visual Studio (at least the older versions ?) has .dsp (projects) and .dsw (workspaces).


GTC won't become the main target of GCC4TI, but since we're in the pre-design and design phase, we can make some choices that help supporting it (starting with abstaining making choices that make it harder to support it). We could provide an optional attribute that tells GCC4TI that the user would like to use GTC, e.g.:
<compiler [b]type="gtc"[/b] options="-g -DTI89" />
The targets system would make it possible to support both tigcc and gtc in the same GCC4TI Project.

-human readable
-multiple projects runnable with a single command -> project groups
-relative filename support, at the user option (default relative for source files, can be made absolute; default absolute for libraries, can be made relative)
-multiple targets with different file sets and options
-build has to be done on real FS paths even if files are displayed in virtual directories.
-project groups in separate files
-virtual projects in project groups, only have dependencies, used to build groups of projects in one command
-support for other compilers, e.g. GTC
-project extension .gpr, project group extension .gpw-targets: executable (optionally packed), static lib, kernel lib, flash application, OS

for the syntax: we need all features before. OK for a dtd, but shouldnt be necessary

I want to say that implementation/coding difficulty is not an issue. All of this is not difficult to code if it's well conceived. What I want is a "sort of" Entity/Relationship diagram, and we'll deduce a data structure to handle it. It will also help us to define the class diagram inside the application.

If you want a project group that will manage dependencies for you you're free but not obliged.
But if you want to use batch files, no problem, just call the gprbuilder command line tool for each project

for the syntax: we need all features before.

Agreed.
I feel we need more people to comment on this topic. I guess I'll post something to the ML. Maybe it's time to invite several English-speaking users (I'm thinking especially of lachprog) on the GCC4TI infrastructure, too ?

What about using QScintilla for parsing and syntax highlighting ?
Just an idea: I've never used it, I don't know whether it's easy to use.

I use the basic support for code completion of SciTE, but I don't know whether it's programmed in SciTE or the underlying Scintilla.

I vote for Makefile. It is not so hard to parse if you force the format and you can even use a generic Makefile controled/generated by the IDE to select the options.

Yes but if the user edits the makefile, everything breaks.

This makefile can be generated by gprbuilder or the IDE, if you want it.

squalyl (./16) :
Yes but if the user edits the makefile, everything breaks.

Why ?

squalyl (./16) :
This makefile can be generated by gprbuilder or the IDE, if you want it.

If this is the case, I prefer using my own makefiles.

you don't like xml do you ?

While pretty much all (GNU/)Linux distributions have `make`, it is not present under Windows, which is the vast majority of our user base...

squalyl (./18) :
you don't like xml do you ?

I don't like rebuilding a huge program like make since we are very short in man power.

Lionel Debroux (./19) :
While pretty much all (GNU/)Linux distributions have `make`, it is not present under Windows, which is the vast majority of our user base...

And so ? We can bundle Make with gcc4ti