User forums > Using Code::Blocks

Why is codeblocks config outside codeblocks folder!

<< < (2/2)

ham:
hi, thx,

no data is written to my profiles anymore, so my settings are portable now.

but i wished this were the default behavior of cb, and controllable within cb.

new question: Can there be a relative path for the compiler?


--- Quote ---quoteWhat?!!!!

--- End quote ---

sorry for my bad english, its not my native language

EDIT: i could add a entry to the system PATH variable with *.bat skript, would cb understand this?

codeur:
You can set the toolchain path relative to the Codeblocks installation directory in [Settings]->[Compiler and Debugger], "Toolchain executables" tab:

For example if you use MinGW as your compiler in subdirectory MinGW of your installation, set the toolchain path to
$(CODEBLOCKS)\MinGW

The portable setup (assuming only one user) cannot be the default CB setup because Code::Blocks is used on multi-user operating systems.
In many real-world situations several users may use the same workstation at different times and each will want to have a different setup and are working on different projects.

ham:
hi,

thx the compiler path is now also portable

Imho different setups can be saved in program folder too and dont need spamming my system.

h.a.n.d.

codeur:
Writing the user settings in a subdirectory of the user directory is a standard and recommended way of setting up any application on any multi-user operating system, unless you write everything to registry. It is not "spamming the system".

Freem:

--- Quote from: ham on August 26, 2011, 06:11:10 pm ---hi,

thx the compiler path is now also portable

Imho different setups can be saved in program folder too and dont need spamming my system.

h.a.n.d.


--- End quote ---

When I discovered this way of configuration (coming to xp from w98), I was thinking it is stupid, too. Now, I had to save and reinit OS's and softwares configuration many times (repairing friend's machines, by example) , and I understand the logic behind this. No more need to go in each program's binary directory to try to find (a part of) the config, in hope there is nothing elsewhere (regedit...), and searching which file is the configuration one (there are ini, inf, dat, or no extension, sometimes, and they are not necessarily configuration ones...).

The separation allow to use different partitions for each things too (the standard with linux).
The use of this, is that if a problem appear on a partition (XP not always make things you ask him to, and had often make some self-destruction on my side, or you can have a power problem, damaging the partition where a file was, the whole system if it is not partitioned correctly) you can always save the system, or a part of it, because softwares can rebuild their configuration (but you have to redo the configuration, but save the time needed to install them), or if you have configuration you can reinstall softwares. In all cases, you have a big time gain.
Making backup of configuration is easier, too. Just save a directory's files instead of the whole disk.
There is also the performance issue: different partitions means you can use different file systems, because configuration files are often small, but not software. You can also choose which data could be at beginning of hard disk, to make access faster.
With windows, it allow to reduce fragmentation, too.
Another point is that the user may not have rights to write in program files, but can be allowed to execute binaries there. But he always have rights on his own home.

But, as far as I know, ms windows don't make smart partitioning of the system by default, so many of those advantages don't appear on a default configuration (but it is possible to send "program files" , "docs&settings", "pagefile.sys" and "windows" directory on their own partition manually)

Navigation

[0] Message Index

[*] Previous page