Author Topic: Project build options confusion  (Read 5163 times)

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Project build options confusion
« on: July 18, 2006, 04:04:57 pm »
Hi,
in the "Project build options" dialog, you have a tree (in the left pane) that shows your project name as the root and your targets as leafs.
Each target has it's own options and this is right.
The project (root) has it's own options too, why? Who uses them?

Thanks,
Alessandro

sethjackson

  • Guest
Re: Project build options confusion
« Reply #1 on: July 18, 2006, 04:06:17 pm »
Hi,
in the "Project build options" dialog, you have a tree (in the left pane) that shows your project name as the root and your targets as leafs.
Each target has it's own options and this is right.
The project (root) has it's own options too, why? Who uses them?

Thanks,
Alessandro

Because you may want all targets to have a few similar options/link libs etc. Like -Wall for example. :)

I use this all the time. The CodeBlocks.cbp project uses it. I'm pretty sure others use this alot too. ;)
« Last Edit: July 18, 2006, 04:08:07 pm by sethjackson »

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Re: Project build options confusion
« Reply #2 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.

I think there should be a GUI representation of the gloabl status: you could use grayed check boxes for example.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9603
Re: Project build options confusion
« Reply #3 on: July 18, 2006, 04:48:44 pm »
The project (root) has it's own options too, why? Who uses them?
I for example use them. I've setup the warning levels to show on the project level and enable optimisation on the relase target and enable to include debugging options on the debug target.
...but you are right: to see the result would be nice. Currently you can achive this by showing the full compiler command line that is issued if you enable this option (see my sig how to do this). Maybe this can be done in another way, too (I think you have the visual studio dialog in mind...right?)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Re: Project build options confusion
« Reply #4 on: July 18, 2006, 05:07:51 pm »
The project (root) has it's own options too, why? Who uses them?
I for example use them.
Sorry, I didn't express my thought in the right way: I did not mean "what developer uses them", but "what part of C::B uses them"...

...but you are right: to see the result would be nice. Currently you can achive this by showing the full compiler command line that is issued if you enable this option (see my sig how to do this). Maybe this can be done in another way, too (I think you have the visual studio dialog in mind...right?)
Thanks for the full command line option, this is very useful!
(I still hadn't used the "Settings" menu ;-))
Yes, I'm thinking about the visual studio dialog. Not to copy always from others, but why reinvent the wheel every time? Moreover that way is more intuitive and less error-prone (at least I think so).
Anyway that is only an idea, if there are better ones, they are always welcome!

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Project build options confusion
« Reply #5 on: July 18, 2006, 05:11:55 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.

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

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Re: Project build options confusion
« Reply #6 on: July 18, 2006, 05:18:22 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.
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?

Anyway, the GLOBAL options are not so many (usually) :).
Yes, but they are distributed in 10 different TABS and sub-TABS... (just counted them ;-))

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Project build options confusion
« Reply #7 on: July 18, 2006, 05:26:13 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.
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?

Yes, it is a bit of work at the beginning. But until now it was not a source of troubles for me :).

Anyway, the GLOBAL options are not so many (usually) :).
Yes, but they are distributed in 10 different TABS and sub-TABS... (just counted them ;-))

Yes, but usually you do just enable one or may be 2-3 depending on your project.

Best wishes,
Michael

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9603
Re: Project build options confusion
« Reply #8 on: July 18, 2006, 05:43:17 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?
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.
« Last Edit: July 18, 2006, 06:19:35 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9603
Re: Project build options confusion
« Reply #9 on: July 18, 2006, 05:46:35 pm »
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.
« Last Edit: July 18, 2006, 05:48:29 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Re: Project build options confusion
« Reply #10 on: July 18, 2006, 06:12:29 pm »
Final considerations:
1)
Ok, I understand why you use global options and I agree that they are useful.
2)
I noticed now that there is a "Policy" combo that changes all the behaviour and gives the possibility to ignore global options (if I understand corretly what it does).
3)
If all setting are only for "adding" options and never "removing", then you can avoid the gray check box I was thinking before.

Now I have 2 new suggestions for the build options window, but may be better if I open a new topic.

sethjackson

  • Guest
Re: Project build options confusion
« Reply #11 on: July 19, 2006, 02:34:20 am »
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).
...

Heh I still use it that way. Most of my projects have only one target named "default". :)