Hi,
When building from the command line or another IDE is there a way to have uVision not rebuild the whole project.
As part of an automated build it is a good thing to do the complete rebuild but I have been looking at eclipse as an alternative IDE. This does work but the build takes a few minutes each time rather than just seconds when doing a build after a small change in uVision itself.
Currently I am using a simple .bat file
echo Starting Build.bat C:\Keil\UV4\uv4.exe -r EFM32_Main_MCU.uvproj -o buildOutput.txt type buildOutput.txt
Any suggestions?
Thanks Stephen
IDE-Version: µVision V4.23.00.0 Copyright (C) 2011 ARM Ltd and ARM Germany GmbH. All rights reserved.
License Information: Stephen Robertson Spacelabs Healthcare LIC=IK125-D0D23-RZKSN-W8V2U-79FIV-8CHFZ
Tool Version Numbers: Toolchain: MDK-ARM Standard: 4 user Version: 4.23 Toolchain Path: C:\Keil\ARM\BIN40 C Compiler: Armcc.Exe V4.1.0.894 Assembler: Armasm.Exe V4.1.0.894 Linker/Locator: ArmLink.Exe V4.1.0.894 Librarian: ArmAr.Exe V4.1.0.894 Hex Converter: FromElf.Exe V4.1.0.894 CPU DLL: SARMCM3.DLL V4.23 Dialog DLL: DCM.DLL V1.4.0.0 Target DLL: Segger\JL2CM3.dll Dialog DLL: TCM.DLL V1.4.0.0
This does work but the build takes a few minutes each time rather than just seconds when doing a build after a small change in uVision itself.
Of course it does: your batch file requested a full re-translation of all sources instead of just a plain build. You can replace "-r" by "-b" to change that.
Sorry that was not what I really meant to post. My batch file did have -b but I had tried -r just to see if I got a different result.
Do you find that -b works like build rather than rebuild? I so does anyone know of a project configuration setting that could affect the operation.
Thanks
Stephen
Do you find that -b works like build rather than rebuild?
Yes.
Can I ask what your complete command line is? Are you running it from a .bat/.cmd file?
I had assumed that it would work as you see, but so far it is always rebuilding. Strange.
I think I have tracked down my issue. The .dep file was write protected(It rightly or wrongly is checked into source control). This does not seem to stop incremental builds from working when building within uVision itself.
Hope this helps someone else.
This does not seem to stop incremental builds from working when building within uVision itself.
That figures.
I would expect it to hurt the first incremental build per GUI session, too. From then on the IDE probably keeps the current dependency information in RAM, so all later builds in the same session can benefit from it and only build what really needs building. But if the saved version can't be updated when the session is closed, the penalty for out-of-date dependencies has to be paid once per session --- which for batch operation means every time.
This is an example case supporting the old rule: you don't check generated files into the revision control system. Not unless there's a really good reason for it, anyway, like: not everybody on the team has access to the tool generating them. And if you do check them in, prepare actions to automatically undo the write protection before running the corresponding generator tools.