>> Maybe the only generic way to integrate such needs with
>> hbmk2, is to create an separate external tool (non-hbmk2)
>> and call it as part of of 'preprocessing'. So what needs
>> to be done in hbmk2 is to allow to run external tools at
>> specific stages of the process, f.e. 'preflight',
>> 'postflight', 'prelink'.
>>
>> I hope to hear ideas on the specifics of such
>> implementation.
>>
>
> Sounds good. But I am at a loss to understand what type of
> tool it could be. You have embedded moc_ creation in Harbour
> build system nicely, rather very nicely.
It's a local extension to HBQT, it's not embedded in core
in any ways.
Note however that GNU Make is a much more generic tool
than hbmk2, with different goals.
>> Though until this is implemented I'd suggest to do the
>> 'moc' creation as part of the generator tool.
>>
>
> I will think but probably it is not possible due the fact
> that at the time of generation the path_to_headers is not
> known neither cared. It will increase the complexity IMO.
Complexity is unavoidable, the only question is where
to put it.
If hbmk2 can call an external tool with a preconfigured
list of input files and that external tool can convert
these to whatever else input files, we're done.
>>> -incpath=${QT_WITH_SCINTILLA}/qt // where QScintilla headers
>>> are
>>
>> In the context of Harbour, QT_WITH_SCINTILLA
>> should be named HB_WITH_QSCINTILLA.
>>
>
> HB_WITH_QSCINTILLA seems more appropriate, I will change.
Thank you.
>> Another (maybe obvious) rule is to strictly avoid
>> any qscintilla references in HBQT generated sources.
>
> Probably this is the most difficult part and probably not viable.
>
> hbqt_par_Q* - hbqt.h
Why cannot QSCINTILLA wrapper sources reference
hbqt.h?
And why do HBQT files need to reference QSCINTILLA
files? If they do, something is wrong, if they
don't, you don't have to mix them.
Pls keep separate components cleanly separated.
It's a basic rule in Harbour.
> These must have to go inside hbqt.h otherwise we will end up
> replication because the other members are referenced from within
> all external lib wrappers anyway. i.e., QFont, QColor, etc.
>
> extern QT_G_FUNC( hbqt_gcRelease_Q* ) - hbqt_garbage.cpp
> extern void * hbqt_gcAllocate_Q*l( void * pObj, bool bNew ) -
> hbqt_garbage.cpp
>
> These can be somehow isolated in local file like
> hbqt_garbage_qscintilla.cpp.
> Other implementation could be to create a composite file clubbing _par_
> and _gcAllocate_, _gcRelease_ together in the local folder.
I cannot see the nature of complication. There
is no theory which would explain why separate
components need to have mashed-together parts
in order to work.
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
