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:).