[Interest] qmake: questions regarding huge projects
I would like to ask for some expert tutorial or some hints for using qmake with huge projects. What is huge? Our complete package consists of 50 applications build based on 100 libraries (organized in modules and units). On Windows, we use a Visual Studio solution file containing 250 projects, the application projects use Properties / Framework and References to refer to those libraries needed for this specific application. Now I would like to setup build system on Linux for a part of our package. Currently we use a own Makefile based approach that has some disadvantages. What I would like to have is a solution based on qmake (ideally) that satisfies these conditions: - if an application A depends on a library B, it is sufficient to define this only once (needs), not multiple times (depends on + build after + link with + ...) - if I build a single application, only those libraries are build that are needed for this application - if the whole package is build, each library is ideally built only once - build steps run in parallel on multiple cores Could anyone of you point me to examples or docs that might help me to find this solution? Best Regards / Mit freundlichen Grüßen Rainer Wiesenfarth -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Hans-Jürgen Gebauer smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qmake: questions regarding huge projects
On Fri, Apr 19, 2013 at 12:18 PM, Rainer Wiesenfarth rainer_wiesenfa...@trimble.com wrote: I would like to ask for some expert tutorial or some hints for using qmake with huge projects. What is huge? Our complete package consists of 50 applications build based on 100 libraries (organized in modules and units). On Windows, we use a Visual Studio solution file containing 250 projects, the application projects use Properties / Framework and References to refer to those libraries needed for this specific application. Now I would like to setup build system on Linux for a part of our package. Currently we use a own Makefile based approach that has some disadvantages. What I would like to have is a solution based on qmake (ideally) that satisfies these conditions: - if an application A depends on a library B, it is sufficient to define this only once (needs), not multiple times (depends on + build after + link with + ...) The depends qmake keyword should take care of this. - if I build a single application, only those libraries are build that are needed for this application The single application's pro file should have all the libs it depends on, listed in the depends variable. - if the whole package is build, each library is ideally built only once The whole package's pro file can contain subprojects. Subprojects can be pointed to by the SUBDIRs qmake template. So building the complete project then comes down to individually building these sub-projects. In order to ensure libraries are not re-built multiple times (libs can be built directly as they'll be part of the SUBDIRs OR they can be built because of a dependency), have a common build dir where the generated object files for all the sub-projects are kept. Make would take care then of not building the libs again if they're already built. - build steps run in parallel on multiple cores qmake takes care of this (I think), i.e it'll find out the number of cores and supply the relevant number to make's -j option. HTH, -mandeep Could anyone of you point me to examples or docs that might help me to find this solution? Best Regards / Mit freundlichen Grüßen Rainer Wiesenfarth -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/**imaging/ http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Hans-Jürgen Gebauer ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qmake: questions regarding huge projects
Hi, On Fri, Apr 19, 2013 at 10:35 AM, Mandeep Sandhu mandeepsandhu@gmail.com wrote: On Fri, Apr 19, 2013 at 12:18 PM, Rainer Wiesenfarth rainer_wiesenfa...@trimble.com wrote: I would like to ask for some expert tutorial or some hints for using qmake with huge projects. What is huge? Our complete package consists of 50 applications build based on 100 libraries (organized in modules and units). On Windows, we use a Visual Studio solution file containing 250 projects, the application projects use Properties / Framework and References to refer to those libraries needed for this specific application. Now I would like to setup build system on Linux for a part of our package. Currently we use a own Makefile based approach that has some disadvantages. What I would like to have is a solution based on qmake (ideally) that satisfies these conditions: - if an application A depends on a library B, it is sufficient to define this only once (needs), not multiple times (depends on + build after + link with + ...) The depends qmake keyword should take care of this. This probably refers to the .depends-extra-flag for SUBDIRS elements. In addition this only works for Makefile generators, i.e. not with visual studio according to the documentation. See http://qt-project.org/doc/qt-4.8/qmake-variable-reference.html#subdirs - build steps run in parallel on multiple cores qmake takes care of this (I think), i.e it'll find out the number of cores and supply the relevant number to make's -j option. No, qmake does not take care of this as qmake is not a buildsystem itself (rather a buildsystem generator, it generates Makefiles, VS files etc.). But of course a user can run make -j3 himself. make does not have any support for automatic parallel build based on the number of cores. Andreas ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qmake: questions regarding huge projects
Am 19.04.2013 10:35, schrieb Mandeep Sandhu: [...] The single application's pro file should have all the libs it depends on, listed in the depends variable. Thanks for your answer, I will take a look at depends - I did not yet read in depth about its meaning and impact. Best Regards / Mit freundlichen Grüßen Rainer Wiesenfarth -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Hans-Jürgen Gebauer smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qmake: questions regarding huge projects
Am 19.04.2013 11:25, schrieb Bo Thorsen: Sounds to me like you want to switch to cmake instead. That has a lot better support for dependencies between subprojects than qmake. And for a project of this size, I would expect you have some fancy build stuff in there as well, and qmake is usually too simple for it. Hi Bo, well, I know about cmake, but was going for something less cryptic... :-) We have some fancy build stuff (f2c, versioning, ...), but I was hoping to get it done with qmake, _because_ it is simple. Probably I have to dig through QMake Variables and QMake Functions to find the features I need. Best Regards / Mit freundlichen Grüßen Rainer Wiesenfarth -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Hans-Jürgen Gebauer smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qmake: questions regarding huge projects
qmake takes care of this (I think), i.e it'll find out the number of cores and supply the relevant number to make's -j option. No, qmake does not take care of this as qmake is not a buildsystem itself (rather a buildsystem generator, it generates Makefiles, VS files etc.). But of course a user can run make -j3 himself. make does not have any support for automatic parallel build based on the number of cores. Yes, you're right. I guess one has to figure this out outside the build system. You can probably pass the number of jobs to run via the MAKEFLAGS variable. HTH, -mandeep Andreas ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qmake: questions regarding huge projects
Den 19-04-2013 12:29, Rainer Wiesenfarth skrev: Am 19.04.2013 11:25, schrieb Bo Thorsen: Sounds to me like you want to switch to cmake instead. That has a lot better support for dependencies between subprojects than qmake. And for a project of this size, I would expect you have some fancy build stuff in there as well, and qmake is usually too simple for it. Hi Bo, well, I know about cmake, but was going for something less cryptic... :-) We have some fancy build stuff (f2c, versioning, ...), but I was hoping to get it done with qmake, _because_ it is simple. I know, but when you have a complicated build process, a simple tool just doesn't cut it. Probably I have to dig through QMake Variables and QMake Functions to find the features I need. I'll bet you that you won't be able to, unfortunately. On the bright side: Once you have a good cmake build in place, you will have the visual studio build done with the same system as Linux. Having two different build systems is *not* a good idea. Bo. -- Bo Thorsen, European Qt Manager, Integrated Computer Solutions ICS - Delivering World-Class Applications for Embedded Mobile Devices http://ics.com/services ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Re: qmake: questions regarding huge projects
On Friday, 19 April 2013 12:29:04 CEST, Rainer Wiesenfarth wrote: well, I know about cmake, but was going for something less cryptic... :-) One of my biggest disappointments with qmake was that it just did not set up proper dependencies between the static libs I build and the targets which use it. Either I was missing something obvious, or qmake is really, really stupid. Yes, you can add a ton of macros on top of it to make it sane, but is that really what you want to do? Further details at [1]. (It looks like I was wrong on the first topic I complained in there -- it seems that it is actually possible to produce multiple binaries from a bunch of .cpp files in the same directory. At least I've seen some qmake hackery doing that. You still need an extra .pro file for each target, though, at least as far as I know.) With kind regards, Jan [1] http://jkt.flaska.net/blog/QMake_Static_Libraries__Unit_Tests_and_Much_Headache__or_the_Tale_of_How_Trojita_Changed_the_Build_System_from_CMake_to_QMake.html -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qmake: questions regarding huge projects
Den 19-04-2013 13:36, Jan Kundrát skrev: On Friday, 19 April 2013 12:29:04 CEST, Rainer Wiesenfarth wrote: well, I know about cmake, but was going for something less cryptic... :-) One of my biggest disappointments with qmake was that it just did not set up proper dependencies between the static libs I build and the targets which use it. Either I was missing something obvious, or qmake is really, really stupid. Yes, you can add a ton of macros on top of it to make it sane, but is that really what you want to do? Further details at [1]. (It looks like I was wrong on the first topic I complained in there -- it seems that it is actually possible to produce multiple binaries from a bunch of .cpp files in the same directory. At least I've seen some qmake hackery doing that. You still need an extra .pro file for each target, though, at least as far as I know.) In a directory with two projects, you can place two .pro files and use a SUBDIRS to include the two .pro files. Not a difficult hack :) SUBDIRS treat a directory and a .pro file entry pretty much the same way. Bo. -- Bo Thorsen, European Qt Manager, Integrated Computer Solutions ICS - Delivering World-Class Applications for Embedded Mobile Devices http://ics.com/services ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qmake: questions regarding huge projects
Am 19.04.2013 13:36, schrieb Bo Thorsen: On the bright side: Once you have a good cmake build in place, you will have the visual studio build done with the same system as Linux. Having two different build systems is *not* a good idea. I know, but we will definitely have two build systems - unless there is a cross-platform MSBuild / devenv ... :-) Our almost exclusive development environment is and will remain Visual Studio, so any initial changes to projects or solutions are done inside VS. Building the software on Linux is done far less often, so re-adjusting the build files is a tolerated approach. Best Regards / Mit freundlichen Grüßen Rainer Wiesenfarth -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Hans-Jürgen Gebauer smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qmake: questions regarding huge projects
Hi Rainer, as other members already stated out qmake has some limits - but: These can be hacked ;-) We (our company) spent much time to discover different build systems and approaches - where CMake was the most complicated and most work intensive solution. So we decided to use the long term and on all Qt platforms available qmake and to use ONLY .pro files - even in Visual Studio 2005-2012 (thanks to the great VSAddin this can be simply done by an export/import button to save/load .pro files). + qmake .pro files are fully supported by VisualStudio, Eclipse and QtCreator + .pro files are simple and have a small footprint + extensible thanks to integrated (very simple) scripting functions and import of external files (.pri) + automatic dependenies for libs + version handling and execution of unit tests, pre- and post-build commands + can generate resource files (and with own commands even sources) + with a few tricks can used to automatically check out and include other dirs / libs / modules + automatically execute unit tests, create versioned file names, copy build files etc. In our company we use qmake with some self written qmake functions (inside .pri include files) to run a hughe build environment with fully automatic dependencies and execution of unit tests directly after compile. Means: 591 .pro files (libs + apps + subdirs) and 23 .pri files (includes) For a simple example how to automate things with qmake you can see an old blogpost here: http://www.3dh.de/3dh.de/2006/12/19/qt-automated-unit-tests-with-qmake/ If you're interested, I can give you more details... And yes: QMake is a really limited tool and will be replaced in the future by QBS or some other system - but: For production environments it's a currently available and reliable tool, working fine under Windows (in VC++ with the VSAddin) and Linux. QMake offers me some possibilities, VC++ cannot provide out of the box and thus is the currently favorite tool to simply work with ONE .pro file for ALL platforms. Getting CMake to this state is possible - but costs so much time and work, that no one of my devs wants to use it. ciao, Chris___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qmake: questions regarding huge projects
QMake and CMake both generate what your final build environment need, whether it is Makefiles for GNUmake, nmake, or VS projects. So you can have one project definition set that generates for all build environments. I highly recommend it. I'd further advise that you probably want to use CMake instead of QMake - especially if you know you have implementation files by the same name in different places that could potentially be linked to the same executable either directly or through a static library (e.g. *.a on Linux). This is probably the only short-coming of qmake I've actually come across. CMake doesn't have that issue. For example, I have a project now where I am refactoring some code - the original class's filename was imRunScreen.cpp; and the new class's filename is imRunScreen2.cpp; even if I put it in a sub-directory I still cannot use the same file name. Now, may be this got changed for Qt5; I can't say as I haven't tried to do that kind of thing with Qt5's QMake yet. Regardless you'd probably be better off going the CMake route any way. $0.02 Ben From: Rainer Wiesenfarth rainer_wiesenfa...@trimble.com To: Cc: interest@qt-project.org Sent: Friday, April 19, 2013 8:33 AM Subject: Re: [Interest] qmake: questions regarding huge projects Am 19.04.2013 13:36, schrieb Bo Thorsen: On the bright side: Once you have a good cmake build in place, you will have the visual studio build done with the same system as Linux. Having two different build systems is *not* a good idea. I know, but we will definitely have two build systems - unless there is a cross-platform MSBuild / devenv ... :-) Our almost exclusive development environment is and will remain Visual Studio, so any initial changes to projects or solutions are done inside VS. Building the software on Linux is done far less often, so re-adjusting the build files is a tolerated approach. Best Regards / Mit freundlichen Grüßen Rainer Wiesenfarth -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Hans-Jürgen Gebauer ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Interest Digest, Vol 19, Issue 82
I've used QMake in two large cross-platform projects, one of which wasn't even a Qt application. I did look at other options including CMake and Premake 4 but decided to stick with QMake. Here are my thoughts: - The documentation is poor and in some case misleading and wrong. Google 'undocumented qmake' for some fairly vital information, particularly in regard to subdirs. - QtCreator's .pro file templates are embarrassingly bad and misleading. Don't use them. - The ability to create extra targets and custom build steps which run automatically based on dependant files is really, really powerful and a godsend for those icky special cases. None of the other build systems I looked had quite the level of 'hackability' that QMake provides. - It understands Qt's MOC, RC and UI compilers natively. - It supports all platforms Qt supports and allows the mixing of C, C++, Objective-C and Objective-C++ (the latter is vital on Mac). - The syntax is fairly readable compared to QMake. - It's the native build system for QtCreator and can generate XCode and VS projects. The last point is really important; a build system without good IDE support is of limited value in the real world. CMake support is improving but it's not there yet. I'm hoping QBS will prove a viable alternative at some point. I really liked the Lua syntax and the JS integration makes sense. But it's still a toy project. Build systems are messy by their nature though. You hack them so that they work for a project and spend your time on more important things. Date: Fri, 19 Apr 2013 14:11:29 +0200 From: Bo Thorsen bthor...@ics.com Subject: Re: [Interest] qmake: questions regarding huge projects To: Jan Kundr?t j...@flaska.net, interest@qt-project.org interest@qt-project.org Message-ID: 51713471.9030...@ics.com Content-Type: text/plain; charset=UTF-8; format=flowed Den 19-04-2013 13:36, Jan Kundr?t skrev: On Friday, 19 April 2013 12:29:04 CEST, Rainer Wiesenfarth wrote: well, I know about cmake, but was going for something less cryptic... :-) One of my biggest disappointments with qmake was that it just did not set up proper dependencies between the static libs I build and the targets which use it. Either I was missing something obvious, or qmake is really, really stupid. Yes, you can add a ton of macros on top of it to make it sane, but is that really what you want to do? Further details at [1]. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Interest Digest, Vol 19, Issue 82
On Fri, Apr 19, 2013 at 03:36:21PM +0100, Danny Price wrote: I've used QMake in two large cross-platform projects, one of which wasn't even a Qt application. I did look at other options including CMake and Premake 4 but decided to stick with QMake. Here are my thoughts: [...] - QtCreator's .pro file templates are embarrassingly bad and misleading. Don't use them. I am sure you can support this claim by giving links to some more detailed descriptions on bugreports.qt-project.org. Andre' ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Interest Digest, Vol 19, Issue 82
On 19 Apr 2013, at 20:49, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Fri, Apr 19, 2013 at 03:36:21PM +0100, Danny Price wrote: I've used QMake in two large cross-platform projects, one of which wasn't even a Qt application. I did look at other options including CMake and Premake 4 but decided to stick with QMake. Here are my thoughts: [...] - QtCreator's .pro file templates are embarrassingly bad and misleading. Don't use them. I am sure you can support this claim by giving links to some more detailed descriptions on bugreports.qt-project.org. Andre' I've contributed a number of bug reports and patches to bugreports.qt-project.org, several of which are still marked as P2 or P1 (take a look at 30657, 30279 or 30284 for example). But this falls more under the category of a feature request: - No subdir templates or wizards which means no way to create hierarchical projects within Creator. You have to use a separate text editor to create the pro files manually and then import them. QMake is fully capable of complex hierarchical projects including Creator itself and this should be promoted. - No templates or example projects for common things like an executable linking to a dependant library. This requires a surprising amount of work with QMake, more so to make it work correctly. - No binary or configuration directories - on Linux and Mac, all generated files, objects and binaries are dumped into one messy project directory (don't get me started on shadow builds - that wasn't a solution). At the very least, Creator should be able to generate a project that the user can expand without having to read through documentation, like XCode and VisualStudio. I know that Qt lacks a document framework but you get far more out of the box with an MFC (!), .Net or Cocoa Document-based project than you do with Creator's Qt Gui App. In regard to my bad or wrong comment, there is a lot of confusion regarding directory variables (PWD, IN_PWD etc) and dependencies. This leads to the impression that QMake (and by extension, Qt and Creator) is poor which isn't true. Some more comprehensive out of the box example projects would go a long way to address this. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Interest Digest, Vol 19, Issue 82
Hi, indeed - as one of the QMake advanced users (or hackers ;-) ) I agree that QMake has an unsufficient documentation for usage in more complex projects - see https://bugreports.qt-project.org/browse/QTBUG-28428. Without having to edit .pro and .pri files outside the QtCreator and to use many stuff of the Undocumented QMake sites it isn't feasable to run complex hierarchical projects or use advanced dependency checking etc. Here the QtCreator could learn something from the old men a la VC++ - offer a new context menu for much more .pro(ject) settings like dirs/paths, config options, qt modules etc. IMHO it's not a problem of qmake - its a matter of documentation and support inside the GUI. ciao, Chris___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Interest Digest, Vol 19, Issue 82
Hi, apropos: I could supply some more complex examples for .pro and .pri - including some basic utilities and environment stuff realized inside qmake files - if it helps ciao, Chris On 20. April 2013 at 00:20 Christian Dähn da...@asinteg.de wrote: Hi, indeed - as one of the QMake advanced users (or hackers ;-) ) I agree that QMake has an unsufficient documentation for usage in more complex projects - see https://bugreports.qt-project.org/browse/QTBUG-28428. Without having to edit .pro and .pri files outside the QtCreator and to use many stuff of the Undocumented QMake sites it isn't feasable to run complex hierarchical projects or use advanced dependency checking etc. Here the QtCreator could learn something from the old men a la VC++ - offer a new context menu for much more .pro(ject) settings like dirs/paths, config options, qt modules etc. IMHO it's not a problem of qmake - its a matter of documentation and support inside the GUI. ciao, Chris Mit den besten Grüßen, Christian Dähn Consultant // ASinteg GmbH // Hagenower Strasse 73, 19061 Schwerin // Registergericht Schwerin HRB 9035, Geschäftsführer: Sandro Seltitz // Telefon +49 (0)385 30 200 500, Fax +49 (0)385 30 200 509 // Internet http://www.asinteg.de___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Building qt4 on mac with -no-webkit
Hi Everybody, It seems this is not possible, -no-webkit is marked as Windows only in the configure options docs, why is that? If Qt was smart enough to link to the system webkit on Mac, it might make sense, but that doesn't happen. I would like to distribute my app via the Apple app store without qtwebkit, and with qtassistant using QTextBrowser. This combination works well on Windows, yet QtAssistant will not build if -no-webkit is specified on the configure line on Mac. I have also tried running configure as normal, then defining QT_NO_WEBKIT, and re-running the assistant makefile with -B. The assistant runs but still uses webkit. I can tell that since our help css has first-child selectors in it, and they are working on Mac, but on Windows QTextBrowser ignores them. As a last resort, I could hack the supplied the assistant.pro to force it to use QTextBrowser. I am using Qt 4.8.4, and gcc shows i686-apple-darwin11-llvm-gcc-4.2 on OSX 10.7.5. Thanks for any suggestions! Tony ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
