Qt-interest Archive, February 2007
concurrent windows and mac development
Message 1 in thread
Hello,
We are currently evaluating QT with the intention of producing Windows
and Mac versions of our software.
We're wondering how people organise their workflow when producing apps
for both platforms. In particular - do you base all your work around a
common QT .pro file and then convert it to Visual Studio and XCode
projects after it's modified? Or, do you keep separate projects for
Visual Studio and XCode, and maintain a .pro file by hand or generate
one in VS and then convert it on the Mac?
Any advice would be great!
Thanks,
Peter Lee
--
[ signature omitted ]
Message 2 in thread
On Wednesday 14 February 2007 14:57, Peter Lee wrote:
> We're wondering how people organise their workflow when producing apps
> for both platforms. In particular - do you base all your work around a
> common QT .pro file and then convert it to Visual Studio and XCode
> projects after it's modified?
This is how we do things at Trolltech. We regenerate Makefiles, vcproj and
Xcode projects from .pro files, always.
Hope that helps ;)
--
[ signature omitted ]
Message 3 in thread
I can second that. Keeping your .pro up-to-date is the best way to
develop your code, but it is somewhat tough to do in practice. If your
.pro file is correct, you don't even need to make a VS or XCode project.
You can just go to the command line and do a:
qmake
make (or nmake on Windows)
And your Qt project builds.
There are a couple downsides to this technique, you can't use either
IDE's debugger or code completion without building one of their projects
and there is not perfect backwards compatibility between the Visual
Studio (or XCode) projects and your .pro file. What I mean by backwards
compatibility is say that you thought your Qt project was complete so
you built an IDE project from it, we'll take XCode as an example. As
you are playing around with it you decide that you need to add two new
files to your project foo.h and foo.cpp, so you just add them in XCode.
You recompile and everything is happy. There isn't any way to get XCode
to update your .pro file for you, you need to remember to do that by
hand, so that when you go back over to Visual Studio you can create a
new .vcproj to get your app to build with the new foo.* files. If you
do this process from Visual Studio and you've installed the Qt
integration stuff, you can create a .pro file from your Visual Studio
project, but the .pro it writes out is very basic, and will not have any
of your platform specific build stuff left in it. It will create a .pro
file that allows you to build what you just built on Windows. You've
already been bitten by this on your other email thread where your .pro
file had a RESOURCES line in there that was specific to Windows.
For me, I've found it best to develop on one platform using its IDE,
debugger, etc. and get the app working correctly under the IDE's build
system. Then do a "make distclean" and then see if I can get it to
build from the .pro file using the command line (qmake and (n)make).
Once I'm sure my .pro file is 100% capable of getting my app to build
perfectly on that platform, I take everything over to the other platform
and build from the command line there. If it isn't perfect, I keep
working on the .pro file until it's perfect on both (or in my case all 3
since I usually build for Windows, Mac OS X, and Linux).
Sean
-----Original Message-----
From: Bradley T Hughes [mailto:bhughes@xxxxxxxxxxxxx]
Sent: Wednesday, February 14, 2007 9:14 AM
To: qt-interest@xxxxxxxxxxxxx
Cc: Peter Lee
Subject: Re: concurrent windows and mac development
On Wednesday 14 February 2007 14:57, Peter Lee wrote:
> We're wondering how people organise their workflow when producing apps
> for both platforms. In particular - do you base all your work around
> a common QT .pro file and then convert it to Visual Studio and XCode
> projects after it's modified?
This is how we do things at Trolltech. We regenerate Makefiles, vcproj
and Xcode projects from .pro files, always.
Hope that helps ;)
--
[ signature omitted ]
Message 4 in thread
Murphy, Sean M. schrieb:
> I can second that. Keeping your .pro up-to-date is the best way to
> develop your code, but it is somewhat tough to do in practice.
Well, I third that. Even when developing for one platform only this
makes sense IMHO; you can always generate the complete project (VS6 in
my case) from a .pro, but not vice versa in a lossless fashion.
(Exceptions prove the rule; some details you have to add by hand to VS6
project files, because of qmake limitations): And I use this cycle quite
often, because qmake generates all moc and other Qt specific steps quite
nicely for me when I add a new dialog/class/ressource/whatever.
.pro is nothing else than a meta project file...
Martin
--
[ signature omitted ]
Message 5 in thread
I'll fourth this. I'm currently working on a project for Windows and
OSX. All our code lives in SVN and the latest and greatest .pro and
.pri files live in there as well and use only relative paths. IDE
projects are generated on the fly and considered disposable, aka they
don't live in SVN. This avoids cross platform problems where you
forgot to add the file to both projects and this way you really take
full advatage of qmake. I generally work on OSX using XCode. I've
setup a trivial script for regenerating an xcode project (so I don't
have to type all that flag stuff to qmake that I can never remember).
If I want to add a file I always do so by modifying one of the .pri
files and regenerate the xcode project. If XCode is open it'll even
notify me the project has changed and ask me to reload it which is
fine. The only pain is that newly created projects in XCode don't take
up the full screen and don't actually show the code in a full pane by
default, or even show a give by default. As for the Windows side, I
opt to do a svn update every day and fresh compile there. Generally I
can get away with doing an incremental build but sometimes qmake
doesn't force recompiling some files if say a tyepdef enum has been
modified in an included header. I'm still looking for a good IDE to
use on Windows. I'm aware of VS but we're bucking the trend and using
gcc on both platforms for our commercial product. It would be great if
qmake could spit out a project for an open source IDE on Windows that
uses gcc as the compiler.
Will Stokes
On 2/14/07, Martin Gebert <Martin.Gebert@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Murphy, Sean M. schrieb:
> > I can second that. Keeping your .pro up-to-date is the best way to
> > develop your code, but it is somewhat tough to do in practice.
>
> Well, I third that. Even when developing for one platform only this
> makes sense IMHO; you can always generate the complete project (VS6 in
> my case) from a .pro, but not vice versa in a lossless fashion.
> (Exceptions prove the rule; some details you have to add by hand to VS6
> project files, because of qmake limitations): And I use this cycle quite
> often, because qmake generates all moc and other Qt specific steps quite
> nicely for me when I add a new dialog/class/ressource/whatever.
> .pro is nothing else than a meta project file...
>
> Martin
>
> --
> To mail me in private, please remove the -NOSPAM- part from the adress
> above.
>
> Ultimate Truths in software development # 7:
> Plan to throw one away. You will anyway.
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 6 in thread
On 2/14/07, Will Stokes <wstokes@xxxxxxxxx> wrote:
> I'll fourth this. I'm currently working on a project for Windows and
> OSX. All our code lives in SVN and the latest and greatest .pro and
> .pri files live in there as well and use only relative paths. IDE
> projects are generated on the fly and considered disposable, aka they
> don't live in SVN. This avoids cross platform problems where you
> forgot to add the file to both projects and this way you really take
> full advatage of qmake.
This is exactly what I do, too.
--
[ signature omitted ]
Message 7 in thread
Hi,
there is an open source IDE for Windows (and Linux and Mac OS X) which uses
gcc - QDevelop ( http://qdevelop.org/ ). That's the one I use, and it is
quite easy to use on different platforms (at least Windows and Linux, I don't
have a Mac) as it does not need to generate some kind of project file out of
the pro file â the pro file /is/ the project file. The only problems I have
are that if QDevelop doesn't understand what I added in the pro file, it just
leaves it away or creates nonsense out of it. The other problem is the
charset, I had to alter the source code to make sure that QDevelop uses UTF-8
on Windows (which is the charset it uses on my Linux system). But beside
that, I think it's a great IDE, including some nice features like adding the
on_<widgetName>_<signalName> functions to your window class. I don't know if
it is usable for big and/or commercial projects, but for my (quite small)
applications it works quite well.
Regards,
Ralf
Am Mittwoch, 14. Februar 2007 17:47:07 schrieb Will Stokes:
> I'll fourth this. I'm currently working on a project for Windows and
> OSX. All our code lives in SVN and the latest and greatest .pro and
> .pri files live in there as well and use only relative paths. IDE
> projects are generated on the fly and considered disposable, aka they
> don't live in SVN. This avoids cross platform problems where you
> forgot to add the file to both projects and this way you really take
> full advatage of qmake. I generally work on OSX using XCode. I've
> setup a trivial script for regenerating an xcode project (so I don't
> have to type all that flag stuff to qmake that I can never remember).
> If I want to add a file I always do so by modifying one of the .pri
> files and regenerate the xcode project. If XCode is open it'll even
> notify me the project has changed and ask me to reload it which is
> fine. The only pain is that newly created projects in XCode don't take
> up the full screen and don't actually show the code in a full pane by
> default, or even show a give by default. As for the Windows side, I
> opt to do a svn update every day and fresh compile there. Generally I
> can get away with doing an incremental build but sometimes qmake
> doesn't force recompiling some files if say a tyepdef enum has been
> modified in an included header. I'm still looking for a good IDE to
> use on Windows. I'm aware of VS but we're bucking the trend and using
> gcc on both platforms for our commercial product. It would be great if
> qmake could spit out a project for an open source IDE on Windows that
> uses gcc as the compiler.
>
> Will Stokes
>
> On 2/14/07, Martin Gebert <Martin.Gebert@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > Murphy, Sean M. schrieb:
> > > I can second that. Keeping your .pro up-to-date is the best way to
> > > develop your code, but it is somewhat tough to do in practice.
> >
> > Well, I third that. Even when developing for one platform only this
> > makes sense IMHO; you can always generate the complete project (VS6 in
> > my case) from a .pro, but not vice versa in a lossless fashion.
> > (Exceptions prove the rule; some details you have to add by hand to VS6
> > project files, because of qmake limitations): And I use this cycle quite
> > often, because qmake generates all moc and other Qt specific steps quite
> > nicely for me when I add a new dialog/class/ressource/whatever.
> > .pro is nothing else than a meta project file...
> >
> > Martin
> >
> > --
> > To mail me in private, please remove the -NOSPAM- part from the adress
> > above.
> >
> > Ultimate Truths in software development # 7:
> > Plan to throw one away. You will anyway.
> >
> > --
> > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> > "unsubscribe" in the subject or the body. List archive and information:
> > http://lists.trolltech.com/qt-interest/
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 8 in thread
> there is an open source IDE for Windows (and Linux and Mac OS
> X) which uses gcc - QDevelop ( http://qdevelop.org/ ). That's
> the one I use, and it is quite easy to use on different
> platforms (at least Windows and Linux, I don't have a Mac) as
> it does not need to generate some kind of project file out of
> the pro file - the pro file /is/ the project file. The only
> problems I have are that if QDevelop doesn't understand what
> I added in the pro file, it just leaves it away or creates
> nonsense out of it. The other problem is the charset, I had
> to alter the source code to make sure that QDevelop uses
> UTF-8 on Windows (which is the charset it uses on my Linux
> system). But beside that, I think it's a great IDE, including
> some nice features like adding the
> on_<widgetName>_<signalName> functions to your window class.
> I don't know if it is usable for big and/or commercial
> projects, but for my (quite small) applications it works quite well.
I had forgotten about this, every time someone brings it up on the list
I always mean to check it out, and then I always promptly forget to
actually check it out! We'll see how well it works this time...
How well does the debugger work on this, especially cross-platform?
That's the only thing that I really prefer to use Visual Studio for is
their debugger. The one with XCode (which I believe is gdb?) seems very
slow to me, whereas the one in Visual Studio seems extremely fast.
Sean
--
[ signature omitted ]
Message 9 in thread
Hi,
> I had forgotten about this, every time someone brings it up on the list
> I always mean to check it out, and then I always promptly forget to
> actually check it out! We'll see how well it works this time...
let's see ;-)
> How well does the debugger work on this, especially cross-platform?
> That's the only thing that I really prefer to use Visual Studio for is
> their debugger. The one with XCode (which I believe is gdb?) seems very
> slow to me, whereas the one in Visual Studio seems extremely fast.
QDevelop uses gdb, and unfortunately it really is quite slow on my Linux
system (that's another point of criticism I forgot to mention because I
rarely needed it till now). I'm not sure weather the IDE , gdb or a problem
with my system is the reason for that. I don't have gdb installed on Windows,
but another IDE with gdb (Lazarus, an IDE for free pascal we use at school)
uses gdb on Winodws and it seems to work quite well. I don't know much about
gdb, though, and I don't know about open source alternatives. The debugger in
Borland C++ was much faster than gdb (I've never used Visual Studio...)
Regards,
Ralf
--
[ signature omitted ]
Message 10 in thread
I'm aware of qdevelop or qide, whichever it goes by right now, but so
far it does not support more complicated qmake projects (aka ones that
use .pri files). I also had a little troble getting code completion
working on Windows.
-Will
On 2/14/07, Ralf Jung <ralfjung-qt@xxxxxxxxxxxxxx> wrote:
> Hi,
>
> > I had forgotten about this, every time someone brings it up on the list
> > I always mean to check it out, and then I always promptly forget to
> > actually check it out! We'll see how well it works this time...
>
> let's see ;-)
>
> > How well does the debugger work on this, especially cross-platform?
> > That's the only thing that I really prefer to use Visual Studio for is
> > their debugger. The one with XCode (which I believe is gdb?) seems very
> > slow to me, whereas the one in Visual Studio seems extremely fast.
>
> QDevelop uses gdb, and unfortunately it really is quite slow on my Linux
> system (that's another point of criticism I forgot to mention because I
> rarely needed it till now). I'm not sure weather the IDE , gdb or a problem
> with my system is the reason for that. I don't have gdb installed on Windows,
> but another IDE with gdb (Lazarus, an IDE for free pascal we use at school)
> uses gdb on Winodws and it seems to work quite well. I don't know much about
> gdb, though, and I don't know about open source alternatives. The debugger in
> Borland C++ was much faster than gdb (I've never used Visual Studio...)
>
> Regards,
> Ralf
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 11 in thread
Thanks to all for the responses - much appreciated! We'll keep playing....
Regards,
Peter Lee
--
[ signature omitted ]
