Hi, Apart from finding a post which says 'this has been discussed before', I haven't found much information on if/how I can run perform a pre-make stage on my uV2.40 project. I want to run a dos command/batch file to perform a purge of all unrequired file types prior to the building of my project. Is there any way of achieving this? David
uVision translates the files in the order they appear in the Project. Therefore, you just need to put your batch file as the very first file in the project. You would probably need to set it as a "Custom Translation", and "Always Build".
http://www.keil.com/forum/docs/thread1652.asp (With current versions of uVision, it is now easy to move files & groups around in the IDE to get the order you require)
See also: http://www.keil.com/support/docs/1823.htm http://www.keil.com/support/docs/1878.htm
http://www.keil.com/support/docs/1878.htm says: "I have an application program (VAREXT.EXE) that I use to automatically generate some include files." Note that uVision has no dependency facilities for Custom Translations; therefore the include files (in this case) will be re-generated for every build - whether it's needed or not. :-( This, in turn, will mean that every source module that includes the generated files will be re-translated on every build. :-( Therefore, in this case, you might want to set VAREXT.EXE to 'Exclude From Build', and only manually change it to 'Include In Build' when you specifically want to re-generate the includes. Of course, this rather defeats the object of having it in the Project to start with! :-( I had this problem with the Triscend E5, where source files are generated to describe the logic configuration. I eventually abandoned the idea of trying to include it in the uVision Build process - for the reasons described above. :-(
Therefore, in this case, you might want to set VAREXT.EXE to 'Exclude From Build', and only manually change it to 'Include In Build' when you specifically want to re-generate the includes. Or just keep it excluded from the build, and just use the "compile this file" function on it, which should be a lot easier. Or make the tool a bit more intelligent by having it compare its output with the previous state, so it can avoid touching files that diddn't change. Of course, this rather defeats the object of having it in the Project to start with! Not necessarily. Having the name of that file in the project list still helps to keep things organized. Around here, e.g., we tend to keep an informal TODO list file (in its own source group, and excluded from builds) as part of the project, just to have it close at hand.
"Or just keep it excluded from the build, and just use the 'compile this file' function on it" When I was actually trying this, it didn't work - the 'compile this file' function was greyed-out by excluding a file from the build! :-( I think I moaned about this to Keil at the time - so perhaps it's changed now? "Having the name of that file in the project list still helps to keep things organized." Yes, I totally agree! "we tend to keep an informal TODO list file ... as part of the project, just to have it close at hand." Ages ago, Borland Turbo-C used to have a feature called "Project Notes" to do exactly that sort of thing. It was extremely useful!