[Releasing] [Development] FW: Finalizing qt5.2 RC1

[Wolfgang Bremer]

On 22.11.2013 19:50, Oswald Buddenhagen wrote:
> On Fri, Nov 22, 2013 at 07:41:43PM +0100, Wolfgang Bremer wrote:
>> We did the last merge from upstream/release on the 12th November.
>> Since then the following commits went into QtBase in the release branch
>> and applied changes to the configure script.
>>
>> 02556c0 clean up mess surrounding PLATFORM_MAC
>> f0524ce consolidate all license checking in the earliest place possible
>> a6b9729 don't initialize build dir earlier than necessary
>> 078ad53 print help right after parsing command line
>> 558b0a2 make help independent from options and environment
>> 925899d do CONFIG+=silent after configure tests
>> 862fbd9 move some option validations to more relevant places
>> d1990a7 don't automatically display help on error
>> c9692fb remove hacks to support solaris 2.[56] and aix < 5
>> 7faf1a7 initialize WHICH, AWK, PERL and MAKE a bit earlier
>> 08d7bac configure: Document that -sdk only applies to the target mkspec
>>
>> Honestly, I don't know which commit exactly now causes the configure
>> call to fail.
>>
> please bisect it. not that it would change anything, but i'm curious
> what i missed.
>
>>           -no-sql-sqlite_symbian \
>>           -no-sql-symsql \
>>
> *this* is your problem. there are no such plugins in qt upstream. and
> most likely your downstream. you copied the line cargo cult like from
> some 4.8 setup and were lucky so far for some bizarre reason.
Thanks! Removing this two options fixed the build.
The problem is that we want to nail down as much as possible of our 
configuration.
The intention is to break the build if the underlying system changes or 
upstream commits change the scope of the build output.
I am fine with this and would expect such breakages on dev, stable 
branches but not on the release one.
>
>> I don't want to blame any one, but this should just not happen on the
>> release branch.
>>
> it's a classical case of garbage in, garbage out. there are no
> guarantees for invalid input; any bugfix can legitimately break it at
> any point, and as your setup is not part of the CI, we won't even know
> until you complain.
Sure, being part of the CI system would be the ideal solution.
You can trust me that it would make our daily work life way easier, 
effective.
We are working on this and I hope we have a basic build testing setup 
integrated in early January.

This is the second time this week that a change in the release branch 
breaks our build.
The first one tried using a function in the v4 engine implementation 
which is just not available on our platform.

Let's talk about the bisect part offline.

Wolfgang
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.