I found the bug in uVision v5 1. add a segment of code #ifdef XYZ ... #endif
2. make sure there is no preprocessor symbol XYZ 3. save all and rebuild 4. check code size 5. edit preprocessor symbol, add XYZ 6. click BUILD (F7) -> keil figured out that you changed compile options and it's doing what looks like a rebuild and not only build of changed files (showing that it's compiling all c files in project) 7. check code size, it's same as without symbol, the whole block of txt between ifdef XYZ and endif is NOT compiled?!?! - BUG 8. click REBUILD -> the code is now built, the codesize increased
so the rebuild done from build in step6 does not properly work, it's a serious bug :(
Do you have any understanding how the tools operste?
Ha ha. Make has the same serious bug!
understanding how they *should* operate - yes understanding how keil itself operate - no, not the clue
1. when you do "rebuild" it should do clean/make, build all objects and link them 2. when you do "make" it should - in case "project files" are changed, do a rebuild - in other cases build only objects that depend on changed source files, and link everything
What keil does in case project files are changed and make started - it "shows" it's compiling *all* files, like it's doing a rebuild BUT it is actually NOT recompiling them ?!?!?
this makes ZERO sense
There are tools that ignore changes in the project settings and on "make" it will only recompile changed files and their dependencies. In that case you see that only "few" or "none" are compiled so you remember to do a "rebuild", but in case where Keil shows that it's compiling the whole project from scratch - and it's actually not... it's a bug IMO.
Nope, make would ignore the "Makefile" itself and when you do make it will not show you that it's recompiling the whole project while actually not doing it!
The only bug is in your knowledge and sight. Look at what really happens and you might learn.
You've informed keil support about it?
@K Ponteypool very insightful comment, I'm really happy I can learn from you.. to bad not everyone is as helpful as you are
output from "build" (That does nothing in reality)
*** Using Compiler 'V5.06 update 5 (build 528)', folder: 'e:\Keil_v5\ARM\ARMCC\Bin' Build target 'kupola' compiling stm32f4xx_hal_flash_ex.c... compiling stm32f4xx_hal_pwr.c... compiling stm32f4xx_hal_flash.c... compiling stm32f4xx_hal_flash_ramfunc.c... compiling stm32f4xx_hal_spi.c... compiling stm32f4xx_hal_dma.c... compiling stm32f4xx_hal_rcc_ex.c... compiling stm32f4xx_hal_pwr_ex.c... compiling stm32f4xx_hal_tim_ex.c... compiling stm32f4xx_hal_tim.c... compiling stm32f4xx_hal_cortex.c... compiling stm32f4xx_hal.c... compiling stm32f4xx_hal_rcc.c... compiling stm32f4xx_hal_uart.c... compiling stm32f4xx_hal_gpio.c... compiling system_stm32f4xx.c... compiling stm32f4xx_it.c... compiling usart.c... compiling gpio.c... compiling stm32f4xx_hal_msp.c... compiling stm32f4xx_hal_dma_ex.c... compiling spi.c... linking... Program Size: Code=6098 RO-data=450 RW-data=12 ZI-data=1308 "kupola\kupola.axf" - 0 Error(s), 0 Warning(s). Build Time Elapsed: 00:00:17
output from "rebuild" (that actually rebuilds)
*** Using Compiler 'V5.06 update 5 (build 528)', folder: 'e:\Keil_v5\ARM\ARMCC\Bin' Rebuild target 'kupola' compiling stm32f4xx_hal_dma.c... compiling stm32f4xx_hal_pwr.c... compiling stm32f4xx_hal_flash_ex.c... compiling stm32f4xx_hal_flash.c... compiling stm32f4xx_hal_spi.c... compiling stm32f4xx_hal_flash_ramfunc.c... compiling stm32f4xx_hal_rcc_ex.c... compiling stm32f4xx_hal_cortex.c... compiling stm32f4xx_hal_tim_ex.c... compiling stm32f4xx_hal_uart.c... compiling stm32f4xx_hal_rcc.c... assembling startup_stm32f407xx.s... compiling stm32f4xx_hal_pwr_ex.c... compiling stm32f4xx_hal.c... compiling stm32f4xx_hal_tim.c... compiling stm32f4xx_it.c... compiling main.c... compiling stm32f4xx_hal_dma_ex.c... compiling gpio.c... compiling stm32f4xx_hal_msp.c... compiling system_stm32f4xx.c... compiling stm32f4xx_hal_gpio.c... compiling spi.c... compiling usart.c... linking... Program Size: Code=9404 RO-data=448 RW-data=12 ZI-data=1308 "kupola\kupola.axf" - 0 Error(s), 0 Warning(s). Build Time Elapsed: 00:00:17
Build don't compile "all" files, just whole bunch of them (do not compile main.c where the issue is so that is why the change is not applied) but why on build it recompiles all these files?! They are not changed, only change is in the project options. None of those files are changed?!
If I change the main.c only and push build I get as expected:
*** Using Compiler 'V5.06 update 5 (build 528)', folder: 'e:\Keil_v5\ARM\ARMCC\Bin' Build target 'kupola' compiling main.c... linking... Program Size: Code=9404 RO-data=448 RW-data=12 ZI-data=1308 "kupola\kupola.axf" - 0 Error(s), 0 Warning(s). Build Time Elapsed: 00:00:02
dunno, I still think it's a bug. Nothing that I find serious as I'm used to doing clean/make (rebuild) when I change the properties but what Keil does here is misleading and imo a bug
6. click BUILD (F7) -> keil figured out that you changed compile options and it's doing what looks like a rebuild and not only build of changed files (showing that it's compiling all c files in project)
Doesn't look from your logs to be compiling *all* C file.
Pretty sure when I change compiler target, or change command line options, I want to be using "Rebuild all target files" so there is no ambiguity about what I expect to happen.
That sort of rebuild is required on the Linux kernel build, when making subtle changes, which doesn't use Keil at all.
Keil should perhaps do a better job of marking the entire project as tainted, but then we'd likely see more complaints about it taking longer to build with "minor" changes.
(do not compile main.c where the issue is so that is why the change is not applied)
I'll venture a guess: your problem is that "the change" is actually not applicable main.c at all, because you made that change in the settings of a source group of the project that most of the files of the project are in --- but main.c is not.
Doing something else than you actually intended to do will invariably lead to such misunderstandings between you and the tools.
@Westonsupermare Pier, yup not all, as I wrote "..looks like a rebuild..", obviously not a rebuild otherwise it would work as expected :)
also, yes, I tend to click rebuild whenever I change config (both proj and hardware.h and similar) but it's a trap as you can miss-click (easy done with high res screens if you go for a click instead of f7 on keyb) make and it "looks like a rebuild" as it starts to build bunch of files..
changes in project properties imo should mark the whole project tainted as really changing compiler preferences etc requires a full rebuild
@Hans-Bernhard Broeker, I'm *very* unexperienced with Keil (I'm gcc user and vi is my editor of choice and I work on development of system software, database servers, telco backends etc, this is just a hobby and I'm just trying out Keil, gui's like eclipse, visual studio, atmel studio, microchip mplab/mplab-x I havent used for many many years) so what you wrote hides some potentially interesting info, I'd appreciate if you can elaborate or point me to a documentation segment :D.. talking about "source group of the project that most of the files of the project are in --- but main.c is not.". What is a source group and how are they controlled from the project settings? Can they have different compiler options? This is a super basic app - 10 clicks trough stm32cubemx, open project, add 3 lines into main.c compile, edit properties, compile ... no "project settings" made by me nor edited by me.. Why is everything except startup_stm32f407xx.s and main.c part of that "group" that's marked "tainted" after project properties are changed? What group is that, how I change what's in it? Thanks in advance!!
I still believe this is a bug, not a "serious one" but definitely a bug
Nope. I don't agree with that. Just because you don't see it working the way it you think it should, does not make it a bug. It's more a decision made that you don't like.
I personally do a rebuild on a project change. Just to ease my paranoia, I also do a full rebuild immediately prior to a formal release and compare the final executable with what I had used during testing. Why assume an action when when you, the developer, can be certain?
> Nope. I don't agree with that. Just because you don't see it > working the way it you think it should, does not make it a bug. > It's more a decision made that you don't like.
You are 100% right, I have to admit :D
But I'm still wondering why it's compiling all those other files after project edit? Need to figure out what's going on there.. the "groups" mentioned before might be the key but my web search gets me nothing and quick browse trough documentation gave me nothing too :(
> I personally do a rebuild on a project change. Just to ease my paranoia, > I also do a full rebuild immediately prior to a formal release
Same thing I do :D
The whole thing here happened as a "friend who's learning C" had a problem that #ifdef with symbol from project property was not working for him. Something so simple and plain that was impossible to "not work", after not being able to explain him what to do (as it should work) I TV to his box and it was working for me (as I clicked rebuild of course) and then he figured out he was clicking "build" not "rebuild" but since on "build" Keil was compiling so many files after project was edited it was confusing... So, what Dave would of said "trap for young players".. and while it does not affect me I think it is confusing enough to warrant a bug status :)
But I'm still wondering why it's compiling all those other files after project edit?
Because it does exactly what you wanted it to, and what it should do: it noticed that you changed the settings effective for those files, so they have to be compiled next time.
My guess is that the surprise is rooted in the fact that, while you were intending to do a "project edit", i.e. a change of compiler settings for all source files, what you actually did was just a change for most files.
Let's have a look: open the project window. Expand the hierarchy. Note that below the master "Project" node, there are several sub-hierarchies ("Targets", "Source groups", "Components" and whatnot), which eventually contain (references to) the source files. Each of those nodes can have compiler settings, which then modify or override the settings inherited from the higher-up node. By default only the nearly top-most "Target" node contains settings, and all others pass them on unmodified --- the "taint" mark is there to warn you if that's no longer the case. But if you add a new switch to a node other than "Target", that will only affect the files below that node.
Thanks for sticking with me, I'm really trying to figure this one out once and for all :)
> Because it does exactly what you wanted it to, and what it should do: > it noticed that you changed the settings effective for those files, > so they have to be compiled next time.
> My guess is that the surprise is rooted in the fact that, while you > were intending to do a "project edit", i.e. a change of compiler > settings for all source files, what you actually did was just a > change for most files.
It is possible since I don't know that there are "groups of files" in Keil hence very possible I did something wrong. On the other hand, I have main.c open (only) and I'm clicking main menu - "project"/"options for target kupola" (kupola is name of the project and the only target available). The go to C/C++ tab and change preprocessor symbols/define, click OK and that's it. Not sure how can that be related to "only those files" :(
The "project structure" as made by cubemx, "Application/User" "directory" contains main.c, gpio.c, usart.c, spi.c, stm32F4xx_it.c, stm32f4cc_hal_msp.c files.. and when I click make after editing project it's compiling gpio.c, usart.c, spi.c and not main.c ? How is the gpio.c different from main.c - where to see that?
> Let's have a look: open the project window. Expand the hierarchy.
Like this (dunno how to link image to post, open url manually): pasteboard.co/GDvvq1r.png
> Note that below the master "Project" node, there are several > sub-hierarchies ("Targets", "Source groups", "Components" and whatnot), > which eventually contain (references to) the source files. > Each of those nodes can have compiler settings,
gpio.c, usart.c, spi.c and main.c are in the same group (as visible on the image)
The "kupola" node (target) is selected in the project window, I click on project/options for target kupola -> so options for the whole (and only) target.
click on build - it recompiles gpio.c usart.c and spi.c and does not recompiles main.c that is in the same group (Application/User) in the same target (kupola).
I don't get, still, what I'm doing wrong :(. It's super simple (freshly generated product skeleton), there's only one target..
thanks
btw I checked each group (right click, group properties) and it's blank, all settings are blank, only the top target have options..
I can upload project somewhere so you can check, it's empty project nothing to hide