| T O P I C R E V I E W |
| hajo_old |
Posted - 08/16/2004 : 3:29:25 PM
Hello, all
I just tried to pack my project using opk and extract it on an other Origin installation!
1) Configuration: same computer, other Origin_User path
(I changed the origin user path before opk installation by "delete -path" and restart of Origin.)
OPK installation was fine on the first view, but when I try to load an Origin Workspace during startup code, compilation stops and linking of the workspace file failed!
The reason for that seams to be, that not all files/paths are correctly translated by packing the OPK archive. Some paths still are on its old level. Especially those in sub directories of my project tree! Those in the root folder seem to be ok!
Example:
<root>
<include> -> some include files (*.h)
<classes> -> all the classes I need for the project
function_files -> (*.c)
script_files -> (*.ogs)
For the <classes> directory the workspace include definition looks like:
<root_old>//<classes>//filename.c
For the script files the entry looks like:
script_file.ogs
An other point Im wondering about is, why some paths are relative (those seem to work) others are absolute!!
2) Configuration: from Laptob to work PC (two different computers)
same issue!
Any hints?
I use OriginPro (Eng) v7.5Sr4
Thanks
Hajo
-- --
Dipl.-Ing. Hans-Joerg Koch
SiemensVDO Automotive
Regensburg
Edited by - hajo on 08/16/2004 3:32:02 PM |
| 6 L A T E S T R E P L I E S (Newest First) |
| Mike Buess |
Posted - 08/26/2004 : 3:16:26 PM
Hi Hajo,quote:
Writing a seperate OC function might be a sollution, but as there seems to be no consistant way eighter to use relative or absolute pathing I wanted to make that clear to all of us!
As far as I can tell run.loadOC() and CodeBuilder both want OCW files in which the paths are either absolute or relative to the path of the OCW file. We agree that the problem is that CodeBuilder will replace valid relative paths with full paths, which fowls things up when we try to distribute our apps. How best to fix that? It would make more sense to me to make CodeBuilder save OCW files using relative paths whenever possible than it would to enhance opack to handle the problem.
In any case, the work-around should not be difficult. This function strips User\OriginC\ from all paths listed in User\OriginC\MyOCW.ocw. Hopefully something like it will work for you.void StripPaths()
{
INIFile ini("OriginC\\MyOCW.ocw");
string sPath,sRoot = GetAppPath() + "OriginC\\";
int nRoot = sRoot.GetLength();
int nFiles = ini.ReadInt("Workspace","FileCount",0);
sRoot.MakeLower();
for(int i=1;i<=nFiles;i++)
{
sPath = ini.ReadString("Workspace","File"+i,"");
sPath.MakeLower();
if( sPath.Find(sRoot,0)==0 )
ini.WriteString("Workspace","File"+i,sPath.Right(sPath.GetLength()-nRoot));
}
}
Mike Buess
Origin WebRing Member |
| hajo |
Posted - 08/26/2004 : 11:14:53 AM
Hello, Mike
quote:
It seems to me that the real fault lies in the way CodeBuilder handles workspace files. If it didn't replace relative with absolute paths on Save then you wouldn't have this problem to begin with.
That's the reason I write the whole thread about!!
Writing a seperate OC function might be a sollution, but as there seems to be no consistant way eighter to use relative or absolute pathing I wanted to make that clear to all of us!
The next thing is, that "correcting" this within the Pack/Unpack Tool is a central place. Especially as the user path stuff is also handled at that point. Additionally you can't forget to "fix" the paths in the workspace file, because the tool is taking care of the right location!!
Thanks
Hajo
Edited by - hajo on 08/26/2004 11:16:33 AM |
| Mike Buess |
Posted - 08/26/2004 : 08:57:56 AM
Hi Hajo,
The Pack/Unpack tool is oblivious to the contents of files in an OPK archive. It will unpack all files to their proper places but what happens after that is up to the programmer. It might be possible to correct the paths in the OCW file from the OnAfterSetup section of OPKSetup.ogs but would probably be easier to edit the OCW prior to packing and make all paths relative. Since the OCW has an INI structure it should be possible to create an OC function which reads each key, strips the User path from the value and then writes the result.
It seems to me that the real fault lies in the way CodeBuilder handles workspace files. If it didn't replace relative with absolute paths on Save then you wouldn't have this problem to begin with.
Mike Buess
Origin WebRing Member |
| hajo |
Posted - 08/26/2004 : 04:14:58 AM
Hello, all
Anyone working at that issue at the moment?!
I did some tests the last days according to that issue with the results that:
- if I edit the OCW file and "correct" all paths to relative, the project is read in fine by CodeBuilder.
- saving the workspace by "Save As" produces me the absolute pathing again (relative pathing is lost!) only for *.c (*.cpp) files. *.h files are kept relative!
- packing OCW to OPK with the Pack/Unpack Tool and installing to different computer and then loading the workspace by "run.LoadOC" works for the preedited OCW file (relative pathing) fine! Not for newly saved OCW files (*.c -> absolute; *.h -> relative pathing)
So, it seams to me, the Pack/Unpack Tool doesn't take care of the locations stored in a workspace file by packing an archive, so initaializing a workspace by run.LoadOC ONLY works on the computer the automation application was created! On other computers I'll have to edit the OCW file by hand to get the paths right!!
Is that true?
Is there a solution available in short term?
Thanks
Hajo |
| hajo_old |
Posted - 08/17/2004 : 03:04:19 AM
Hello, Mike
thanks for clearify that issue ...
But I edited the workspace file after compilation/link error after installing the OPK. I didn't use the Pack/Unpack tool for examining the paths!
The files ARE unpaked to the propper places as far as I can see, but the workspace file I call for initialization by
"LoadOC(workspace.ocw)"
is corrupted so linking and compiling failed as the files aren't loaded into the workspace!
After editing the file by hand and correcting the corrupted path entries everything works fine!
-- --
Dipl.-Ing. Hans-Joerg Koch
SiemensVDO Automotive
Regensburg
Edited by - hajo on 08/18/2004 05:36:35 AM
Edited by - hajo on 08/18/2004 05:37:08 AM |
| Mike Buess |
Posted - 08/16/2004 : 5:03:27 PM
Hi Hajo,
Are you saying that the files are not unpacked to the proper places? I suggest that you open the OPK with the Pack/Unpack tool and examine all paths. There can be two types of entries... folder\file.ext and \folder\file.ext. (The only difference is the presence or absence of initial \.) If the user path is C:\Origin75\User1 then folder\file.ext is unpacked as
C:\Origin75\User1\folder\file.ext
and \folder\file.ext as
C:\folder\file.ext
(i.e., file path\names that begin with \ are unpacked to the root of the drive containing the User path.)
Mike Buess
Origin WebRing Member |
|
|
