Viktor Szakáts wrote:
>
>>> 9) In the project properties would need a field to set the target
>>> platform and may be useful to make cross-build process.
>>>
>>> Target platform is just an hbmk2 switch: -plat=
>>>
>>> In HBIDE it was recently implemented as separate option with
>>> {hb_plat}, which uses HB_PLATFORM envvar. I don't know the
>>> reasons, this seems like overcomplicating this matter and
>>> HB_PLATFORM envvar is definitely a legacy solution, so using
>>> -plat= option directly seems to be the optimal solution here.
>>>
>>
>> Please note that "Environments" protocol is designed for this
>> purpose only. I do not know how does hbMK2 works, I simply
>> accepting input from user and pushing forward to hbMK2.
>> May be this is not needed at all, and probably does not, tell me
>> what else I have to remove from hbide.env to make it crystal
>> clear. These are my grasp of the knowledge only which can be
>> limited.
>>
>> -plat=option will be the final result of
>> {hb_pat} win == -plat=win
>> This is only a way to record this entry in "Environments".
>
> You are right, it's not needed in most cases. It's only needed
> if you want to override autodetection, or if you want to create
> cross platform-builds.
>
> I intentionally left out this parameter from most examples,
> to encourage users to drop it. So, IMO at least in default
> .env file, it should only be there if required.
>
> Anyhow I'd suggest to create a simple setting, say {hbmk2}
> which could hold any number of standard hbmk2 options, in
> the form of:
> {hbmk2} -plat=win -comp=bcc -env:<something> <...>
>
> In the future there will be even more options to fine tune
> per environment options (and even now there is, f.e.
> -arch (for CPU) and -build), and it's much easier to offer
> a generic solution which accepts known hbmk2 options, than
> implementing a unique solution for each of them.
>
> BTW, I'd also suggest to use one common syntax in all
> HBIDE related config files. In .env I see ' [ SECTION ]'
> for section header and {<item>}<space><value> for items.
> In .hbi files I see '[ SECTION ]' and <item>=<value>.
> While standard .ini files use: '[Section]' and <item>=<value>.
>
> But again, IMO .hbi files should be much better as simple
> .hbp files, with '#HBIDE' formatted commands for extra HBIDE
> specific information.
>
> I also don't understand [COMMON] section. The default state
> should be what's already setup in the environment when
> starting HBIDE. IMO it's unnecessary to replicate another
> level of default HBIDE.
>
> Finally I don't understand {shell} and {ext}. Why should
> these be specified by users on a per configuration bases?
>
> HBIDE should be able to detect shell, and configure
> everything automatically. No need to add an extra layer
> of abstraction on that IMO.
>
{hbmk2} -plat=whatever -env:<something> <...>
{hbmk2} -comp=bcc
{hbmk2}
So now hbIDE have to deal with these components:
{hbmk2} To be place in .hbp
{shell} To be invoked
{ext} To have {contents} file this extension
{contents} To be placed in shell specific file.
You have simplified my task. Thank you.
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/hbIDE---Requested-Thought-of-Features-Tracking-tp27313368p27315641.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
