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?
I ran into this when integrating my project with Eclipse. I have a batch file called "build.cmd" with the following contents:
c:\keil\uv4\uv4.exe -b RSN_BB0.uvproj -o errors.txt type errors.txt
Not sure if it's doable without an intermediate file, I tried various tricks with stdout to no avail.
Thanks for the answer; I'm doing roughly the same thing, but it feels like a hack. I don't really understand why it can't output directly to stdout. I though that I missed something in the documentation...
This is real pain in an automated build process / production software environment! Isn't there some other option?
I don't really understand why it can't output directly to stdout.
Largely because Windows GUI programs (like uVision) don't have any stdout stream in the first place, so nothing to output to.
Isn't there some other option?
There's always make, and it's load of descendants/variations.
Because it is, essentially, an interactive tool - so everything happens through the GUI (Graphical User Interface).
For non-interactive use - when there is, effectively, no User - make or some equivalent would be more appropriate.
Ah, but then you have to try to maintain synchronization between the make files and the UVPROJ/UVOPT file.
It appears that even the batch file creation hasn't been regression tested for some time. The "Make Batch files" functionality generates a batch file that will only work if you already have the intermediate files generated, i.e. it won't work for a clean build. NOT USEFUL FOR PRODUCTION.
If I go to make files, msbuild, maven or [N]ANT, then I don't see sufficient value in the licensing fees and will go with GNU tools and encourage others to do likewise.
True.
Doesn't really say much for uVision as a truly professional toll, does it?
"batch file that will only work if you already have the intermediate files generated, i.e. it won't work for a clean build"
I think that was the case when I tried this feature about 6 years ago!
"NOT USEFUL FOR PRODUCTION"
Indeed!
I used the contents of the output directory as information to manually write a Makefile.
*.__i contains the compiler options needed when compiling each object file. *.d contains the dependancies for each source file. <proj>.lnp contains information for linking.
All that is missing is an automatic tool to scan these files and create a real Makefile.
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.