Hello to KEIL people.
Why isn't it possible to store the usage of a specific compiler version within project settings.
Why should we install different MDK-ARM versions into different root folders: See http://www.keil.com/support/docs/2010.htm
This is neither an intuitive nor an modern approach!
Robert
Hello John,
I'm not sure whether I understand you right. My impression is that your answer (er.. question) is based on you're feeling as the guardian of the holy grail.
Excuse me, if this is wrong.
The question about what is good and what is evil, and how we will decide that, would go into a deep philosophical discussion.
Is my conclusion philosphical based? No.
Did I make a statistical research? No
On what it is based then? Practical work, experience and common sense.
I raised it a little in my previous post. Maybe you've read this post entirely, and tried to understand.
Again, a more detailed example: A company with some software engineers and some different projects.
A project ABC is already in production. Project DEF, and GHI is in development.
ABC was compiled/linked with Version 3. People work on project DEF and GHI with compiler/linker Version 4.
Now we have a little bug (e.g. a typo in UI-text) in project ABC. The risk for fixing this little typo is low. To change not only the typo, but also the compiler/linker Version the risk would be something higher.
Now, is there anybody who is seriously thinking that it is a good idea to let the user/programmer decide which is the correct root folder to start the IDE from (so to choose the right compiler version)?
The project setting have to say, take compiler version xxx, and have to complain if a user has not installed the correct compiler version.
When you are a lone fighter, you may have more control over your environment, and it may not matter what compiler version you are using. But the current approach is error-prone, and for a professional environment, hmm... A well educated British upperclass may say: "Well, indeed, this approach is a little bit suboptimal."
Nothing is bug free and 'bad design' free (not even me, and my programs), but it should be allowed to be said if something is bad.
Hi Robert,
=> My impression is that your answer (er.. question) is based on you're feeling as the guardian of the holy grail. <=
(Sorry for my limited English ability and technique ability.)
I hope that I can explain clearly why I asked that question.
[1]
I know that there are a lot of scientific researches on a lot of different areas. Even I can't find any solution for some specific problem, but there might be already an optimized method for that problem found by scientists.
For example: http://www.keil.com/forum/docs/thread16471.asp
[2]
I read some articles here on the forum, this one: http://www.keil.com/forum/docs/thread16108.asp
Per Westermark said: (Haven't "see" Per for quite a long time.) The concept of having multiple targets in the same project file is very advantageous, since it makes sure that related source code is kept together.
I'm a very strong believer in keeping everything together.
In the end, you want multiple, independent, ways to be able to figure out what you have, and how to combine it to a working firmware.
But it seemed that, Hans-Bernhard Broeker did not very agree with Per. So, without strong evidences, I just keep these different opinions in my mind.
One more older thread that I revisit.
Yes, I do like the project files to know what compiler to use.
If I supply product A to a customer, and they perform own tests and then accepts the delivery, then I can't just switch compiler without requesting an OK from the customer. Why? The customer may have invested significant amounts of money in their own testing before accepting the software/hardware delivery.
A switch of compilation tools means that I may not be able to recreate an identical build. Maybe the new compiler introduces a bug. Maybe there is already a bug in the current software, but masked by a corresponding bug/behaviour in the current compiler.
A number of certification processes treats the used development tools as critical parts of the certification process. Switching compiler version may then be seen as a major change requiring a new certification, suddenly upgrading a perceived minor product upgrade into a major one.
A traditional way to handle builds is to have a build machine (preferably a VMWare machine or similar that can be duplicated and moved to new hardware in case of hardware failures) that picks up all required source code directly from a repository based on a supplied tag. Then builds everything. The same machine may then be used for automatic regression testing to try to locate any unexpected changes in the new build.
Our Keil compilers are locked to individual machines. Pay for an extra €5,500 license for a "virtual user" to run on a separate build machine?
There is much need that Keil sits down and really thinks about their end users and our needs. For us, it is critical to be able to have multiple compiler versions available (unless we have but a single product), and to be able to always get the correct compiler used when building a project.
Having the project file store the required compiler version would be one of these important features to consider.
The alternative, is that we customers has to make sure that we create our own command-line solutions that can build the final and testing releases, and that we leave the IDE for debugging of work-in-progress.
If continuing the rant - Keil should also spend more time thinking about the file format of their project files. How do we manage them in a repository? How do we make sure that we can pick up all vital project settings - do we have to walk through every single dialog and try to figure out if a checkbox is checked or not?
As it is, I feel that there is a bit of lack of two-way communication between Keil and the developers. The tools are best aimed for a single developer who also happens to own all the products he is working with. But how many customers matches that pattern?