>
> 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.
> 2.
> No support for commented block.
> /*
> */
> IMO it must be avialble in both .hbp and .hbm.
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.
> 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.
> 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.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
