We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm building my project via the command line using something like this:
"C:\Program Files\Keil\UV4\Uv4.exe" -b ".\myProj.uvproj"
The problem is that this command does not send anything to the stdout. The only option I see is to output the results to a file, using the -o option. Is there any way of just showing the results in the same command prompt window without resorting to some ugly hack?
Also, is there any way to perform a clean on a project via the command line?
Largely because Windows GUI programs (like uVision) don't have any stdout stream in the first place, so nothing to output to.
Then what do you call the contents of the "Build Output" window? see http://www.keil.com/support/man/docs/uv4/uv4_ca_buildproject.htm
"Then what do you call the contents of the "Build Output" window?"
And how do you think the text got there? The GUI didn't have any stdin that could accept any stdout from the compiler/linker.
Per,
I really appreciate your statements in the final posting on the thread regarding tool installation locations.
http://www.keil.com/forum/16556/
Keil really does appear to think only in terms of small-code projects, with a single developer. They do not appear to consider the Production Software use model, where multiple developers commit their source to a shared repository and an autonomous machine automatically performs the "definitive" build.
For the cost of the tools, I'm a bit underwhelmed, particularly considering the quality of their support.
I think the list of users who would want Keil uVision a bit better adapted to automatic builds, version control etc could be made very, very long.
Alas, we don't have the ear of the responsible developers/managers, or they simply have a completely different view on software development and work processes in different companies.
I'm not sure how often they travel around and meets their customers at the customers place (instead of quick meets at fairs or meeting new customers when they hold seminars/courses), but I do suspect that they have not really spent some real time looking at real-life needs.
They are more interested in how to make sure each company pays multiple licenses of not only the uVision system but all the source code bundles too than they are in thinking about build machines, version control, regression testing etc.
Agree. We're a huge customer for ARM (mostly processor IP) but don't seem to have their ear. It's worse with Keil, which still seems like a separate company. I like their stuff, definitely prefer it to IAR, but its idiosyncracies are getting more amd more out of touch with the main stream. At this point Hitex seems a lot more responsive to our requests, we'll see where it goes...
Then what do you call the contents of the "Build Output" window?
The output of a non-GUI program (the compiler), which runs as a child process of the GUI. This output is captured and displayed inside the GUI program.
Hans-Bernhard,
The problem is that there is no functional export method of the GUI project file that will work for a full build from a source repository. Thus, one must use the UV4.exe command line, which still doesn't export the compilation result data that is output by the compiler to the stdout and/or stderr streams that can be monitored by an automated build utility.
UV4 is not the center of the universe. Being a good citizen in the tool world goes a long way.
If I have to create make files from scratch, that have to be maintained by the developer, then the value of the IDE is dramatically reduced. There are other IDE's that provide similar utility and cost a lot less.
which still doesn't export the compilation result data that is output by the compiler to the stdout and/or stderr streams that can be monitored by an automated build utility
It does output them to a file though, which is trivially easy to package shoot out through stdout later, if you have your heart so strictly set on doing it that way. So no problem at all.
Hans-Bernhard, That's a poor excuse for a production build process.