Migration to Windows 7 .. cpu support packages
Hi Guys,
I've just moved from Win2k to Win7x64. Most things are going OK, but I have a couple of issues. Just one for now.,
Trying to work on an existing in-progress project, the system header files will not open.
That is because Crossworks is looking for them here: (Sigh even now one _still_ can't cut and paste from error pop-ups.)
C:\Documents and Settings\gordon.CIL-UK\local Settings\Application Data\Rowley Associates Limited\Crossworks for ARM\packages\include\targets\
but on Win7 the files are actually here:
C:\Users\Gordon\AppData\Local\Rowley Associates Limited\CrossWorks for ARM\packages\targets\STM32\include\targets
I can't presently see in the configuration, from Crossworks gets that path.
As the projects are kept on a fileserver, is it feasible to move the files to a Rowley directory on that fileserver, and if so how?
That would also be important if anyone else should have to work on the project, now or in the future.
Thanks,
Gordon.
-
It sounds like you have an absolute path somewhere in your project, the easiest thing to do is open up the .hzp file in a text editor and look for the path. The macros $(PackagesDir) or $(TargetsDir) should be used to reference the packages and targets directory rather than using an absolute path.
You wouldn't normally edit the files in the packages directory, the intention is that if you need to modify any system files you would import them locally into your project (right click on file in project explorer and click Import) and then edit them.
Having said that, you can change the location of the packages directory by clicking Tools > Options and setting Environment > Directory Options > Package Directory.
-
Hi Jon,
I tried looking though the .hzp and .hzs files, but the path wasn't there. I tried grepping every file in the project for "Documents", found some in the build directories, so I just deleted the lot from there and started a rebuild, though as a work-in-progtress, currently I have some errors to sort.
However .. compiling just STM32F10x_ctl.c fixes that problem. Closer inspection reveals that the absolute path is embedded in both the .d and .o files, and that is from where the IDE gets its path to the source.
I tried setting the Package Directory to a UNC name:
- //cilserver20/users/gordon/CrossWorks_Packages/CrossWorks for ARM/packages
But it's rather confused about that:
- U:/cilserver20/users/gordon/CrossWorks_Packages/CrossWorks for ARM/packages/targets/ST_STM32F10x/STM32F10x_ctl.c: No such file or directory
Using the mapped drive sorts it out, so I guess I'll need sort out a map directory for CrosswWorks. Well, I'd been thinking it was time softwaere was centralised, anyway.
Please sign in to leave a comment.
Comments
2 comments