Hi Pritpal, >> hbmk2_PathMakeRelative( "C:\this\test", >> "C:\that\that\proj\hello.prg", .T. ) >> hbmk2_PathMakeRelative( "D:\this\test", >> "C:\that\test\that\proj\hello.prg" ) >> > > I have started reorienting .hbi and if possible to embed .hbi specific info > in .hbp. > I am convinced that single project file is the right way to go. > > I may be asking more questions as I know nothing about *nix systems, hope > you won't mind... > > 1) hbmk2_PathMakeRelative( "C:\dev_projects", > "C:\dev_sources\vouch\myfile.prg", .f. ) > => C:\dev_sources\vouch\myfile.prg => OK > > hbmk2_PathMakeRelative( "C:\dev_projects", > "C:\dev_sources\vouch\myfile.prg", .t. ) > => ..\dev_sources\vouch\myfile.prg => OK > > hbmk2_PathMakeRelative( "C:/dev_projects", > "C:/dev_sources/vouch/myfile.prg", .t. ) > => ..\C:/dev_sources/vouch/myfile.prg => Not OK > => [ expected ] C:\dev_sources\vouch\myfile.prg
This function requires native path separators, so to fix this, always convert to native before passing them to it. Here is the function doing this job in hbmk2: --- FUNCTION PathSepToSelf( cFileName ) #if defined( __PLATFORM__UNIX ) RETURN StrTran( cFileName, "\", "/" ) #else RETURN StrTran( cFileName, "/", "\" ) #endif --- You can even save back native pathseps to file, but you should make sure to convert them to native when you load them. This way the disk files are platform independent. > hbmk2_PathMakeRelative( "C:\dev_projects", > "C:/dev_sources/vouch/myfile.prg", .t. ) > => C:/dev_sources/vouch/myfile.prg => Not OK > => [ expected ] C:\dev_sources\vouch\myfile.prg Same as above. > The idea is to retain path information in .hbp file as relative and in > normalized form (forward slash) You can store it with consistent slash type, but since these files can be edited by humans, and also hbmk2 is insensitive of the slash format, always be prepared to any format when reading the files. > as: ../dev_sources/vouch/myfile.prg, even on Windows machine, and > converted to > OS specif path. It will solve a lot of issues. > > 2) Can I have its reverse function hbmk2_PathMakeAbsolute( cRootPath, > cTargetFile, lForce ) > hbmk2_PathMakeAbsolute( "C:\dev_projects", > "../dev_sources/vouch/myfile.prg", .t. ) > => C:\dev_sources\vouch\myfile.prg > > RootPath will always be the absolute path ( os specific ) of .hbp file. This is where we started from, just lookup the original function. It's called 'PathProc()'. > 3) Is is normal if info in .hbp is sectionized ? I mean, switches and > sources separation, > as with you sent the function to parse .hbp. hbIDE needs information in > sectioned way, > free format cannot be manipulated. Once existing .hbp will be submitted > to hbIDE, > it will parse its contents, sectionize, and will overwrite the existing > .hbp with > added .hbi specific info constructed prefixed with #. I'd suggest to touch it only as absolutely necessary. As for "sectionizing", I think it's not very good, since you need to be able to parse native .hbp files anyway, so section can get deleted, or not present at all. For pure cosmetic reason you could add them, but IMO it's not very polite to add unnecessary information to config files. For a start you can simply write an .hbp file based on in-memory information using your own formatting. F.e. options first, empty line, source files, empty line, hbide options. Later this can be extended to keep track of change in-memory and try to replicate original format, with original comments, when writing out the file. To make a little simpler, I'll add a new switch to hbmk2, which it will always ignore, so it can used to specify hbide (or other 3rd party tool switches), I plan to call it -3rd=<string>, so you can add hbide specific options, without fiddling with comment trick, like this: -3rd=-hbide-specialoption -3rd=-hbide-projectfriendlyname=Hello I hope that helps. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
