>> It is, but if you stick to the format, you can still use it.
>> In this case it'd be better to expose the parsing logic from hbmk2
>> code through an API though.
>>
>
> Let it be like it. I will give another extension.
> I hope .id* extensions will prevail. Better options are welcome.
I have a suggestion.
- Store project source files in an .hbm file.
- Store project options in an optional .hbp file.
- Store additional, UI controlled options in any sort of
format you prefer.
On build:
- Combine .hbm + .hbp + generate extra .hbm from additional
UI control options, and pass that to hbmk2.
This gives easy parametrization through .hbp file directly,
it also gives you the option to allow control of essential
project parameters from UI, and you can easily create
filename parser for .hbm file which contains only a list of
filename.
Using some clever file format, you may 1) combine these
three files into one (remember that .hbm and .hbp can
even be one line each), or 2) you can use a method where
the project name is the filename and above three different
setting categories are stored by different extensions:
1) myproject.hbi
HBM=file1.prg file2.prg file3.prg
HBP=-l -m -w3 -head=native
MYOPTION1=...
MYOPTION2=...
2)
myproject.hbm (filelist)
myproject.hbp (raw options - optional)
myproject.hbi (hbide specific option format)
I'd suggest using .hbi for hbide project format, be it either
the combined one or this latter solution.
Perhaps 1) is the more elegant here.
>> .hbp is the same as .hbm as far as the format goes, It's a
>> file which contains command line options with the exact same
>> syntax you would use on cmdline, you can have more than one
>> options in one line and you can have any number of lines.
>> Comment line begin with # as a convention. I suggest to create
>> one option each line to keep it clean.
>>
>
> Now I better understand .hbp and .hbm.
> I can build entire project only with .hbm. How does .hbc fits
> into the picture. Probably I may think of splitting the logic
> in .hbc and .hbm.
Maybe I told it wrongly. .hbp is the one you need for projects.
Then again, the difference between the two is rather by usage /
convention, technically they are the same.
By my intent .hbp contains everything needed to build a project,
f.e. file list and output name. .hbm contains only "some" settings,
f.e. generic .prg compilation options, or anything which can
be *reused* across multiple projects / targets. Typical example
is hbmk.hbm which is automatically parsed even.
The only special property of .hbp extension is that it is
recognized by hbmk2 and in this case it will automatically
build it as a separate project. This is useful if you want
to build multiple projects by one hbmk2 invocation.
You can force this behavior for any extension (f.e. .hbm)
by using -target option.
See this docs from ChangeLog 2009-05-25 10:11 UTC+0200:
---
Updated usage:
There are three ways to do multitarget hbmk2 sessions:
1.) hbmk2 [<common_params1>] -target=target1[.hbm|.prg]
[<common_params2>] -target=target2[.hbm|.prg] [<common_params3>]
Examples:
hbmk2 -target=prog1 -target=prog2 -target=prog3
hbmk2 -target=prog1.prg -target=prog2.prg -target=prog3.prg
hbmk2 -target=mylib1.hbm -target=mylib2.hbm -target=myapp.hbm
hbmk2 -trace -pause -target=mylib1.hbm -target=mylib2.hbm
-target=myapp.hbm -beep
2.) hbmk2 [<common_params1>] -target <target1_params> -target
<target2_params> [-notarget <common_params2>]
Examples:
hbmk2 -target hello1.prg -target hello2.prg
hbmk2 -trace -target hello1.prg -target hello2.prg
hbmk2 -trace -target hello1.prg -target hello2.prg -notarget -beep
3.) hbmk2 [<common_params1>] target1.hbp [<common_params2>] target2.hbp
[<common_params3>]
where .hbp is an .hbm file just with an .hbp extension.
Examples:
hbmk2 mylib1.hbp mylib.hbp myapp.hbp
hbmk2 -trace -pause mylib1.hbp mylib2.hbp myapp.hbp -beep
---
Overall I strongly suggest to use 3.) which uses .hbp
extension for project files.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
