Hi
Szakáts Viktor wrote:
>
>> 1.
>> -workdir=
>>
>> This switch is not a part of .hbp.
>> Can it be included here?
>
>
> I left it because it's target specific detail. Best to have it
> in .hbm or cmdline.
>
IMO it is useful in this form:
{bcc}workdir=...
I am trying to reduce the number of batch configurations.
> I really wanted to keep it simple, so no such freeform
> comments are supported, intentionally. If we complicate
> it each .hbp reader and parser will have to be much heavier,
> error prone and hard to implement. Usually these files are really
> small, f.e. my whole project with 600+ files is no more than
> 8 lines + lib template is 30-50. For similar reasons I left
> out any usual freeform support for parameter lines.
>
I agree to not implement commented blocks.
May be src/*.prg is not an option for everybody.
BTW I am interested how you designed your
8 lines + lib templates.
>> 3.
>> -o<OutFileName> also cannot be defined in .hbp.
>
>
> Also build/app/target specific option. .hbp is meant to accompany
> 3rd party libs and in such file is best to leave out everything
> which is app specific. What you need is probably an .hbm
> file if you miss -o.
>
You already have implemented filters, no?
So
{bcc}outfile=c:\dev_exes\vouch.bcc
{msvc}outfile=c:\dev_exes\vouch.msvc
I avoid one more parameter in routine batch file.
What is the loss if it is implemented in .hbp also
alongwith how it is behaving as of current.
4.
>> Can we define a macro in .hbm like:
>> $source_folder=c:\dev_sources\vouch
>>
>> {source_folder}\vouch.prg
>> {source_folder}\b_myprg.prg
>
> You can define envvars outside hbmk2 and use them as ${ENVVAR}
> I prefer to encourage users to minimize such hard wired paths in
> these config files. You can use relative to .hbm dirs, usually it's
> much more flexible. I mean you place your .hbm file in
> C:\dev_sources\vouch
> and simply put the .prg file in there as vouch.prg, b_myprg.prg.
> You can include this .hbm file from other .hbm files or from command
> line either by absolute or relative dir and hbmk2 will find your .prg
> files. Adding such variable handling engine in hbmk2 would create a
> quite heavy layer with several complications not just for hbmk2
> development,
> but also for users, f.e. how these can be inherited, which is stronger,
> envvar or local var, exporting, importing, so basically all the burden
> what
> is present in regular script files and GNU make, and which makes them
> much more complicated to use than necessary.
>
Ameen.
What is the syntax of using ${ENVVAR} in .hbm files.
It practically solves my purpose.
Regards
Pritpal
PS : I am asking so much because though xMate has served well
all these years still I felt the punch of some very important missing
features which Andy could never get a time to implement.
--
View this message in context:
http://www.nabble.com/HBMK2---Few-Changes-tp23348709p23349792.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
