Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Changing build options, should force a rebuild

<< < (4/8) > >>

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:

--- Quote from: thomas on July 18, 2006, 06:56:24 pm ---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.

--- End quote ---
Sorry, but this is not so obvious.


--- Quote from: thomas on July 18, 2006, 06:56:24 pm ---Many compiler options and project settings can indeed be changed without requiring the whole project to be recompiled.

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


--- Quote from: thomas on July 18, 2006, 06:56:24 pm ---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.

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


--- Quote from: thomas on July 18, 2006, 06:56:24 pm ---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.

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


--- Quote from: thomas on July 18, 2006, 06:56:24 pm ---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.

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


--- Quote from: thomas on July 18, 2006, 06:56:24 pm ---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.

--- End quote ---
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.


--- Quote from: thomas on July 18, 2006, 06:56:24 pm ---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.

--- End quote ---
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.


--- Quote from: thomas on July 18, 2006, 06:56:24 pm ---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.

--- End quote ---
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:

--- Quote ---This is not the case: avoiding the user to link incompatible object files is not stupid or bullshit in my point of view.
--- End quote ---
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:


--- Quote ---Nothing prevents adding a checkbox in that dialog like "Never show this message again".
--- End quote ---
Sure enough, but nothing prevents you from clicking the "full rebuild" button either whenever you are in doubt whether it *might* be needed.


--- Quote ---I think in "every real case" what happens is not what you expect, else there were no bugs in softwares.
--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page