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

[Thiago Macieira]

Ross Bencina wrote:
>Thiago Macieira wrote:
>>It will be installed correctly, probably into
>>/usr/local/Trolltech/Qt-4.4.3.
>
>How does this interact with the frameworks the commercial installer puts
> in (i think) /Library/Frameworks?

It doesn't interact at all. As for your programs using Qt, how the dynamic 
linker finds the libraries and frameworks, I have no clue. It's Mac-specific 
and I am not a Mac expert.

>>It will not match the .dmg
>
>In exactly what ways will it not match the .dmg?

By not placing the files in the same places as the .dmg does.

>Ok, but are these steps documented? You mentioned otool, but is that the
>only thing? Do you understand my problem? At the moment I am unable to
> use a patched version of Qt-commercial on OSX because I have no way to
> build a version which matches the Trolltech binaries (and hence no way
> to do QA with guarantees that the only thing that has changed is the
> patch I've applied).

Those steps are not documented. We freely change our scripts to match the 
new modules that are added to Qt, new examples and demos, as well as 
changes to the build procedure, like license texts. The scripts are very 
much tied to the particular Mac installation we use to build the packages, 
so it doesn't really make sense to publish it.

Basically, the purpose of the script is, besides building Qt with the 
options above, to install it so that:
 a) stuff ends up where a Mac developer would expect stuff to be
 b) it works

You can take a look at the manifest of files in each volume of the .dmg to 
see where we believe a Mac developer expects stuff to be (libraries, 
documentation, examples and demos, tools, etc.)

Aside from moving those files around (and using otool and similar tools to 
adapt to the moving), we do not change them. So if you simply compile and 
install with make install, you should have suitable binaries, albeit at 
different locations.

>Perhaps I should just forget binary releases on OSX, from what you are
>telling me they are more than useless if I need to patch something
> later. The fact that Trolltech supplies a patch is great (and what I
> expect from my commercial licence) the fact that I can't even compile
> Qt with the patch on OSX and get a direct-swappable replacement for the
> commercial binaries is unacceptable.

I'll check if we can release the scripts to create the Mac binaries. We 
did that for Windows (see tools/installer).

However, the same problem applies: it's very much tied to our infra-
structure, it's very hackish and we change it freely. And we can't publish 
it all, because of the dependency on the license-key checker code.

>> We don't have the infrastructure for building packages for each
>> customer, since the patches that we sometimes send are different.
>
>How about releasing more regular maintenance releases with roll-ups of
> all fixes :-)

Every 2 months not quick enough for you? :-)

It takes at least 2 weeks to prepare a package and involves a great part 
of the developers. Releasing more often than every 2 months would mean we 
do nothing else other than release, so there would be nothing new to be 
released.

>>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.
>
>My point is not about feature freezing 4.5 its about _stabilising_ 4.4
> (or 4.5) before even thinking about shipping the next bunch of new
> features.

That's what happened between October and March this year. Between the 
freeze and the release, it's the stabilisation period.

Our procedures are changing so we expect in the future to destabilise 
less, therefore needing less time for re-stabilisation.

>As far as I'm concerned 4.4 has never been stabilised and I doubt 4.5 is
> yet either (personally I can't afford to risk switching from what I

As far as I'm concerned, 4.4 was stable by March 2008, when we released 
RC1. 4.5 has been stable since January/09 too.

The fact we don't agree on dates means we use different criteria for 
qualifying something as "stable".

> Two examples: (1) the example you gave of QNetwork, (2) the
> patched version of 4.4.3 commercial I use here fixes significant
> crashes in the paint engine on Win32. I'm sure there are others.

The particular example I gave of QtNetwork wasn't a bug fix, but a new 
feature. Therefore, it could not have been added to 4.4. And that's the 
reason the particular customer upgraded the entire module: they needed new 
features which we would not add to a released, feature-frozen series.

>As far as I can see, Trolltech dumped 4.4.x as soon as 4.5.0 was
> released. There has not been a single 4.4.x release since 4.5.0 was
> released. 

We've always done that. Releases for a minor stop when the next minor 
comes around. The only exception was 4.3.5, which was released after 4.4.0 
beta 1. Yet no 4.3 releases happened after 4.4.0 final.

Like I said, releasing is a 2-week procedure (3 for an RC), which involves 
a great deal of manual testing, involves our Support department, 
Marketing, QA, etc. We just don't have the resources for releasing past 
series with our current infra-structure and processes.

> Personally, what I expect is stable, regular packaged
> maintenance releases of 4.4.x say for at least a year after 4.5 is
> released, and _then_ 4.4.x can go into deep maintenance with only
> critical fixes.

I'm sorry, but the patches should be enough. Our Support department does 
provide support for 2 years after a release is made and support beyond 
that can be discussed. But the release engineering department is no longer 
involved: we expect customers to be able to build Qt from sources if 
necessary.

Like I said, let me check if we can release the scripts to recreate the 
.dmg.

>But lets forget this -- I understand that Trolltech/Nokia have some
> other strange strategy other than to ship reliable, stable software to
> their commercial customers. The main thing I need to work out now is
> how to succesfully patch 4.4.3 on OSX as per my questions above.

The strategy is to ship reliable, stable software to everyone. Commercial 
customers are a part of that, but not the only part.

The other part of the strategy is to add attractive, important features 
that make developers' lives easier and their programs better. So we have 
to keep the pace and (hopefully) ahead of the curve when it comes to 
features.

We're very constrained when it comes to talent. We have open positions 
(have had them for the entire year, despite the economic crisis) and we 
just cannot manage to fill them. I think we had only two new developers 
starting in Oslo for the entire 1st half of 2009. That means we always 
scale back on plans.

-- 
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/20090721/dbf333c9/attachment.bin