See http://www.keil.com/forum/56892/
"The project file should have been 100% focused on the rules required to perform the similar task of a Makefile. Everything else should have been optional information stored in separate files that doesn't need to be version-controlled and that can be auto-created if missing"
I entirely agree. It seems that Keil have totally broken the Project File arrangement as far as Version control goes.
:-(
And how is it intended that the Pack status should be controlled??
Hello Andrew,
you can control the Pack status using the "Select Software Packs" button next to the "Manage Run-Time Environment" button. If you unselect "Use latest versions of all installed Software Packs", you can specify for every Pack the exact version that is to be used with the project.
Kind regards,
Christopher
And what is the official recommendation for source code management of the different files, so that a developer can check in a complete project and a different developer then check out the project and be able to build using the same options/versions etc. But without all the time getting large amounts of SCM differences from open editor files, size of windows etc?
I feel that Keil should have a whitepaper available about this critical part of how to use the Keil tools. And if you do get into troubles writing that whitepaper, then that would indicate that there might be issues with the separation of information in the different uVision project files.
"you can control the Pack status using the "Select Software Packs" button next to the "Manage Run-Time Environment" button"
And where is that setting stored?
" ... about this critical part of how to use the Keil tools. And if you do get into troubles writing that whitepaper, then that would indicate that there might be issues with the separation of information in the different uVision project files."
Absolutely!
Then you might see things like the fact that the filetype descriptions are wrong; eg:
http://www.keil.com/support/man/docs/uv4/uv4_b_filetypes.htm
"*.UVOPTX: µVision5 project options. Contains the settings for the debugger, trace configuration, breakpoints, currently open files, ... . This mandatory XML file can be shared in a work-group."
Actually, it does not contain anything about "currently open files" - that's in the project.uvguix.<user> "user preferences" file.
However, it does show which groups in the Project explorer are expanded or collapsed - which are, surely, "user preferences" and should **not** be in a shared workgroup file!?!?
And Breakpoints should, surely, **not** be in a shared workgroup file!?!?
hello Andrew,
that is stored in the <RTE> section of the uvprojx file, for example:
<RTE> <packages> <filter> <targetInfos/> </filter> <package name="CMSIS" schemaVersion="1.3" url="http://www.keil.com/pack/" vendor="ARM" version="4.2.0"> <targetInfos> <targetInfo name="ULINK pro" versionMatchMode="fixed"/> </targetInfos> </package> <package name="STM32F1xx_DFP" schemaVersion="1.2" url="http://www.keil.com/pack/" vendor="Keil" version="1.1.0"> <targetInfos> <targetInfo name="ULINK pro"/> </targetInfos> </package> </packages> ...
For the CMSIS Pack, versionMatchMode="fixed" means that the version of the Pack is fixed (in this case to 4.2.0). The STM32F1xx_DFP is set to "use latest" in the GUI and thus it does not get a versionMatchMode entry.
Hello Per,
have you seen our Application Note 279 ( http://www.keil.com/appnotes/docs/apnt_279.asp )? This is a first version of our way of looking at project revisioning using Git. I would be very happy to get some feedback on AN279.
Thank you. I'll take a closer look at that application note.
http://www.keil.com/forum/60086/#msg195729
uVision creates a Build Log file with the name <project>.build_log.htm. This file lists:
For re-creating a project it is important to install the same Compiler Version and Software Packs. Typically this requires:
We have information about the b>build_log.htm here http://www.keil.com/support/man/docs/uv4/uv4_ca_buildlog.htm
As I can see right now, this seems to be quite complex to understand. Perhaps because the process is not clearly documented. I believe improving the documentation would do the job, but I am open to listen to suggestions (please post them on this forum).
Thanks Reinhard