Apparently my brain kept working on the redirection problem that I blogged about yesterday as when I woke up the morning I had a good clue what the problem was: Long path names. That turned out to be at least big part of the problem. However, it was not quite that simple, it never is! I didn't have time to do a complete research into the problem and nail down everything, but here is my findings and theories. <\/p>\n
It appears that the compiler has issues finding files if the path to them includes pathnames that are more than 8 characters long. For example:<\/p>\n
\r\nC:\\Dev\\Prod\\Utilities\\Src\r\n<\/pre>\n<\/div>\ncauses problems, but <\/p>\n
\n\r\nC:\\DEV\\PROD\\UTILIT~1\\SRC\r\n<\/pre>\n<\/div>\ndoes not cause a problem. But like I said, that is just part of it, as:<\/p>\n
\n\r\nC:\\Dev\\Prod\\XPTheme\\Src\r\n<\/pre>\n<\/div>\nalso caused problem. Either the problem is that there were other paths in the *.INC
\nline that use long path names (and there were) OR the compiler didn't grasp somehow that <\/p>\n\n\r\nC:\\DEV\\PROD\\XPTHEME\\SRC\r\n<\/pre>\n<\/div>\nis a short path name! I'm not sure which it is and didn't have time to figure it out. <\/p>\n
Using a macro for any part of the path fixes the problem completely. For example, I created this macro:<\/p>\n
\n\r\nDEV=C:\\Dev\r\n<\/pre>\n<\/div>\nand then used <\/p>\n
\n\r\n%DEV%\\Prod\\Utilities\\Src\r\n<\/pre>\n<\/div>\nand there was no problem at all. So using the macros somehow makes the IDE correctly interpret the path name and probably convert it to a short path and the compiler is happy. When I had cleaned everything up, I ended up with just two macros being defined in my C60EE.ini:<\/p>\n
\n\r\nProd=C:\\Dev\\Prod\r\nDev=C:\\Dev\r\n<\/pre>\n<\/div>\nI also came to a final consensus on the folder structures I'm using, which seems to be working pretty well so far. The Dev folder has 3 folders now:<\/p>\n
\n
\n \n C:\\Dev\\Prod<\/b>\n <\/td>\n \n Products<\/b>. Each product has its own subfolder so it can be easily added to version control. This way the entire product folder can be checked out and committed.\n <\/td>\n<\/tr>\n \n \n C:\\Dev\\Projects<\/b>\n <\/td>\n \n Non product projects<\/b>. This folder contains client projects, in-house projects and anything that cannot be classified as a product, free or commercial.\n <\/td>\n<\/tr>\n \n \n C:\\Dev\\Source<\/b>\n <\/td>\n \n Other sources<\/b>. This is basically a catch all folder for anything that doesn't directly belong in either of the above. Currently it holds templates and classes that I use in some of my own apps, but are neither a product or a project on their own, nor do they belong to a specific product or project.\n <\/td>\n<\/tr>\n<\/table>\n With the structure in place I spent most of today copying and moving files from my old structure to the new one and test compiling various projects and products in both Clarion 6.3.9053 which I use for one client project, and Clarion 6.3.9058, which I use for pretty much everything else. <\/p>\n
So tomorrow will be the day that I convert all my editor projects to work with the new folder structure as well as my Build Automator scripts. Then I will get this on to a virtual machine and test the structure with Subversion to make sure that it holds up for the version control! <\/p>\n
Arnor Baldvinsson<\/p>\n
<\/div>\n