Hi,
> hbide_pathProc() is only effective when
> source tree is beneath its location only. In case
> it is there on some upper level folder, this mechanism
> fails.
No it doesn't fail. If it's in an upper level directory,
the only change is that you will use "..\..\mysource.prg".
If the "upper level directory" is a fixed one, and AFAIK
this is what you like to use in your personal projects,
you will use "C:\myfixeddir\mysource.prg"
My function won't fail in any of these case. In first,
it will merge the base path with relative path and
give "myprojectroot\..\..\mysource.prg" and find the
.prg. In second case it will use "C:\myfixeddir\mysource.prg"
and find the file.
IOW my function will allow also for this option,
and give the choice to user to use relative or
absolute paths for any source files.
> But in real development pattern one has adopted
> since years has to be changed. For example, I keep
> my sources in
> {root}/dev_sources/under_various_subfolders_per_interest
> and project contains sources from multiple such subfolders.
> Many projects contain same source.
> If I keep the .hbps in {root}/dev_sources, only then
> such path synchronization will work. Right?
No.
> If it is "yes" then probably we need to devise another
> mechanism to hold the path info .hbi ( scheduled to be
> embedded in .hbp ). I do not want to populate my
> source folder tree with something I never wish to back-up.
> What other means can you suggest.
Pls read above.
> <SrcPath>=folder_source_path meta-mechanism is designed
> for such scenario.
It's not necessary to find files.
It's only necessary if you want to avoid repeating
the same long path a lot of times and this long path is
not devisable from any root paths. For such purpose,
you can use macros, like you say, and this is supported
also by hbmk2 ('{MYPATH}\source.prg' and '-env:MYPATH=C:\dev_sources\').
Anyway I don't like such solution, it's much simpler
and self-contained if you create an .hbm file with
list of files in your C:\dev_sources\this\that\ folder,
named C:\dev_sources\this\that\filelist.hbm, and simply
refer to this file using hbmk2 option: 'C:\dev_sources\this\that\filelist.hbm'
or if you don't like .hbm extension, you can change it
to anything and use: '@C:\dev_sources\this\that\filelist.ext'
You can embed this option into your .hbp file.
(Even the parser I wrote for hbide can be extended
to support such embedding (see my notes in comments),
but I stopped investing time into this.)
The best solution tough is if you simply store you
.hbp (or .hbi) file inside C:\dev_source\...\myproject.hbi,
open it, and voila, it will find all the source files,
without any extra trick.
I don't know your workflow, but if you like to store
you sources and the make files that belong to them in
different places, detached from each other, you can
stick to macros.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
