Changing build options, should force a rebuild

[iw2nhl]

Hi,
I noticed that changing build options (Project -> Build options) and building (Build -> Build), the compiler says:
--------------
Target is up to date.
Nothing to be done.
--------------
But, in fact, it should recompile everything!
I tried to set some compiler and linker options and they are not applied until I force a rebuild (Build -> Rebuild).
Can this considered a bug?

Moreover, if I change something in a file and I select different compile options, only the changed file is compiled with new options and then it is linked with other files that where compiled with different options?
Isn't this dangerous?
May be there are different ways of passing arguments to functions because of different options and this should cause a crash.

May be also that I'm wrong!

[tiwag]

i think you are right

[sethjackson]

Yea I think you are right too.

[MortenMacFly]

Can this considered a bug?

I don't think so. You are changing global settings for your project and expect that C::B shall know to re-build. Well for this C::B should be able to really know (!) what compiler option(s) require a re-build, or only re-link etc. Think about you change the directory for includes. for this C::B should be able to know what header files your project includes, if they have changed do a re-build. This way you can find many things C::B should check to see if a re-build is required or not. But why let C::B do this calculation? This is definetely error-prone. If you as developer know you've changed compiler options you also know if you have to do a re-build or not. Thus if you just press "build" IMHO you are doing wrong.
Also think about that C::B supports a wide range of compilers. Are you really willing to implement for each compiler what switches require a re-link / re-build or change nothing? If a new compiler version comes out you have to reconsider everything.
IMHO a IDE shall be clever but not too clever. To fulfil such cleverness you are expecting here cannot be implemented on a safe basis. Thus it isn't.

With regards, Morten.

BTW: If you ahve ever worked with Makefiles: If you change the CFLAG inside the makefile does this re-build your sources? Is this a bug in Make? ;-)

[iw2nhl]

I don't think so. You are changing global settings for your project and expect that C::B shall know to re-build. Well for this C::B should be able to really know (!) what compiler option(s) require a re-build, or only re-link etc. Think about you change the directory for includes. for this C::B should be able to know what header files your project includes, if they have changed do a re-build.

I know this problem, but there is a very simple solution: if something has been changed in the compiler options since last build, mark all files as dirty (and this can be done in several ways). So you are forced to recompile everything. You can also show a messagebox informing the developer of the forced full-rebuild when "rebuild" is clicked (if there are pending changes).
This is what is done by other IDEs (e.g.: VS6).

BTW: If you ahve ever worked with Makefiles: If you change the CFLAG inside the makefile does this re-build your sources? Is this a bug in Make? ;-)

Yes, for my point of view this is a bug.
The same for .h files: if you change only .h files (I if remember well), nothing is recompiled and for me this is a bug of the make tool.

Best regards,
Alessandro

[Game_Ender]

I disagree MortenMacFly.  I use Xcode on a daily basis and if you change any options that would in effect change the compiler command line generated your entire project is rebuilt.  That is how it should be because if you don't you will get all sorts of strange errors and it will probably take you a little while to track them down.  So this is all ready done in an a widely used industry IDE so its not out of the question.

You argument about it being the developer responsibility is weak.  The IDE exist to remove developer responsibility and make it easier to develop.  After all, why use an IDE or dependency system at all.  The developer knows when changes to a file and therefore he just build the ones that depend on it, shouldn't he?  Yet CB does because it is error prone and easy to get wrong if you do it by hand.

Your are correct that an ideal implementation would be difficult, so don't use the ideal one.  You use a more broad approach.  I think a good way to implement this feature would be through another "Annoying Dialog" which would say:

"You have changed the build options of you project.  If you compile some files with these options and try to link object files compiled with the previous there is a likelihood of strange linker and program errors.  Would you like to do a full rebuild now?".

This would be triggered every time you change a build option to your project.  For even better control it should rebuild the entire project if you change a project or compiler option, but only a target if you change a targets options.  That would be pretty easy to do.

BTW: Aren't we trying to be better than make?

EDIT: lw2nhl- you can generate dependicies in make to make sure it rebuilds when you change header files.  Its not easy but it can be done and can be automated.

[MortenMacFly]

I know this problem, but there is a very simple solution:

Again: I don't think so. Let me give you an example: If I turn off a compiler warning level, why should all files be marked as dirty then? And in fact that time I dont want to do a re-build!

This is what is done by other IDEs (e.g.: VS6).

I'm using VS6. Of course this can be done here (btw: limited!). But this applies to only one compiler and is neighter backward nor forward compatible. C::B supports more than one compiler.

Yes, for my point of view this is a bug.

Well, I'd say for many people (including me) it isn't Who is right?

Again: You know for sure when you have to do a re-build. So why don't you press re-build? This I don't get...?!

With regards, Morten.

[MortenMacFly]

I use Xcode [...]

Does Xcode support more than one compiler?

I use the QNX plugin for Eclipse to develop a real-time application. There it is the same and this drives me crazy: If I setup the project dependencies as they should be, nearly always there is done a full re-build. A re-build means in my case: Compile about 400 source code files distributed over several libs. I believe this is a serious bug in the dependeny sytem but it does't get fixed.

In the end: I agree that this is possible. But I believe that this is going to be really complex and error-prone. Whoever maintains this has a full-time job. Think about that (s)he has to know all compilers C::B supports and will support in the future. And that's not all (s)he should also know all compiler versions C::B can be used with.

I could imagine that this can be done on a plugin-basis. After a quick check I think all required functions are exported. So if someone has the time to give it a try - feel free! And if you have a simple solution to this problem - step forward. But again: Keep in mind the example with the compiler warning levels being changed. I never-ever will have to do a re-build if I change such an option and don't press re-build.

With regards, Morten.

[Game_Ender]

You aren't listening or I am not being clear.  Don't try and do any magic at all!  Just ask the user if they want a full rebuild after they change the build options and make it an annoying dialog.  After all CB does currently warn that a full rebuild takes a long time, which is basically a bigger "duh" for a developer than this current issue.

[MortenMacFly]

Just ask the user if they want a full rebuild after they change the build options [...]

What build options? If I change the global compiler options a full re-build of all projects in the workspace (and future workspaces I open later) should be performed. Thus if I open another workspace after having changed this I should also be asked like that.

If I change the project's compiler options all targets of this very project should be re-build. But: Imagine I have overridden compiler options in the target that will lead to the fact that a target does't have to be re-build because it's (local) options haven't changed at all. Thus to make it a help for the developer such dependencies should be considered. Otherwise I still have to think for myself if to re-build or not.

With regards, Morten.

[iw2nhl]

Again: I don't think so. Let me give you an example: If I turn off a compiler warning level, why should all files be marked as dirty then? And in fact that time I dont want to do a re-build!

If I increase warning level is because I want to see if there are other errors in the code and I do this after everything else compiles rightly. So yes, I DO a re-build after changing warning level (at least most of the times).

I'm using VS6. Of course this can be done here (btw: limited!). But this applies to only one compiler and is neighter backward nor forward compatible. C::B supports more than one compiler.

Sorry, but I don't understand what you mean here. Why is this "neighter backward nor forward compatible"?
VS6 just warning you that you SHOULD recompile everything and you can do it or not (depending on what button you click in the dialog shown).

Yes, for my point of view this is a bug.

Well, I'd say for many people (including me) it isn't Who is right?

Sorry but still I can't understand!
Why, if I change the compiler optimizations flags, the project should not be rebuilt?
Why you changed them then?

Again: You know for sure when you have to do a re-build. So why don't you press re-build? This I don't get...?!

Yes, and I can use Notepad to develop too ;-).

[EDIT]
Moreover consider that not everyone knows when he has to rebuild all. A lot of people trust what IDE is doing and if they click "build" and no errors are shown, a "not expert" could think that his changes have been applied.

[MortenMacFly]

The same for .h files: if you change only .h files (I if remember well), nothing is recompiled [...]

C::B should support this. But I cannot reproduce tis issue: I've created a simple project that includes an enumeration via a header file. If I only change the header file (e.g. add another enumeration member) C::B re-builds all object files that depend on that header file just fine.

Could you give an example where this doesn't work? Because in fact this would be a bug.

With regards, Morten.

[MortenMacFly]

Why, if I change the compiler optimizations flags, the project should not be rebuilt?

The project shall be re-build but only if I issue a re-build. You have two buttons there: Build and Re-Build. They do what they say and they compute their functionality upon the files that have changed (binary, sources). All I'm saying is that for a change in the compiler settings it can't be easily obtained if really a re-build is required, or not. So when I start bugging the user with "you better re-build" the option if (s)he chooses to re-build or not still depends on the knowledge of the user. This knowledge (s)he does have (or not) could directly lead to press the right button.

Anyway: As a help how would it be to have a message like "If you change the compiler options you should consider a re-build of you project(s)" on the pages where you setup compiler options. Would this help? This would be nearly zero code change and warn the user in a non-interactive way and will be "compatible" too all compilers.

[iw2nhl]

The same for .h files: if you change only .h files (I if remember well), nothing is recompiled [...]

C::B should support this. But I cannot reproduce tis issue: I've created a simple project that includes an enumeration via a header file. If I only change the header file (e.g. add another enumeration member) C::B re-builds all object files that depend on that header file just fine.

Could you give an example where this doesn't work? Because in fact this would be a bug.

With regards, Morten.

Sorry if it was not clear, I was speaking about "make", not C::B!
I meant this was a bug of the "make" program :-)

[iw2nhl]

So when I start bugging the user with "you better re-build" the option if (s)he chooses to re-build or not still depends on the knowledge of the user. This knowledge (s)he does have (or not) could directly lead to press the right button.

Yes, and for this you guide the user saying him that the recommended choice is to recompile!
You help him, but letting him the choice.
I think this is the better way to help new developers and not limit experienced ones!

Anyway: As a help how would it be to have a message like "If you change the compiler options you should consider a re-build of you project(s)" on the pages where you setup compiler options. Would this help? This would be nearly zero code change and warn the user in a non-interactive way and will be "compatible" too all compilers.

No, I don't think so. I wrote a lot of programs and one of the main thing I learned is that "people does not read". Someone do it if he is forced (read this as a dialog with at least 2 buttons ;-)). But most of them does not read in that case too :-(. For this you need the recommended choice, which will be clicked by most users, solving them a lot of troubles (and removing a lot of messages of false-bugs in this forum too :lol:).

[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.

[thomas]

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.

It just seemed that Thomas would remove that other annoying messagebox too, along with a dozen others.
But the world is not a perfect place, we have to live with compromises, we can't have everything the way we want it.
While for me, there are far too many dialog boxes that annoy the hell out of me (things like "the file was created successfully" or "do you really want to rebuild?" make me say "yeah, what else, that's just what I asked for!"), I do see that a novice user might need one or the other of them (maybe).

It is because of this why I wrote both AnnoyingDialog and InfoWindow, to stop the IDE from hampering your work while still being able to display some chatter that is either unobstrusively placed int the bottom right corner or can be turned off. The problem with turning off messages is that you have to do it over again for every new installation (or profile), which quickly gets almost as annoying as the original thing...

Think of the typical installer app (the kind of installer that 100,000 programs use) as a negative example of what I am talking about:
You start the installer and it tells you "this will install program xxx, click OK to continue". As if you did not know, what did you start the installer for? Then, you are shown a license that no sane person can understand and you are asked if you accept that license (which you really cannot because it is 20 pages in fine print, and 18 of these pages are unintellegible to anyone not having a degree in law). If you don't accept the license, you are asked whether you really want to quit the installer. Why "really"? That's not what you said. You never said you wanted to quit.
If you accept the license, it asks you 3 or 4 things, one thing per page, as if you were unable to memorise more than 15 words at a time. If you click on "Cancel" it gives out a massive warning that this will terminate the installer (as if this was a major catastrophe). And finally, as the very last thing, it opens the Readme which you do not want to read.

If the user is not an outright retard (which you should assume for a programmer!), then I think the program should not treat him that way.


I generally think that not everything must be configurable, not everything must be automatic, a program does not need to tell you everything over and over again, and not every additional feature is a good feature. Many choices are bad choices. Most automatisms are bad (the more "smart", the worse).

And while my attitude towards new features is generally cautious (to avoid saying "negative"), history has proven me right a few times. Many feature requests (particularly the ones from two specific users) that were implemented against my objection in the past have caused quite a few problems that were not foreseen and have cost many weeks of development time (and user time).

People complain that RC3 is delayed and delayed, we are being compared to "Duke Nukem Forever", and we're being told that features should not be added to a RC, but at the same time, new features are asked for every day.

I am not saying that I know everything or that I am unfailable as the Pope does.
However, I am positive about two things: more message boxes with yet more choices do not make the application better, and neither does making one more thing that you might not want automatic.

[kidmosey]

...
However, I am positive about two things: more message boxes with yet more choices do not make the application better, and neither does making one more thing that you might not want automatic.

And 34 different ways to open/create a new file does not make an IDE easier to use, especially for novices.

And I can't help but applaud you for everything you've said.  But, then, I'm the type who despises people who create web pages with frontpage when I made my entire site with notepad.  I'm all for new developers, but depending on software to hold your hand is a horrible way to learn and will only lead to lazy/poor results.

[thomas]

Lol, I forgot to mention the MS office assistant in my rant. Clippy, Minky, Professor, whatever they're called...  :lol: :lol: :lol:

[mdelfede]

Lol, I forgot to mention the MS office assistant .........

Beurrrk !
First time I used office it took me 1 hour to get rid of assistant !
Without speaking about automatic bullets (one morning to disable them), spell check (I disabled it and it continues to put capital letters everywhere, in particular on 'i', even if in Italian the 'i' doesn't mean 'first person singular'....

I agree, too much 'automatics' doesn't make a better program.
I used for some time Borland tools, and they'll do it good, not too much, not missing too much. Of course, it was easier for them, supporting only one compiler...

Of course it would be possible to parse the compiler options for each compiler, to detect when a rebuild is needed, but it would be a huge job, working with many compilers. Even doing it, on future compiler version there would be many options not parsed by the program, which would lead to bad behaviours.
Of course, having a person that could spend all time on it would be great  :mrgreen:

One nice thing that could indeed be added with no much effort would be a new option with 'message verbosity', let's say
'expert', 'normal', 'beginner' and 'dummy like a hun', on wich the messageboxes would depend.
So, if you don't want to be bothered at all you can choose 'expert' mode, if you want a messagebox that remembers you that you must eat twice a day you select 'dummy like a hun' .

Ciao

Max

[MortenMacFly]

One nice thing that could indeed be added with no much effort would be a new option with 'message verbosity', let's say
'expert', 'normal', 'beginner' and 'dummy like a hun', on wich the messageboxes would depend.

Hehe... I thought the same. Because I for myself have disabled all TipOfTheDay and AnnoyingDialogs after they appeared the first time. For me a global setting "Expert mode" that does not even offer me such things the first time would have been great!

In fact I am developing a modelling software that follows this concept: There are 3 user levels: Expert, "Default" and Beginner. Depending on what level you set the modelling tool adjusts parameters automatically to a "good" default value. This is accepted and used intensively by the users that use "my" modelling tool.

[iw2nhl]

I agree with some ideas of thomas, but only some ;-)!

While for me, there are far too many dialog boxes that annoy the hell out of me (things like "the file was created successfully" or "do you really want to rebuild?" make me say "yeah, what else, that's just what I asked for!"), I do see that a novice user might need one or the other of them (maybe).

Yes, there are too many dialog boxes and the worst one is about clean/rebuild: for both of them it remebers you that that operation will require a lot of time if the application is big.
Is this message really needed? This is what I think is well known by any developer: building requires time.
While other dialogs may be useful: if I ask to create something, I want to know if it was created or not because of errors. Generally, if no message is shown, you do not know if it is because everything was right or because of a bug in the system or a silent error.

Think of the typical installer app (the kind of installer that 100,000 programs use) as a negative example of what I am talking about:

Yes, I partially agree: that way of installing is not very good, but always better than a compile required by a lot of applications for Linux (worst than this, when the application requires libraries to be compiled too).

People complain that RC3 is delayed and delayed, we are being compared to "Duke Nukem Forever", and we're being told that features should not be added to a RC, but at the same time, new features are asked for every day.

About the version I have an idea: why just don't skip the 1.0 version and release something like a 1.5 version?
I say this because we are NOT working on an RC (release candidate): it has changed in GUI, menus, frameworks, plugins and much core code. It has nothing to do with the old 1.0 version.
New code means new version.
You cannot still call the new release: 1.0 version. Give it a new name, please!

[mdelfede]

Reading the topic about compiler framework redesign, made with xml files, one for each compiler, I was thinking that it should be possible to put 1 field in xml file for each compiler version telling which options should force a rebuild when changed.
Then, another file should be generated on each build, saving (maybe also in xml...) the options used on last build.
On next build that file could be scanned, compared with 'force build on change' flags in compiler framework xml file and a forced rebuild could be done automatically.
Of course, the rebuild could be done on 'per file basis' when only local options changed, or 'per target basis' when a global option changed.
It would also be possible to put 3 kind of options :
1 - rebuild not needed (for example, for warning levels, ecc...)
2 - rebuild suggested (for example, change in optimizations), which could lead to a box asking for it
3 - rebuild mandatory, which could lead to an automatic forced rebuild.

Having that in xml compiler files, it could be easy mantained and extended with new future compilers and options.

Ciao

Max