This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Please tell me if this is expected behavior for CCS4.1 when building a project.
It appears that when you go to change the build properties for an individual source file, a snapshot is taken of all the build properties and then it stays that way. Is this the correct and expected behavior?
This will be very inconvenient if I want to have several files with different build options than the project as a whole. If I want to make some global changes for all files, the separate ones will have to be updated manually, if I am understanding this correctly.
Please advise. This was not the behavior that I recall from CCS 3.x, so is this an Eclipse-effect or an intentional feature change?
Regards,
RandyP
Randy,
What you are describing is what i would expect. I would not expect CCS to change the file-specific options I set if I tinker around in the project level options.
ki
Ki,
Wouldn't you expect CCS to maintain project level options that I do not specifically set at the file-specific level? This is my case. I, too, would not expect CCS to change the file-specific options I set, but I would expect it to propagate project-level changes that were not changed at the file-level.
The predefined symbol in #2 was changed at the project level, then I set one file-specific option -O3 in #3, then I change the project-level predefined symbol at the project level in #5. But that change, never touched at the file-level, did not update the parameters used for that file. I expect that if I added a new predefined symbol at the project level, then it would not get applied to my xyz.c file, either.
In other words, CCS does not keep track of just what changes you make at the file level. Instead, CCS blocks future project-level changes from migrating to the file level. Another example that I predeict would be blocked would be adding an include path at the project level; this would most likely not get carried to the file-specific level for any files that you have modified one or more options.
You can click Restore Defaults at the file level to remove all the intended file-specific changes and then pickup all the project-level ones again. But that then requires re-applying any file-specific options that you do want to maintain.
Randy
RandyP said:In other words, CCS does not keep track of just what changes you make at the file level. Instead, CCS blocks future project-level changes from migrating to the file level.
This is not quite true. CCS does not block all changes made at the project level from propagating down to files with file specific options set. For example, if you have a file with a file specific option where you added a predefined symbol, and then go to the project level options and change the optimization level from 3 to 2, that optimization level change will propagate down to that file with the file specific option set.
However, it appears that if I then go to the project level options and add a predefined symbol, that change does NOT get propagated down to the file with the file specific option (it does not add that new symbol). So it will block changes only for the specific options that were set (in this case it is any changes to the -D option).
RandyP said:Another example that I predeict would be blocked would be adding an include path at the project level; this would most likely not get carried to the file-specific level for any files that you have modified one or more options.
This would only be true if the option modified in the file specific option is the include path. If it was not touched as a file specific option, then adding a project level include path will indeed be carried to the file with the file specific options.
I currently see this behavior. Do you not see this?
Ki-Soo Lee said:it will block changes only for the specific options that were set (in this case it is any changes to the -D option).
At the file level, I never changed anything in the -D options. This was only done at the project level. There was one time when I saw that the predefined symbol had not changed correctly at the file level, and only then did I change it at the file level, but since then I have cleared everything out with Restore Defaults and have never tried to change the -D at the file level.
My scenario is not what you are describing, but is the reverse (-D at the project level, then -O3 at the file level, then change -D at the project level, -D blocked at the file level). And the effects are not what you describe, either. Can you confirm if you follow my numbered steps that you do not see the same behavior that I see, please?
Ki-Soo Lee said:adding a project level include path will indeed be carried to the file with the file specific options.I currently see this behavior. Do you not see this?
I should not have made the prediction without confirming it. My apologies for such rash talk.
I was able to reproduce your use case. It is strange, sometimes options get passed down and sometimes it does not. At the very least, it is strangely inconsistent and can cause confusion. I will file a CQ for this
Thanks
ki