[Qt-interest] standard configure parameters for OSX commercial binaries (4.4.3) ?

Ross Bencina rossb-lists at audiomulch.com
Mon Jul 20 10:38:05 CEST 2009


Thanks for the quick response Thiago

Thiago Macieira wrote:
>A good hint of what the configuration was is the mkspecs/qconfig.pri file.

Hmm, it doesn't seem to tell me too much (given i don't know how to read 
it). e.g. The mkspecs/qconfig.pri  in Win32 4.4.3 commercial binaries 
doesn't mention sqlite plugin, even though that's one of the configure 
options. (but see below about config.cache)

>>The reason I ask is that I need to rebuild with a patch and I want to
>> get the same binaries (except for the patch) as the commerical binary
>> release
>
>"make install" isn't enough. The .dmg files are created by manually picking
>up things and moving them into their proper places, and running otool to
>change the library search paths.

So, if I run "make install", the frameworks won't be installed correctly? 
(!) or just not the same as the dmg?

Is the dmg build script available?

I need to distribute a patched Qt on OSX. You seem to be saying I can't 
actually build the OSX version and get the same results as the binaries you 
guys are shipping. Is that correct? I do have my own otool scripts which 
retarget the installed qt frameworks so I can include them in my App bundle.


>>(hint: it would be really helpful if the configure parameters were
>> written into a file when you run configure so you could check how the
>> source had been configured!)
>
>You mean like config.status?

There's no config.status here but I did find configure.cache in a version I 
configured -- and yes, that's exactly what I was looking for. It would be 
very useful if this was shipped in the binary packages, especially if it had 
a comment at the top: # built with the following configure parameters:

> Except that this file and other by-products of the build process (moc
> outputs, object files, uic and rcc outputs, etc.) are not included in the
> packages.

I think this one (perhaps renamed) would be really helpful to keep in the 
packages. My use-case is that I usually (and prefer to) use the binary 
packages, but every now and then I get source patch from support which I 
need to apply and build my own version which is identical to the commerical 
binary package except for the patch. At the moment it's hard for me to know 
with 100% certainty that I will get the same results as the commercial 
binary. Even though you told me the parameters, they could change for future 
versions. Another option would be for Qt Software to rebuild patched binary 
packages for commercial customers on request, or supply some infrastructure 
for doing this -- or perhaps even better, maintain a stable branch with 
regular updates =) Stability, cosmetic appearance and bug fixes are a lot 
more important to me than new features or speed.

Thanks!

Ross. 




More information about the Qt-interest-old mailing list