Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

How are the project files of CodeBlocks itself are created?

<< < (2/2)

thomas:

--- Quote from: sodev on January 14, 2014, 04:40:53 pm ---Well, thats what i mean with handwritten, i don't expect anyone uses a text editor to write the xml code himself :D.
--- End quote ---
You misunderstood that statement. You're not supposed to presume that it's user-editable (or XML for that matter) at all.  :D

If you tamper with project files (or config files) yourself, you're out alone in the dark. No support, no guarantees.
Code::Blocks generates all non-source files in an unspecified way from its internal representation of data. It is guaranteed that Code::Blocks can also read any such file (including the previous one or two versions), but nothing else. It is not guaranteed that you are able to read it, or even modify.

Incidentially the files generated by Code::Blocks are (99.9% valid) XML files at the present time, because it's both convenient for us, and because it works fine with svn/diff as a bonus. You are likely able to edit most of it with a script or even an editor, but not everything that's valid XML will necessarily pass. There exists no documentation and no DTD, and we are probably not even able to tell what exactly you can and can't modify.


--- Quote from: sodev on January 14, 2014, 04:40:53 pm ---PreMake
--- End quote ---
Yes yes, except it's not what we use, and except it sucks :)

I'm not saying that our build process is the best thing, but it works (and what's important, it works automatically with one click, without needing to configure or patch anything).

People keep telling me how great CMAKE and automake are all the time. And every time someone (or I) use one of these, a more or less serious issue comes up (if nothing else, they're unnecessarily slow). Except of course if you use them under GNU/Linux. Yay for portability.

As for compiling with Visual Studio, I wouldn't be too optimistic. That might work, but it might turn out being a nightmare due to lacking language support, too. Sadly, it's not like you write C++ and it will compile with every compiler.

sodev:

--- Quote from: thomas on January 15, 2014, 01:13:33 pm ---If you tamper with project files (or config files) yourself, you're out alone in the dark. No support, no guarantees.

--- End quote ---
Yes i understand, no documentation, no warranty at all, thats what we tell our customers as well when they spot out config files and ask about them :).

But after switching our toolchain from gcc to msvc and upgrading the latter one multiple times i realized that generating project files for the used build system instead modifying them was better to maintain. I know the problems of these generators, too complicated, less powerful and the like, but i found a solution that works well enough for us. And we are also using bleeding edge svn snapshots of external libraries so i guess we are on the double no warranty path. We follow this approach since about two years and so far had only one or two major issues, so i can't complain.

thomas:
Well, we use TinyXML (the classic version, though we've been thinking once or twice about maybe switching to version 2 eventually, some day, maybe, who knows) to read and write these files. Output goes into a TiXmlPrinter, so we can get hold of the whole blob as a char* and flush it to disk in one operation.

So, as the first thing, you need to output something that TinyXML will not choke on (which probably 99% of all XML qualifies for).

For the more complicated stuff, config files are generated from one central "manager" class that sustains an in-memory tree-like database structure and serializes/unserializes at startup/shutdown the complete database using an undocumented but quite obvious and 100% consistent scheme. What's less obvious and consistent is how some components name the data within their "namespaces", but that is less of an issue (a namespace is basically a little sub-tree private to one component or plug-in). The whole config file (or config settings) infrastructure was planned and written once, and everybody uses the same public high-level API (which exposes key-value pairs in isolated sub-trees, not XML).

Now, for config files... things are... different. Project files have evolved over time, with features being added and changed. Whoever made a change made sure that the application is still working properly afterwards, but it isn't necessarily as consistent as a scheme, or anything similar in structure, or in code. You will have to dig through the source and find out what exactly is read and written in which way.  :-[

Navigation

[0] Message Index

[*] Previous page