You would think with the uVision's Run-Time Environment Manager and Software Package Selector with all its version control and download features that I should have no trouble switching between machines while working on a project. Well, you'd be wrong.
Half the files in my project are just being referenced to locations in the Keil program directory, while the other half are copied to my project folder. Why?
Some of these files are considered Packages, some are considered Components, and some are just considered included files. They are all just .c and .h files. Why are some handled one way, and others handled differently?
Why after moving my project to a new system do I have to spend hours making sure every setting in every menu is identical to the other machine my code was created just to get the code to compile when all of the information needed to do this already is (or should be) stored in the project file?
Unless I'm missing something all I see from these 'features' is larger file sizes for data that isn't actually being used to do anything to help workflow. All I'm finding are obstacles and reasons to switch to another IDE.
Hi A Wy,
thanks for sharing your problem with us. I have re-created the issue here and I can see that there is no warning message when you load a project that was based on new Software Packs (but these Software Packs are not installed on the computer). We are going to add such a warning in the next months.
However the file <project>.build_log.htm contains already today detailed information about the toolchain version and the Software Packs that have been used. See: http://www.keil.com/support/man/docs/uv4/uv4_ca_buildproject.htm. This allows you to re-install the tool environment along with the Software Packs that have been used previously.
For more information, see also my post under: http://www.keil.com/forum/59513/
I hope this helps. Reinhard
I think this whole idea of having the Software Pack separate from the Project is a Really Bad Idea - it's a configuration control nightmare!
It means that we can't just say, "check this project out of the repository, and use Keil MDK version X.Y.Z".
Instead, it becomes, "check this project out of the repository, use Keil MDK version X.Y.Z, make sure you have Pack A at version C.D.E".
:-(
While I agree that it adds complexity, I think it is a HUGE improvement of the mishmash of examples that partially supported the functionality of an MCU or protocol stack. I just wish Keil had their act together 3 years ago well before we released product, so we would not have spent so much time working around the poorly organized RL-ARM and associated middleware.
The software packs were LONG OVERDUE! It's not the 90's any more.
It's not quite as black-and-white as that. All project configuration management has to draw the line somewhere between those aspects of the build system that are put into revision control / configuration management (RCS), and those that are only specified in central "Tooling document".
All hand-written source code clearly belongs into the RCS.
Details of the development machine's operating system (service pack, driver version, ...) should, OTOH, never be needed in RCS. If they were, that would essentially mean the project's state is not reproducible at all. And of course, the RCS implementation cannot itself be in RCS :-)
License-locked development tools generally cannot be checked out as-is from a repository to an arbitrary working copy location, if only because they don't tolerate multiple copies to be present on the same machine. At the very least, you'll have to re-run some installation / registration script, or configure their license management after the fact. So most of those fall on the non-RCS of that dividing line; Keil uVision does.
Now, which side of that line third-party software components like the uVision software packs should be on is hugely debatable. If there was just a library, some header files, a configuration file, and maybe a bit of documentation in such a pack, and all the integration into the project was done completely by hand, then clearly their correct place would be on the RCS side of the line. But if a component's primary integration is with the IDE, and then in a secondary step they are just "turned on" for use by a project, it would almost certainly be pointless to try an store them in the project. What needs to be in RCS is a verifiable configuration description of the used "packs".
I.e. the closer a software pack is to the IDE, the less sense does it make to put it under project RCS, for the same reasons the IDE itself isn't in there, either.
"if only because they don't tolerate multiple copies to be present on the same machine."
This should be "don't tolerate multiple copies to be present on _different_ machines".
I have multiple versions of MDK-ARM on the same machine - older versions can make use of the same license file as the newer version.
"What needs to be in RCS is a verifiable configuration description of the used "packs"."
That is what the build log is meant to be for.
Only hitting 'rebuild all' builds a full build log. The log file shows which version of packs, and what components from the packs were used.
http://www.keil.com/support/man/docs/uv4/uv4_ca_buildlog.htm
As a bonus, the build log shows the warnings and errors resulting from the last build. So you will know years from now, that this project truly was checked in error free.
Software Packages used: Package Vendor: ARM http://www.keil.com/pack/ARM.CMSIS.4.3.0.pack ::CMSIS:RTOS:1.0 (API) CMSIS (Cortex Microcontroller Software Interface Standard) * Component: RTOS Version: 1.0 * Component: CORE Version: 4.1.0 * Component: Keil RTX Version: 4.78.0 Package Vendor: Keil http://www.keil.com/pack/Keil.MDK-Middleware.7.0.0-beta.pack ::Board Support:Buttons:1.00 (API) Keil MDK-ARM Professional Middleware for ARM Cortex-M based devices * Component: Buttons Version: 1.00 Package Vendor: Keil http://www.keil.com/pack/Keil.STM32F0xx_DFP.1.4.0.pack Keil::Device:Startup:1.5.0 STMicroelectronics STM32F0 Series Device Support and Examples * Component: Startup Version: 1.5.0 * Component: Buttons Version: 1.0.0 Collection of Component include folders: C:\keilcode\STM32f334-show\RTX_Blinky\RTE C:\Keil_v5\ARM\PACK\ARM\CMSIS\4.3.0\CMSIS\Include C:\Keil_v5\ARM\PACK\ARM\CMSIS\4.3.0\CMSIS\RTOS\RTX\INC C:\Keil_v5\ARM\PACK\Keil\MDK-Middleware\7.0.0-beta\Board C:\Keil_v5\ARM\PACK\Keil\STM32F0xx_DFP\1.4.0\Device\Include Collection of Component Files used: * Component: ::CMSIS:RTOS:1.0 (API) * Component: ARM::CMSIS:CORE:4.1.0 * Component: ARM::CMSIS:RTOS:Keil RTX:4.78.0 Include file: CMSIS\RTOS\RTX\INC\cmsis_os.h Source file: CMSIS\RTOS\RTX\Templates\RTX_Conf_CM.c Include file: CMSIS\RTOS\RTX\UserCodeTemplates\osObjects.h Source file: CMSIS\RTOS\RTX\UserCodeTemplates\main.c Source file: CMSIS\RTOS\RTX\UserCodeTemplates\MailQueue.c Source file: CMSIS\RTOS\RTX\UserCodeTemplates\MemPool.c Source file: CMSIS\RTOS\RTX\UserCodeTemplates\MsgQueue.c Source file: CMSIS\RTOS\RTX\UserCodeTemplates\Mutex.c Source file: CMSIS\RTOS\RTX\UserCodeTemplates\Semaphore.c Source file: CMSIS\RTOS\RTX\UserCodeTemplates\Thread.c Source file: CMSIS\RTOS\RTX\UserCodeTemplates\Timer.c Source file: CMSIS\RTOS\RTX\SRC\ARM\SVC_Table.s Library file: CMSIS\RTOS\RTX\LIB\ARM\RTX_CM0.lib * Component: ::Board Support:Buttons:1.00 (API) Include file: Board\Board_Buttons.h * Component: Keil::Device:Startup:1.5.0 Source file: Device\Source\ARM\startup_stm32f030.s Source file: Device\Source\system_stm32f0xx.c Source file: Device\Source\ARM\STM32F0xx_OPT.s * Component: Keil.STM32F030-Discovery::Board Support:Buttons:1.0.0 Source file: Boards\ST\STM32F030-Discovery\Common\Buttons_STM32F030-Discovery.c