User forums > Help
Project build options confusion
Michael:
--- Quote from: iw2nhl on July 18, 2006, 04:38:13 pm ---Ok, this is useful, but then the presentation is not clear: how I know if an option is gloabally active and not in the current target? Have I to remember all global settings in my brain?
Example:
GLOBAL enables -Wall
RELEASE disables -Wall
DEBUG enables -Wall
In RELEASE I read that -Wall is disabled, but in fact it is enabled because of the global setting.
--- End quote ---
Hello,
Then you should not enable -Wall in GLOBAL, but only in DEBUG :). In GLOBAL you should only enable the options valid for each target. I usually do so.
Anyway, the GLOBAL options are not so many (usually) :).
Best wishes,
Michael
iw2nhl:
--- Quote from: Michael on July 18, 2006, 05:11:55 pm ---Then you should not enable -Wall in GLOBAL, but only in DEBUG :). In GLOBAL you should only enable the options valid for each target. I usually do so.
--- End quote ---
Yes, but then if it was already active in GLOBAL (as it is by default) and I want to change settings in DEBUG, I have to remember to modify GLOBAL too and verify that there are no other targets affected by the GLOBAL change. Isn't this too much work for enabling an option?
--- Quote from: Michael on July 18, 2006, 05:11:55 pm ---Anyway, the GLOBAL options are not so many (usually) :).
--- End quote ---
Yes, but they are distributed in 10 different TABS and sub-TABS... (just counted them ;-))
Michael:
--- Quote from: iw2nhl on July 18, 2006, 05:18:22 pm ---
--- Quote from: Michael on July 18, 2006, 05:11:55 pm ---Then you should not enable -Wall in GLOBAL, but only in DEBUG :). In GLOBAL you should only enable the options valid for each target. I usually do so.
--- End quote ---
Yes, but then if it was already active in GLOBAL (as it is by default) and I want to change settings in DEBUG, I have to remember to modify GLOBAL too and verify that there are no other targets affected by the GLOBAL change. Isn't this too much work for enabling an option?
--- End quote ---
Yes, it is a bit of work at the beginning. But until now it was not a source of troubles for me :).
--- Quote from: iw2nhl on July 18, 2006, 05:18:22 pm ---
--- Quote from: Michael on July 18, 2006, 05:11:55 pm ---Anyway, the GLOBAL options are not so many (usually) :).
--- End quote ---
Yes, but they are distributed in 10 different TABS and sub-TABS... (just counted them ;-))
--- End quote ---
Yes, but usually you do just enable one or may be 2-3 depending on your project.
Best wishes,
Michael
MortenMacFly:
--- Quote from: iw2nhl on July 18, 2006, 05:18:22 pm ---Yes, but then if it was already active in GLOBAL (as it is by default) and I want to change settings in DEBUG, I have to remember to modify GLOBAL too and verify that there are no other targets affected by the GLOBAL change. Isn't this too much work for enabling an option?
--- End quote ---
I think we should go back one step here: In the "beginning" targets were not only meant for such purposes as debug and release. Targets were also meant as "library target" for another "application target" that uses this libary (it still is that way). In fact the C::B project is like that. Than consider you want to define e.g. wxUNICODE over all those targets. Of course here you do this one time in the project options and that's it. If you want to disable it for a specific target you issue another wxUNICODE=0 just for this target.
So there are cases where project options are really useful. Of course if you don't like them you don't have to use them. They are all disabled by default just as it would be if you operated on the "command line" - nothing is added. If you like you can setup the option on target level only. But then you have to setup several options (like defines) for every target. And if you want to change an option you have to do this for every target again.
I think basically you shouldn't just think of release/build target and compiler/linker options but also other possibilites C::B offer to you. You can also read http://wiki.codeblocks.org/index.php?title=The_build_process_of_Code::Blocks for a more detailed explanation.
With regards, Morten.
MortenMacFly:
BTW: I'm not sure if there is a misundertstanding: If an option is disabled this doesn't mean something like "-option=false" is issued to the command line. It really means nothing is issued to the command line. So all options you have to enable anyway if you want to use them - also if the option disables a functionality. Thus something like "-w" inhibits all warning messages but is an additional command-line option and thus has to be enabled. That's how compiler work in general (I'd say).
...just to make sure we get this straight.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version