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
sounds like an obvious approach to me!
Hi Andy,
I could have bet, that you will reply.
I think it will be hard for me to argue against your substantial list of arguments, but give me a try.
For a person which is ransacking this forum, which works with KEIL products since years, and doesn't have any knowledge about other (better?) IDEs, the current approach could be 'obvious'.
I would expect, that the installation program takes care about installing different compiler (assembler, linker, IDEs) versions into different folders.
And, surprise surprise, the installation script of MDK_ARM does it. Ok, only half the way, as you can see in my previous thread (16556).
Now, compiler, assembler, linker, include files, lib files, uVisions would reside (and they do, if copy it manually) in different (named after the version) folders.
Do you think it would be so difficult to add a 'use this compiler/assembler/linker' setting to the project settings?
Usage of a specific compiler version is an attribute to a specific project, and should not rely on the setting of a user.
Think of larger companies with many software engineer and many projects. They should not switch the compiler version by switching the IDE! The project setting says what to do (and what to use).
The current approach is neither a bug, nor is it 'obvious', but it is bad design.
BTW, I'm used to work with the HEW from Renesas, and it is doing it in the correct way (as far as I remember :-))
But peace, Andy, peace. Maybe you come to the Munich Oktoberfest, and we can discuss that with one or more beers.
=> The current approach is neither a bug, nor is it 'obvious', but it is bad design.
BTW, I'm used to work with the HEW from Renesas, and it is doing it in the correct way (as far as I remember :-)) <=
Just curious:
Is the conclusion of bad design/correct way based on some methodology research?
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?