[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