How are the project files of CodeBlocks itself are created?

[sodev]

I'd like to know how the project files of CodeBlocks that you use to build CodeBlocks itself are created. I can't find any generator scripts in the source tree and there are quite a lot of project files present.

I ask because i want to build CodeBlocks against the latest wxWidgets SVN snapshot and they changed the version number to 3.1 and EVERY CodeBlocks project file defines the wxWidgets version number as local variable so i need to change a lot of files to change that. Also the latest wxWidgets Makefiles decorate the library output folders with the compiler version (if build using official build mode) so i need to adjust that as well.

Currently it looks like i need to do some mass search-and-replace over all the project files but i would prefer to just change some numbers in a generator script and just regenerate the project files .

My second question is, has anyone tried to compile CodeBlocks with Visual Studio (preferrably 2013), does it work? Because i'd love to get rid of my GCC toolchain on windows .

[MortenMacFly]

Currently it looks like i need to do some mass search-and-replace over all the project files but i would prefer to just change some numbers in a generator script and just regenerate the project files .

Lucky you, I am currently pimping the ProjectOptiopnsManipulator plugin so that you can do so. It requires a compilation of this plugin by you, or you'll have to wait until the next nightly.

My second question is, has anyone tried to compile CodeBlocks with Visual Studio (preferrably 2013), does it work? Because i'd love to get rid of my GCC toolchain on windows .

There was a post recently from a user that was able to do so.

[sodev]

Well, i take it the project files are handwritten .

I'm always using the SVN snapshots so thats not a problem, however i don't know how your plugin can help in my case, i can add options, remove options, but not change (parts of) options, so i ran a search-and-replace over the files, that fixed it for me.

Compiling with Visual Studio seems to be more work than just changing the project files, i gave up when i had the usual problem that enabling unicode changed the generic WinApi methods to the wide char versions but the code still passed in narrow chars and that POSIX functions are preceeded with an underscore .

[stahta01]

Well, i take it the project files are handwritten .

No, the project files are created by Code::Blocks.

It is strongly suggested to never edit the CB config or CB Projects with a text editor.

But, I do from time to time edit the patch files created to update CB Projects by hand to minimize the unneeded changes for what ever patch I submit.

Tim S.

[sodev]

Well, thats what i mean with handwritten, i don't expect anyone uses a text editor to write the xml code himself .

The opposite that i am acutally using in my projects is that the project files get generated, i am using a modified PreMake version that is able to create CodeBlocks project files that use Visual Studio as compiler, a simple premake --target cb-vs11 and you get fresh new project files. There should be really support added for the 2012 and 2013 versions, but sadly the XML is not poweful enough to detect all the fancy SDK's but even with a compiled plugin its not easy to detect all the possible combinations like x32 or x64, Windows XP compatible SDK or not. However compiler option wise it is no big deal, you only need to specify /FS for parallel build with the 2013 version, otherwise all the 2010 switches are enough to get rolling the newer versions.

Want to compile with gcc? Just call premake --target cb-gcc? Need to change the library path of wxWidgets? Change 2 lines in the wxWidgets script and start PreMake again .

[thomas]

Well, thats what i mean with handwritten, i don't expect anyone uses a text editor to write the xml code himself .

You misunderstood that statement. You're not supposed to presume that it's user-editable (or XML for that matter) at all.  

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.

PreMake

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]

If you tamper with project files (or config files) yourself, you're out alone in the dark. No support, no guarantees.

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.