>> 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.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
