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

[Thiago Macieira]

Em Segunda-feira 20 Julho 2009, às 10:38:05, Ross Bencina escreveu:
> So, if I run "make install", the frameworks won't be installed correctly?
> (!) or just not the same as the dmg?

It will be installed correctly, probably into /usr/local/Trolltech/Qt-4.4.3. 
It will not match the .dmg

> Is the dmg build script available?

No.

> 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.

You can do the same we do: move the files to their proper places and otool the 
libraries, plugins, examples and demos to point to the right place.

> >>(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:

Like I pointed out above, it's not enough to recreate the entire package.

Our scripts do a few steps more, which configure && make install can't 
reproduce.

> 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.

Indeed. That happens. It did change from 4.4 to 4.5, actually. I gave you the 
line for 4.5, not 4.4, but I don't think it affects the commercial build (the 
change was in the opensource build).

> Another option would be for Qt Software to rebuild patched
> binary packages for commercial customers on request, or supply some
> infrastructure for doing this

A Mac binary package takes 2 hours to build, a Windows Visual-Studio build 
takes about 3, the MinGW package takes 5.

We don't have the infrastructure for building packages for each customer, 
since the patches that we sometimes send are different. For example, for a 
given customer, we recommended wholesale replacing the QtNetwork module in 4.4 
with the one from 4.5. (It works, and you get better proxying support)

> -- 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.

You're describing this branch:
http://qt.gitorious.org/qt/qt/commits/4.5

Since 4.5 has been feature frozen since about October last year, there are no 
new features in that branch. There have been a few performance improvements 
here and there, but only where the change was sure not to cause problems.

As time passes, the bar for commits into that branch rises. So after two 
patch-releases, you can expect that branch to move very slowly, with only very 
important fixes. After 4.6.0, the 4.5 branch will be mostly dead, except for 
very critical fixes.

-- 
Thiago Macieira - thiago.macieira (AT) nokia.com
  Senior Product Manager - Nokia, Qt Software
     Sandakerveien 116, NO-0402 Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20090720/fa447469/attachment.bin