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.
Never witnessed any problems like this, and we frequently have to move projects from machine to machine.
Sounds like you didn't configure the project correctly in the first place.
I've had similar problems with other development environments in the past, but it (nearly) always was down to something I was doing wrong.
Do you have a build log from the original PC?
You may have to hit rebuild all to get the complete log file.
The file would show the packs and the compiler version that you used to make your project. http://www.keil.com/support/man/docs/uv4/uv4_ca_buildlog.htm
Also the uvprojx file is just an XML file you can edit with a text editor. You could compare the old and new files to see if something is different.
CMM level 1: Reproducibility
You may want to consider a SVCS, i.e. SVN. If your UVPROJ and UVOPT files have been committed to a repository along with your source files, your files should stay sane, regardless of the machine you're using. We have 3-5 people all working on the same code base targeted to the same product without that kind of issue. We have many others issues tho', and Keil has grown weary of hearing from us... ;-)
"you can edit with a text editor"
True, but there is no documentation of the content - so it can be hard to tell whether any differences are significant or not.
"You could compare the old and new files to see if something is different"
The trouble with many of these XML-based project files is that the tools don't have any set order for the elements, and seem to change the order at random.
Thus a simple text compare fails even when the content is the "same" - because the parts of it are in different order.
I can't now remember whether this applies to uVision - but it certainly does to Eclipse and MSVS.
You mean "eg" not "ie": SVN is just one example of an SVCS (Software Version Control System) - it is not a synonym for "SVCS".
As has been discussed before, the trouble with trying to keep a uVision project under Revision Control is that it "pollutes" the project files with a lot of irrelevant stuff - so the SVCS reports them as "changed" even when no real modifications have been made!
:-(
Simply opening a project to view, then closing it without making any edits or changes can result in the Project files being marked as "Dirty".
http://www.keil.com/forum/59513/
Sigh.
A pedant might start questioning whether it is "eg" or "e.g.", "ie" or "i.e.".
But life's too short to debate with self appointed forum police.
So I didn't do that - just the significant point that it is an example and not a synonym.
but you choose to focus on that rather than the issues of trying to use a SVCS on a uVision project ...
Hmm... it's surprisingly hard to find a decent diff tool for XML out there.
For this very reason, I have tried to find an "intelligent" comparison utility for XML files - but no success yet.
If anyone knows of such I thing, I'd be grateful to hear ...
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.