Harbour nightly binary with QT
Viktor Szakáts
Starting tonight (GMT+1) the Harbour nighly package for Windows
contains everything (*) required to create QT apps with Harbour.
IOW you don't need to install QT package anymore to create Harbour
QT apps.
(*) QT resource and .ui compiler, QT runtime .dlls (QtCore, QtGui,
QtNetwork, QtUiTools) and matching implibs for mingw, to be precise.
Viktor
francesco perillo
please specify which Qt version are you using...
I'd like to use Qt 4.7 in order to use QLineEdit:setPlaceholderText()
but if I'm not wrong, hbqt is aligned to 4.5.... is it right ?
Viktor Szakáts
> please specify which Qt version are you using...
I have 4.7 installed on my local system. The nighly
contains the version I used at the time when I assembled
the build environment package, which means it's 4.6.3.
[ BTW, it's be nice of you if you could find some free
time to update it to 4.7. ]
> I'd like to use Qt 4.7 in order to use QLineEdit:setPlaceholderText()
> but if I'm not wrong, hbqt is aligned to 4.5.... is it right ?
It's better to phrase it so that HBQT doesn't yet support
any 4.6/4.7 specific features.
This has been discussed a few times, and there is no problem
in adding support for such features as long as some basic
rules are followed. These rules are:
1) Guard any feature with:
#if QT_VERSION >= 0x040n00
#else
#endif
2) Provide dummy logic for newer features when
compiled against older QT version. Which means
that each public symbol has to be defined and
return permanent error (no RTE) when compiled
against older QT version.
So it will look something like this in practice:
---
HB_FUNC( QFluxionCondensatorStart )
{
#if QT_VERSION >= 0x040700
hb_retl( QFluxionCondensatorStart( hb_parni( 1 ) ) );
#else
hb_retl( HB_FALSE );
#endif
}
---
Viktor
Massimo Belgrano
compiler for 64 bit,windows Mobile,symbian
The binary distrubution will be ready to be used for cross compile for
all platfom this platform using
hbmk2 hello.prg -platform=win -compiler=mingw64
hbmk2 hello.prg -platform=wce -compiler=mingwarm
hbmk2 hello.prg -platforms=symbian -compiler=gcc arm
..
MinGW-64 http://sourceforge.net/projects/mingw-w64/files/ installed in
C:\harbour\comp\mingw64
MinGW CEGCC [win, *nix, free, open-source]
http://cegcc.sourceforge.net/ installed in C:\harbour\comp\mingwarm
with http://cygwin.com
Symbian SDKs
http://www.forum.nokia.com/info/sw.nokia.com/id/ec866fab-4b76-49f6-b5a5-af0631419e9c/S60_All_in_One_SDKs.html
2010/10/20 Viktor Szakáts <harbo...@syenar.hu>:
--
Massimo Belgrano
alcisoft
>compiler for 64 bit,windows Mobile,symbian
>The binary distrubution will be ready to be used for cross compile for
>all platfom this platform using
>hbmk2 hello.prg -platform=win -compiler=mingw64
>hbmk2 hello.prg -platform=wce -compiler=mingwarm
>hbmk2 hello.prg -platforms=symbian -compiler=gcc arm
+1
Regards
francesco perillo
>> please specify which Qt version are you using...
>
> I have 4.7 installed on my local system. The nighly
> contains the version I used at the time when I assembled
> the build environment package, which means it's 4.6.3.
>
> [ BTW, it's be nice of you if you could find some free
> time to update it to 4.7. ]
I know that some mingw versions don't work with Qt 4.7.... I imagine
that the one included in the nbp (nightly build package) is ok....
I didn't check on the build machine yet but I imagine I should install
Qt 4.7 on a pc and then move some directories on the build machine...
> It's better to phrase it so that HBQT doesn't yet support
> any 4.6/4.7 specific features.
>
> This has been discussed a few times, and there is no problem
> in adding support for such features as long as some basic
> rules are followed. These rules are:
> 1) Guard any feature with:
> #if QT_VERSION >= 0x040n00
> #else
> #endif
> 2) Provide dummy logic for newer features when
> compiled against older QT version. Which means
> that each public symbol has to be defined and
> return permanent error (no RTE) when compiled
> against older QT version.
it seems a perfect job for qtgen....
I don't agree with you on point 2.
scenario 1:
prg code based on qt4.7 but compiled with hbqt supporting 4.5 (imagine
a not updated compiler sitting around on a workstation): it will not
work since it will RTE on non-existing methods
scenario 2:
harbour compiled against 4.7, hbqt 4.7 but .exe run on "client" pc
with lower level qt... it should GPF as soon as a 4.7 c++ method is
invoked. If we are kind to developers we can put an if (not a #if)
around the 4.6 and 4.7 calls in order to give a RTE with a unsupported
message
scenario 2 is possible when for example you send a new version to a
client, he puts in a new directory, run it and different qt dll are in
the path
Other scenarios are possible but they will mean that programmer has
mixed up stuff very badly...
> HB_FUNC( QFluxionCondensatorStart )
> {
> #if QT_VERSION >= 0x040700
> hb_retl( QFluxionCondensatorStart( hb_parni( 1 ) ) );
> #else
> hb_retl( HB_FALSE );
> #endif
> }
This will give programmer a false sensation that the program would
work... and it won't...
To me, in TQFluxion.prg, a #if should protect the METHOD
definition... hbqt compiled against 4.5 ? no 4.6 or 4.7 method
available so get a RTE !
I will then add a
#if QT_VERSION >= 0x040700
INIT PROCEDURE requireQt47()
if Qt.version() < 4.7
RTE( "you need qt 4.7 or superior")
endif
#endif
( I don't remember if harbour supports that #if >, but I saw that it
is possible to simulate a INIT PROCEDURE all at c level)
and of course in cpp code
#if QT_VERSION >= 0x040700
HB_FUNC( QFluxionCondensatorStart )
{
hb_retl( QFluxionCondensatorStart( hb_parni( 1 ) ) );
}
... other 4.7 methods
#endif
Viktor Szakáts
> compiler for 64 bit,windows Mobile,symbian
> The binary distrubution will be ready to be used for cross compile for
> all platfom this platform using
It's technically possible and it was done for final releases. Same
can be done for nightly. The cost is: Requires new tools installed
on the build machine, needs testing, requires much more time to
build each day, and it will make the download size considerably larger.
Another thing to note is that mingw64 is still not fully mature, so
it needs much more frequent upgrades than mingw.
> hbmk2 hello.prg -platform=win -compiler=mingw64
> hbmk2 hello.prg -platform=wce -compiler=mingwarm
> hbmk2 hello.prg -platforms=symbian -compiler=gcc arm
Symbian is currently only an experiment of proof of concept.
If someone is interested in that, she should first make
tests with current state, report results and reiterate the whole
process. So far ZERO feedback came regarding Symbian
so it doesn't seem like something important to deal with.
[ BTW would it hurt say "thanks" sometimes instead of
asking for more? ]
Viktor
Viktor Szakáts
>> time to update it to 4.7. ]
>
> I know that some mingw versions don't work with Qt 4.7.... I imagine
> that the one included in the nbp (nightly build package) is ok....
I haven't heard about such information. 4.6 and 4.7 both
requires dwarf mingw build, which is already in the nightly.
On my system the same mingw works perfectly with 4.7.
Maybe you mean the buggy QT installation message. This
has been cleared in that thread.
> I didn't check on the build machine yet but I imagine I should install
> Qt 4.7 on a pc and then move some directories on the build machine...
You can install QT directly into /3rd/qt over the current
version. Make sure to empty the directory first, and also
to install the QT package listed INSTALL.
> I don't agree with you on point 2.
> scenario 1:
> prg code based on qt4.7 but compiled with hbqt supporting 4.5 (imagine
> a not updated compiler sitting around on a workstation): it will not
> work since it will RTE on non-existing methods
It will branch to default case. Apps should count on that.
It's easier to count on it then putting BEGIN SEQUENCE
everywhere. App can also query the QT version and act
accordingly. Control is in app developers hands.
> scenario 2:
> harbour compiled against 4.7, hbqt 4.7 but .exe run on "client" pc
> with lower level qt... it should GPF as soon as a 4.7 c++ method is
> invoked. If we are kind to developers we can put an if (not a #if)
This is different problem. Here the .dlls don't match the requirements
of the application, posed by the QT version that app was _built_ against
in the first place. It's the job of operating system and QT to protect
against it. I'm sure QT thought of that and it won't allow you to load
QT .dlls which are not binary compatible with the version used at
build time. But, even .prg programmer can add such protection by
checking "QVERSION() == QT_VERSION()" at app startup.
> around the 4.6 and 4.7 calls in order to give a RTE with a unsupported
> message
I don't agree with an RTE here because it's much more
difficult to handle it. Most programmer will not even expect
RTE to come from seemingly innocent method calls. Which
means they won't be handled and app will RTE in "random"
places. If we go with my suggestion, app will continue to
work, but with potentially reduced functionality.
BTW we already use proposed method in _all_ Harbour contribs.
> scenario 2 is possible when for example you send a new version to a
> client, he puts in a new directory, run it and different qt dll are in
> the path
That's unrelated to this problem. It can happen even now when
you ship 4.5 QT app and .dlls are 4.7. It's called .dll hell and we
cannot solve it on HBQT level.
> This will give programmer a false sensation that the program would
> work... and it won't...
No, it will signal an error (or it just won't do the requested
operation).
> To me, in TQFluxion.prg, a #if should protect the METHOD
> definition... hbqt compiled against 4.5 ? no 4.6 or 4.7 method
> available so get a RTE !
I don't agree. Forcing an RTE in just too much here.
> I will then add a
> #if QT_VERSION >= 0x040700
> INIT PROCEDURE requireQt47()
> if Qt.version() < 4.7
> RTE( "you need qt 4.7 or superior")
> endif
> #endif
This is app programmers' responsibility and such
code can be added if she decides that the app
is unable to work under given QT version.
> #if QT_VERSION >= 0x040700
> HB_FUNC( QFluxionCondensatorStart )
> {
> hb_retl( QFluxionCondensatorStart( hb_parni( 1 ) ) );
> }
> ... other 4.7 methods
> #endif
No, this is wrong, as it will create link errors
for .prg programmers, so we tie .prg apps to
QT versions. So .prg programmers will in turn
require to use such #if QT_VERSION >= ...
guards in .prg level code, and my goal is to avoid
that ugliness. The point of coding in .prg is
to avoid such low-level complexities.
Viktor
Massimo Belgrano
Thanks for harbour to Viktor and all other developer
thanks,thanks,thanks
I think that harbour will be very usefull for all mobile device platform
2010/10/20 Viktor Szakáts <harbo...@syenar.hu>:
>>
> [ BTW would it hurt say "thanks" sometimes instead of
> asking for more? ]
>
> Viktor
>
--
Massimo Belgrano
francesco perillo
I still don't agree with you. Please read the whole message before
starting to type your answer.
In next hours I will install Qt 4.7 on all my pcs.
Imagine that hbqt is updated with all new Qt 4.7 classes, methods,
signals and events. I compile harbour and hbqt. I update my "client"
program to use that shiny brand-new QLineEdit:setPlaceholderText()
feature. Everything works perfectly.
day 1:
I have at least 3 harbours on my pcs, one is stable, one is svn, one
is my branch of svn.
I don't realize that I'm now pointing to stable harbour, hbqt aligned
to 4.5, my qt can be any release: I compile my program, I run it and
it WILL rte since setPlacheholderText is not present in TQLineEdit.prg
!
day 2:
I set up a brand new i7 pc, I install all the bits but I wrongly
install qt 4.5 instead on 4.7. My fault. I copy svn harbour and
setPlaceholderText is now present in TQLineEdit.prg. According to your
idea, we should run setPlaceholderText but do nothing.. I will just
see in the form that the text is not shown....
Ok, this can be acceptable for such a gui thing...
Let's see what happens when I use different features of hbqt leveled
at 4.7 but with Qt 4.5 in my "client" code:
classes: errors at link time, the 4.7 class doesn't exist in 4.5
signals: hbqt_hbqslots.cpp code will RTE since Qt will refuse to
connect not existing signals
events: I will never get that event since Qt doesn't generate it, so
"something" will not work as expected
methods: hbqt will do nothing and return .F. .... It can be really
really dangerous and provoke possible data loss !!!!
o:setPlaceholderText( "test")
? o:PlaceholderText() // prints .F.
So I will have a very dangerous situation where the program seems to
work but it won't completely !
Day 3:
with PATH/HB_WITH_QT set to 4.7 I run a exe built for 4.5.... 99.99%
it will work since qt is quite good at upwards compatibility. I read
some message about changes but I remember that they were not so
drastic (I may remember wrongly).
So may idea is that we should "help" developers and users to avoid
version clashes... I think it can be done "quite easily" and it will
avoid support request "I call method XYZ, I expect a string but get a
.F.", or "Why do I get a rte with message not existant on .F.?"
I ask you to please rethink a moment on the matter
thanks
Viktor Szakáts
> starting to type your answer.
I did, but sorry, this has come up several times and I just
don't have the time to refight that with everyone individually
and reiterating again and again on all the details, for each
one of the contribs.
> Imagine that hbqt is updated with all new Qt 4.7 classes, methods,
> signals and events. I compile harbour and hbqt. I update my "client"
> program to use that shiny brand-new QLineEdit:setPlaceholderText()
> feature. Everything works perfectly.
>
> day 1:
> I have at least 3 harbours on my pcs, one is stable, one is svn, one
> is my branch of svn.
> I don't realize that I'm now pointing to stable harbour, hbqt aligned
> to 4.5, my qt can be any release: I compile my program, I run it and
> it WILL rte since setPlacheholderText is not present in TQLineEdit.prg
> !
This is wrong behavior. In this example if you
require setPlaceholderText and without it your
app cannot be used, so make sure to check
for proper version at app startup, so instead of
a meaningless RTE which may or may not
appear at testing time, you get a proper screen
message. Even better, make sure to build with
the proper QT.
In above scenario to plan to rely on your app
to have enough luck to run into a problematic
function and RTE for you, while you could avoid
the whole problem with 3 lines of code.
> day 2:
> I set up a brand new i7 pc, I install all the bits but I wrongly
> install qt 4.5 instead on 4.7. My fault. I copy svn harbour and
> setPlaceholderText is now present in TQLineEdit.prg. According to your
> idea, we should run setPlaceholderText but do nothing.. I will just
> see in the form that the text is not shown....
> Ok, this can be acceptable for such a gui thing...
> Let's see what happens when I use different features of hbqt leveled
> at 4.7 but with Qt 4.5 in my "client" code:
> classes: errors at link time, the 4.7 class doesn't exist in 4.5
> signals: hbqt_hbqslots.cpp code will RTE since Qt will refuse to
> connect not existing signals
> events: I will never get that event since Qt doesn't generate it, so
> "something" will not work as expected
> methods: hbqt will do nothing and return .F. .... It can be really
> really dangerous and provoke possible data loss !!!!
So protect against it. Why do you want to punish
all users with random RTEs, just because you cannot
sort out your version requirements?
> So I will have a very dangerous situation where the program seems to
> work but it won't completely !
Yes, and when doing RTE you will have the dangerous
situation that the program crashes at a random point
causing other sorts of problems (f.e. inconsistent database).
> Day 3:
> with PATH/HB_WITH_QT set to 4.7 I run a exe built for 4.5.... 99.99%
> it will work since qt is quite good at upwards compatibility. I read
> some message about changes but I remember that they were not so
> drastic (I may remember wrongly).
>
> So may idea is that we should "help" developers and users to avoid
> version clashes... I think it can be done "quite easily" and it will
> avoid support request "I call method XYZ, I expect a string but get a
> .F.", or "Why do I get a rte with message not existant on .F.?"
Well, you never return .F. when normally a string should
be returned. You always return a dummy or error case if
such exists.
I don't agree that RTEs are a way to help developers
to 3rd party lib version problems.
The only thing to consider here is to not include such methods
at all in HBQT, but in this version both lib level and app level
code will soon become an ugly mess with lots of guards
and several 3rd party lib version dependent sub-branches,
since the whole problem has just been shoved to users,
instead of Harbour developers taking care of it.
I'd like to avoid such mess in .prg code by all means.
Also in such case, we'd need a compile time QT_VERSION
macro available on the .prg level, even the management
of such macro is problematic, since it needs to be put
in a dynamically generated header. Then you'll have to
test your code against each version to ensure that the .prg
code is compatible with every QT version... and it goes
on and on.
[ Look at hbcurl.c for an example of what I'm talking about,
and think of that mess replicated on a supposedly simple
and intuitive .prg program. ]
> I ask you to please rethink a moment on the matter
I've thought about this for quite long and overall the current
system seems to work quite well, and I just cannot see
anything special in case of HBQT which could make it
an exception. BTW, we've been through most solutions
(even yours) in the past, and at least to me practice has
shown that it is the best to handle it the current way.
Viktor
francesco perillo
I will add a check of installed qt libraries and hbqt at program start
and abort with a message if they are too low version.