Changing build options, should force a rebuild

[Game_Ender]

I think an interactive warning is the best way and you are still focusing on making it "smart".  If any option is changed in the project build options, doesn't matter what it is, just popup the window asking the user for a rebuild.  Now I realize it might not be very easy to track changes in the build options because the dialog most likely edits the config file's in memory representation directly thought the config manager.  So that might be the sticking point.

[thomas]

Preamble:
Due to lack of time I have only read about 30% of this massive thread. Excuse my ignorance


I tend to attribute a minimum amount of intelligence to every programmer. This includes the ability to read, the knowledge what changing a specific compiler switch does, and the ability to click on the "rebuild" button.

Many compiler options and project settings can indeed be changed without requiring the whole project to be recompiled. Certainly, on some occasions in the past, I wished Code::Blocks had automatically done a full rebuild, but this happened rarely. Well, so what, 15 seconds lost, hit rebuild "rebuild" manually, problem solved.
On the other hand side, I would be greatly annoyed if this happened without asking me all the time.

However, I would neither want to see yet another annoying message box. We already have so many darn stupid message boxes for so much bullshit, and they really tell you nothing.
While I generally agree that a low entry barrier for novice users is a good thing, this does not mean that you have to moronise the whole application.
Sometimes, I ask myself "what is this program, is it an IDE or what is it?". After all, programming is a scientific activity (or so say the computer scientists... . You can certainly expect from someone using an IDE to either have or acquire the necessary skills and knowledge.

There are at least as many situations in which an automatic full rebuild would be disadvantageous as there are situations where it would be right. You can always click on "full rebuild" if you are in doubt, nothing prevents you from doing so. However, if the IDE decides, then you do not have a choice.

What if you add an include path to a target? Should this rebuild all targets that depend on this target? Technically, this is mandatory as include files with the same name may conflict, but in almost every real case, it has no benefit and is only annoying.
This is only one example of how hard it is to get "smart" things right. More often than not, "smart" features are really stupid in everyday use.

Regarding the XCode argument, I don't deem see this much of an evidence. The mere fact that XCode does something in some way is in no way canon. Similar can be said about VS6.

[iw2nhl]

I tend to attribute a minimum amount of intelligence to every programmer. This includes the ability to read, the knowledge what changing a specific compiler switch does, and the ability to click on the "rebuild" button.

Sorry, but this is not so obvious.

Many compiler options and project settings can indeed be changed without requiring the whole project to be recompiled.

This never happened to me in years of programming. (Anyway may be it happens so often to you and other people)

However, I would neither want to see yet another annoying message box. We already have so many darn stupid message boxes for so much bullshit, and they really tell you nothing.

This is not the case: avoiding the user to link incompatible object files is not stupid or bullshit in my point of view.

While I generally agree that a low entry barrier for novice users is a good thing, this does not mean that you have to moronise the whole application.

Nothing prevents adding a checkbox in that dialog like "Never show this message again".

Sometimes, I ask myself "what is this program, is it an IDE or what is it?". After all, programming is a scientific activity (or so say the computer scientists... . You can certainly expect from someone using an IDE to either have or acquire the necessary skills and knowledge.

"acquire" means someone or something teaches you, and this message box would be there just for that purpose.

There are at least as many situations in which an automatic full rebuild would be disadvantageous as there are situations where it would be right. You can always click on "full rebuild" if you are in doubt, nothing prevents you from doing so. However, if the IDE decides, then you do not have a choice.

I know you didn't read all the topic, anyway this was already discussed, and the idea was to give the user a choice with a recommended choice.
So it is not the IDE to choose, but the user.

What if you add an include path to a target? Should this rebuild all targets that depend on this target? Technically, this is mandatory as include files with the same name may conflict, but in almost every real case, it has no benefit and is only annoying.

I think in "every real case" what happens is not what you expect, else there were no bugs in softwares.
You add an include and it seems to work, you work like that for days, then you make a rebuild and nothing works anymore... you spend days to find it was an error introduced by conflicting headers inserted days before: you where working with inconsistent files.

Regarding the XCode argument, I don't deem see this much of an evidence. The mere fact that XCode does something in some way is in no way canon. Similar can be said about VS6.

The idea about them was (at least for my post about VS6): they work well and that message was useful, why don't take that idea?
It is not a canon, else I would continue to use VS6, while I'm here because I think a lot of things are not good in that IDE and C::B could be better.

[thomas]

This is not the case: avoiding the user to link incompatible object files is not stupid or bullshit in my point of view.

I just imagine the situation. The IDE tells you "Hey, you should rebuild all sources", and next, it pops up the well known dialog "Are you really sure you want to rebuild all? This is very CPU-intensive". It would be even more funny if it happened right after the class wizard had been telling you "The class was successfully created"   :lol:

Nothing prevents adding a checkbox in that dialog like "Never show this message again".

Sure enough, but nothing prevents you from clicking the "full rebuild" button either whenever you are in doubt whether it *might* be needed.

I think in "every real case" what happens is not what you expect, else there were no bugs in softwares.

This has nothing to do with bugs in software. If you release software, one can expect that you don't pack the random crap that happens to be around somewhere into a zip file and ship it. You will do a full build anyway.
My point is about development cycles. Recompiling 2-3 files takes 15 seconds including link stage. If it works out for you, fine. If it breaks, well... fine. You haven't lost much, you can still do a full rebuild. On the other hand, unnecessarily compiling 800-1200 files (a typical "normal" project, not even a big one) takes several minutes. That's harsh if you could have done without.

[MortenMacFly]

One could also argue like this: My collegue will never check any checkbox of dialogs such as the "annoying dialog" or any "Tip of the day" to never show again. Thus this dialogs keep popping up for him again and again. In addition he'll never read but just click the default button. In fact I believe this behaviour is really common! Thus for such people they would always do a full re-build.

In addition: If a developer does'n't understand when a project needs to be re-build before shipping he deserves shipping crap. He'll then get back report from users complaining accordingly which he deserves, too. But then he'll start to think about what he actually does and will understand a build process.

This in fact is most important for serious software development. If you don't understand this you'll never do good software and then IMHO you shouldn't wonder if things don't work. And (again): If things don't work you start thinking which is a good thing (tm).

Presenting defaults to a user that he can just "click through" not always makes sense. Under certain circumstances it even supports leaving dummies to be dummies. Such software I don't want and I guess notbody really wants. In addition I don't want to use software from people that don't understand when to re-build a project and/or don't do a full re-build/testing before shipping software.

You see: This discussion is purely philosofic. Depending on your point of view some will argue pro and other will argue contra to your suggestion. What is right? I don't know but I feel not to have a "dummie help" is more useful in the end (for this specific case).

With regards, Morten.

[thomas]

In addition: If a developer does'n't understand when a project needs to be re-build before shipping he deserves shipping crap. He'll then get back report from users complaining accordingly which he deserves, too. But then he'll start to think about what he actually does and will understand a build process.

This in fact is most important for serious software development. If you don't understand this you'll never do good software and then IMHO you shouldn't wonder if things don't work. And (again): If things don't work you start thinking which is a good thing (tm).

Yes, Sir!

[kidmosey]

Many compiler options and project settings can indeed be changed without requiring the whole project to be recompiled.

This never happened to me in years of programming. (Anyway may be it happens so often to you and other people)

You've never forgotten to add a link library to a compile?  Or to add lib directories?  These certainly do not require a full rebuild.  Or perhaps you just switched the compiler to display all warnings (or even certain optimisations).  You may not want to rebuild after this.  Even in the case of custom settings, using a "-x 'c++''" switch most likely will not require a full recompile... and expecting the IDE to know such things is promoting developer ignorance.  There are already too many VB kiddies out there (no offense).

Sometimes, I ask myself "what is this program, is it an IDE or what is it?". After all, programming is a scientific activity (or so say the computer scientists... . You can certainly expect from someone using an IDE to either have or acquire the necessary skills and knowledge.

"acquire" means someone or something teaches you, and this message box would be there just for that purpose.

I'm not sure the IDE should be the educational instrument, considering most users will already have a lot of knowledge and constantly checking dialogs is quite a nuiscance.  Sure, you can gear it to make it easy to use for novice users, which IMO is what toolbars/tooltips do.  But how do you know where to stop if you turn it into an educational implement?  Will you bring up a dialog to let the user know compiling will overwrite the existing executable?  For the most part, the existing dialogs are there to prevent accidental clicks or keystrokes, not to educate the user.

[Ceniza]

Wow, you're really inspired today... I support your ideology

[iw2nhl]

I think in "every real case" what happens is not what you expect, else there were no bugs in softwares.

This has nothing to do with bugs in software. If you release software, one can expect that you don't pack the random crap that happens to be around somewhere into a zip file and ship it. You will do a full build anyway.

In addition I don't want to use software from people that don't understand when to re-build a project and/or don't do a full re-build/testing before shipping software.

I was not speaking about packaging, I was speaking about everyday compilation.

In addition: If a developer does'n't understand when a project needs to be re-build before shipping he deserves shipping crap.

You never forgot anything?

One could also argue like this: My collegue will never check any checkbox of dialogs such as the "annoying dialog" or any "Tip of the day" to never show again. Thus this dialogs keep popping up for him again and again. In addition he'll never read but just click the default button. In fact I believe this behaviour is really common! Thus for such people they would always do a full re-build.

And this is exactly what I wanted, who does not know or does not read, always recompile.
Who knows what is doing clicks the check box and this "annoying dialog" is gone forever.
Isn't this easy?

You see: This discussion is purely philosofic. Depending on your point of view some will argue pro and other will argue contra to your suggestion. What is right? I don't know but I feel not to have a "dummie help" is more useful in the end (for this specific case).

Yes, it's a question about point of views in the end...
I just wanted an option for newbies, nothing more, while you prefer support only experts. It is a choice, nothing is right and nothing is wrong!

[MortenMacFly]

I just wanted an option for newbies, nothing more, while you prefer support only experts. It is a choice, nothing is right and nothing is wrong!

Well it is possible. You could implement a new dialog class e.g. "NewbieDialog" or "EducationDialog" or however to will call it. It could follow the default "AnnoyingDialog" but should be off by default. Then you could add "educational messages" all over C::B. Most important: In contrast to the "AnnoyingDialog" they should be off by default and can be globally enabled by a command line switch and an option.

Then you could easily turn such messages on or off if you like. But I still think that the default value should be "off" for such messages. They are a good help for beginners (you could ask to enable this option during the installation to point beginners to it) but I guess the majority of the C::B user won't like it if such messages are enabled by default.

This is an Open Source project, so there is this option to look an the AnnoyingDialog, implement a "EducationDialog", add the configuration options and submit a patch. This shouldn't be too hard. And if this is done well I could imagine that this would make it into the core - why not?! But I for myself are not willing to implement this. If anybody else is - go on! There is nothing that could stop you.

Wih regards, Morten.

[Game_Ender]

So we are removing the full rebuild dialog right?  Or are we just using principle when its convenient?

[MortenMacFly]

So we are removing the full rebuild dialog right?  Or are we just using principle when its convenient?

There is a difference:If I change the compiler I know definetely that a re-build is required. But if I change compiler/linker options and stuff I don't.

So this question is issued because I might want to change other compilers too, before doing e.g. a workspace re-build instead of a project re-build.

Again: I'm not against this and it was offered that this could be implemented by somebody. But don't you think there are so many other issues that are really more important like that...

Edit: ...especially since this causes such a controversy discussion?

[iw2nhl]

We could post a poll...  :lol:

[sethjackson]

We could post a poll...  :lol:

 :lol: :lol: :lol:

I vote we poll to have a poll... Whatever.  :lol: :lol:

[Game_Ender]

Sorry I should of been more clear, I was speaking of dialog that warns of how long a rebuild would take.  It was supposed to be remark on the irony that its just as obvious a rebuild will take long as changing the compilier options requires a rebuild.  Yet we still warn the user about how long a full rebuild will take, yet fight tooth and nail to make sure we don't warn in the other circumstance.  Hence the comment about the not standing by the principle: "Obvious warningss that can be shown only once make the IDE less user friendly to its main user group:  Experienced software developers".

EDIT: I just think the featured should be allowed if someone makes implements it.  It just seemed Thomas thought it shouldn't be included at all.