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.
Do we have to specify the header files' path which are located in different directories one by one directory ? Can I just specify the general directory ,and letting the mdk itself searching header files in sub-directories?
There are too many sub-directories,and it's taking a lot of time. Can anyone help me please? Thx!
Write a small script or applet, and paste the list into the project file.
Won't it find them in the current directory? Or have you created some difficult project structure?
I find that the searching directory doesn't contain sub-directories.
So how, exactly, are you doing that search??
The search facility within uVision certainly can include subfolders;
The search facility within Windows Explorer certainly can include subfolders.
So perhaps you should re-think the design of your project, then?
Andrew, my project is very large, and the design of subfolders is used to make the whole structure more clearly ,just like linux subfolders.
The 'search' here means that, when filling the 'include path' in 'C/C++' tab of the project in uVision, I find that if I only contain main level folder, the subfolders won‘t be searched for header files needed.
Example, file "basetypes.h" is located in folder B, which is a subfolder of folder A. file "basetypes.h" is needed by file "main.c" which is located in folder A.
/*main.c*/ #include"basetypes.h"
If I just set the include path as './A', then the complier will pop an error as "can't open basetypes.h,the file is not found"
I wonder if there's any settings in uVision I missed?
I normally use relative path in the source files if I need a number of subdirectories.
So
/* main.c */ #include "com/magic_protocol_1.h" #include "com/magic_protocol_2.h" #include "i2c/eeprom.h" #include "spi/modem.h" ...
The source files in their subdirectories can manage with just:
/* i2c/eeprom.h */ #include "eeprom.h" ...
/* spi/modem.c */ #include "modem.h" #include "modem_commands.h" #include "modem_compression.h" ...
Then I don't need a huge number of include directories specified for the project, even if the project has many 100k of source lines spread over a large number of source files.
thank you,Per. It seems the best solution for the current MDK. I'll take it.
Indeed. I'm pretty sure it searches in the directory the current file comes from first, so my implied understanding is some unnecessary division of files is occurring due to the project being imported from some other build system.
ie modulex\src and modulex\inc instead of putting all ModuleX's junk in the singular modulex directory
Anyway, I'm pretty sure
DIR *.h /s
can descend into directories and one could process that output with a simple script or text editor, into a list of directories. Might take a few minutes, and then open the project file in a text editor, it's in ASCII, and copy in the list to the "<IncludePath>" entry.
thank you. I wrote a .bat file like this,
DIR D:\project\*.h /B /s > D:\project\out.txt
But it outputs like this,
D:\project\driver\can.h D:\project\os\cmsis.h ...
ie,it contains not only the folder path, but filename too, besides there's no semicolon in the end of each line, which cannot be recognized by uVision.
I tried several 'DIR' related commands, like '/ad', but still can't figure it out. Could you tell me what's the exact command to do it?
You seem to see problems.
Let's just think about your above dir output.
3 minutes with any free Windows compiler would be enough to write a program that: - strips the rest of the line after the last path separator. (strrchr) - throws away lines that matches the previous line. (strcmp, strcpy) - concatenate new lines with ';' in between. (strcat/snprintf/printf/...)
And that is just one of many possible options.
There is seldom time to find the "best" or "optimal" solution - most of the time "good enough" will do.
yeah, I know we can write a simple program by ourselves. Maybe i was fixed to seeking for the 'perfect' solution provided by uVision itself.
'most of the time good enough will do', you're right, especially for us engineers, and I'll take it.
thanks,Per.