Exporting compiler settings.

[pnpbios]

Hello Code::Blocks community. My name is Joel Longanecker, and I have been doing dreamcast development for a while now. I am to the point where I can comfortably setup the compiler to work properly, and handle projects and stuff. My primary goal in doing this was making it so that I can distribute it without everybody having to type the information in by hand each and every time.

The thrust of my post is this. What would be the best way for me to share my customized compiler settings?

Exporting the settings works, but when I go to import them, it just says that the feature isn't implimented yet. I am using 1.0 R2.

Does anybody have some ideas, or am I just going to have to write a plugin for this, or what?

[takeshimiya]

What kind of settings? If you made a template or project file, you could just share that. You can attach files here to the forum, or at the SourceForge tracker.

Whatever have you done to make everything works, would be better without "having to" export and import settings.
So, if you made a template, or introduced a new compiler, you can post here the steps you've done or what you've created in order to do that, and hopefully it can be integrated in the next version, or in a devpak.

[pnpbios]

http://www.dcemulation.com/phpBB/viewtopic.php?t=74733

This explains most of what I did. I could just copy all that over into the project level compiler settings, but it's cleaner to just have a compiler setup and ready to go.

As far as the dreamcast goes, my eventual goal is to have a standalone dev pack not dependant on having cygwin installed.
At some point in time, I would also like to be able to do this for the GBA, DS, XBOX, and other nonstandard systems.

[takeshimiya]

Ok, I've read your post there, and every step until "Projects->Save as User Template" can be done by you, and you only will need to distribute that template.

Now you may ask about the paths, well Code::Blocks 1.0RC2 support variables in the form $(varname), so you can create them in the Custom Variables tab of the Project Options.

Example:
$(KERNEL_PATH)=C:\cygwin\usr\local\dc\kos\kos\kernel\arch\dreamcast\kernel
Usage: $(KERNEL_PATH)\startup.o
will be expanded to
C:\cygwin\usr\local\dc\kos\kos\kernel\arch\dreamcast\kernel\startup.o

And then, you only tell your users to change the variable only.
And you must know, in the SVN HEAD version, Global Variables are supported, so it'll even ask your users the first time they'll open the project.


The compiler part will be more tricky, because you should copy/clone another compiler (like MinGW), and the you can call it "DC compiler".
The load/saving of settings will suffer a major change in the RC3 version (it doesn't use the registry anymore, now it's stored in xml), the changes are in SVN HEAD if you want to look.
But another way would be to recompile Code::Blocks with the support of that compiler, at least for now, because a major compiler revamping is planned for version 2.0 which would be a lot more flexible.

I can guess that if you can get a native (ie. non-cygwin) environment to build it, everything should become more easy.

EDIT: If you want to have a look at the SVN HEAD ver. you can try an unnoficial binary build here: http://paginas.terra.com.br/informatica/mauricio/codeblocks/

[pnpbios]

ok, so basicly, this is an issue with the maturity of the environment, rather than anything I can realy do about it. Well, I will start looking through the source for the SVN release when I get a chance.

[takeshimiya]

Only on the compiler part, because you can reduce the firsts steps of "do this and that blabla and then save as a template", and only distribute that template.

[killerbot]

do you mean the settings of the 'compilers' you added to CB ?

In the post RC2, that is SVN head, they are stored in the default.conf configuration file from the user, no longer in the registry. Then you could copy paste the parte of the compiler to another config file. Might be dangerous.
There is for the moment one big flaw in CB, user added compilers have id's 255 and above, internal registered compilers start from 0, that's ok. But in the projects all of them are referenced by a new number starting from 0, NOT th ID, so if your new compiler comes in at position 8 now, it is possible you get in conflict with an update of CB. Hoiw, well suppose CB has a new internal registerd compiler, that one will be then number 8.

For the moment this will not be fixed (dev's have other priorities), so you need to keep that in mind, that you might have to change all those stuff again. That is : MyComplier is now 9 instead of 8, and in the cbp files I have to adjust accordingly.

I am gone study that code of CB dealing with this part again some of these days, and see if I can find a solution for it, since this problem is preventing me to deploy CB with my collegues.


Cheers,
Lieven

[takeshimiya]

I think your solution is for now:

-Create a template using the global variables (new feature in SVN HEAD).
-Get the SVN source code, and add your new compiler settings as a new compiler, straight in the sourcecode.
-Compile yourself and distribute it with the template you created above.