> Viktor Szakáts wrote:
>>
>> 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\').
>>
>
> Perfect. This is exactly what meta-data concept was all about.
> Now the issue is how to fetch these variables from the user?
> Because these are needed to be known before visual interaction
> starts for fetching/including/removing sources in/from projects.
>
> One idea could be
>
> {hbMK2-env}MYPATH=C:\dev_sources\
> {hbMK2-env}MYPATH_1=C:\dev_sources\common\
> {hbMK2-env}MYPATHVOUCH=C:\dev_sources\vouch\
>
> placeholder in hbide.env
>
> another ?
These are simple hbmk2 options: -env:VAR=VALUE
AFAIR there is already a place to put those.
>> 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.
>>
>
> Yes, this is the simplest one. And hbMK2 will receive
> sources in this format only. The point of discussion is
> how to retain path structures in visual concept.
Sorry I still totally fail to grasp the "visual
concept" you're trying to pursue here. I don't
know what difference does a GUI make in assembling
a list of files from on-disk config files. F.e.
hbmk2 also need to know the proper location of each,
so the problem appears to be the exact same.
Do you need a full-blown .hbp parser which duplicates
the hbmk2 logic? and which give you the full path for
each file participating in a project?
If not, what is the actual problem?
>> 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.
>>
>
> I did not know that concept of macros exists in hbMK2.
> that is why I devised meta-data. I will finetune hbIDE to take
> advantage of it. Bust as I said we need a placeholder
> to know these values beforehand.
It's not something overly complicated, and certainly
not something needed for normal work, or overused.
Each unknown {macro} is expanded as environment variable,
that's all.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
