From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by mail.openembedded.org (Postfix) with ESMTP id 102086A8B6 for ; Thu, 6 Jun 2013 16:28:07 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id n12so2429350oag.31 for ; Thu, 06 Jun 2013 09:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=E6JKaRi0mDTZ0CFWq5tdj6DGKz0cJOmYcikVSQPQ3oo=; b=et1nzgLlOW9BCsiL15B5VKwLVuG9B6pGoqOjrnHk6cu9T8Zf3kTfXxBhQaec/FTq4U reCu/BJrvS5JeLl9oL58cNIkVqGTpeVLVEFq4TcoDIGuvlsPY1PW2mew7KWq1W9jY0Bo VJeSmSmLyiJ9eaQhiW/bKIZ7JWvgESXeDEdaGnjmM1ZM0+R05cV3V0I+ue/Umg8PrKrC v222qk9Gl6JZfWlCDOWkdMkLNNRttadI+AGtE2H8bqTMhjzw40/UOx3izjEihjSQ0Z3o lPDNPXOy6eQ4HLgQ451PL+K5+MdqVuAaFLZtD/DSkt/fuiLoc7osIj2HCs9humYQf78Z KF2Q== MIME-Version: 1.0 X-Received: by 10.60.94.70 with SMTP id da6mr18733719oeb.63.1370536088704; Thu, 06 Jun 2013 09:28:08 -0700 (PDT) Sender: otavio.salvador@gmail.com Received: by 10.182.108.167 with HTTP; Thu, 6 Jun 2013 09:28:08 -0700 (PDT) In-Reply-To: <1370533615.6864.4.camel@ted> References: <51AF6E2F.8040309@linux.intel.com> <51AF7336.8050802@linux.intel.com> <20130605200740.GF10298@denix.org> <51AFA565.3040607@linux.intel.com> <20130605205801.GI10298@denix.org> <1370533615.6864.4.camel@ted> Date: Thu, 6 Jun 2013 13:28:08 -0300 X-Google-Sender-Auth: PkczQxV84eOFh37UF47TlsQ7Yc0 Message-ID: From: Otavio Salvador To: Richard Purdie Cc: Patches and discussions about the oe-core layer Subject: Re: [PATCH dylan, master] Fix meta-toolchain-qte SDK build for x11-less DISTRO X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 16:28:08 -0000 Content-Type: multipart/alternative; boundary=089e012287c0b86f6804de7ecc04 --089e012287c0b86f6804de7ecc04 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 12:46 PM, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Wed, 2013-06-05 at 16:58 -0400, Denys Dmytriyenko wrote: > > On Wed, Jun 05, 2013 at 05:56:31PM -0300, Otavio Salvador wrote: > > > On Wed, Jun 5, 2013 at 5:53 PM, Saul Wold wrote: > > > > > > > On 06/05/2013 01:10 PM, Otavio Salvador wrote: > > > > > > > >> > > > >> > > > >> > > > >> On Wed, Jun 5, 2013 at 5:07 PM, Denys Dmytriyenko > > >> > wrote: > > > >> > > > >> On Wed, Jun 05, 2013 at 02:43:07PM -0300, Otavio Salvador wrote: > > > >> > On Wed, Jun 5, 2013 at 2:23 PM, Nicolas Dechesne < > > > >> > nicolas.dechesne@linaro.org linaro.org > > > >> >> > > > >> > > > >> wrote: > > > >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > > On Wed, Jun 5, 2013 at 7:19 PM, Saul Wold < > sgw@linux.intel.com > > > >> > wrote: > > > >> > > > > > >> > >> On 06/05/2013 10:12 AM, Otavio Salvador wrote: > > > >> > >> > > > >> > >>> > > > >> > >>> > > > >> > >>> > > > >> > >>> On Wed, Jun 5, 2013 at 1:58 PM, Saul Wold > > > >> > > > >> > >>> >>> > > > >> wrote: > > > >> > >>> > > > >> > >>> On 06/05/2013 09:32 AM, Nicolas Dechesne wrote: > > > >> > >>> > > > >> > >>> > > > >> > >>> On Wed, Jun 5, 2013 at 6:30 PM, Saul Wold > > > >> > > > >> > >>> > > >> sgw@linux.intel.com>> > > > >> > >>> > > >> > > >> >>**> > > > >> > >>> wrote: > > > >> > >>> > > > >> > >>> You could just directly put the > nativesdk-libx11 > > > >> in place > > > >> > >>> of the > > > >> > >>> variable, no need to have the variable > there. > > > >> > >>> > > > >> > >>> > > > >> > >>> yes, that's what I had initially, but found it > was > > > >> less easy to > > > >> > >>> read... > > > >> > >>> with X11DEPENDS it's more 'obvious' that there is > > > >> something > > > >> > >>> special.. > > > >> > >>> that said, i can make the change if that's really > > > >> needed. > > > >> > >>> > > > >> > >>> We do use the X11DEPENDS elsewhere when there are > multiple > > > >> > >>> dependencies, but I also found cases where we just > > > >> include the > > > >> > >>> dependency directly in the test. I was trying pick a > > > >> direction: > > > >> > >>> single entry no X11DEPENDS, multiple entries use > > > >> X11DEPENDS. > > > >> > >>> > > > >> > >>> Comments, flames, ... > > > >> > >>> > > > >> > >>> > > > >> > >>> Yes; I sent this patch in Febuary: > > > >> > >>> > > > >> http://patchwork.openembedded.****org/patch/44759/ > > >> patchwork.openembedded.org/**patch/44759/< > http://patchwork.openembedded.org/patch/44759/> > > > >> > > > > >> > >>> > > > >> > >>> Please use this one instead of the recent one. > > > >> > >>> > > > >> > >>> > > > >> > >> Well reading back on that, it looks like I was waiting > for an > > > >> > >> EXTRA_OECONF or related change to the autoconf scripts. > > > >> > >> > > > >> > >> Sau! > > > >> > > > > > >> > > > > > >> > > hmm. ok, sorry Otavio, i missed the other patch. I will > check > > > >> on my side > > > >> > > too about EXTRA_OECONF. > > > >> > > > > > >> > > > > >> > Nicolas, don't worry. It is normal to end redoing some stuff. > > > >> > > > > >> > Last time I checked it had no support in Qt build system; I > am > > > >> not sure if > > > >> > it uses or not the host headers (in case they exist) but it > needs > > > >> testing > > > >> > to be sure. > > > >> > > > >> I can confirm that it does not link against host X11 when built > w/o > > > >> that > > > >> dependency and nativesdk has no x11 libs/headers. As I > previously > > > >> mentioned, > > > >> we've been using this fix for over 6 months on several releases > built > > > >> on > > > >> different machines w/o problems... > > > >> > > > >> > > > >> In this case the patch can be merged 'as is'. > > > >> > > > >> > > > > I am still concerned about a floating dependency here, imagine the > > > > following: > > > > > > > > Build the toolchain with X11 enabled, nativesdk-libx11 is build, now > > > > rebuild with X11 disabled, the dependency is gone, but the libraries > and > > > > headers still exist in the sysroot and thus the configure will still > enable > > > > x11 in qte, bad things happen. > > > > > > > > > > I expect different distro features to have different build dirs. No? > > > > > > > > > > We need to have a disable flag to autotools. > > > > > > > > > > The qmake based system does not provide this; so to support it, it will > > > need to be a hack ... > > > > I agree with Otavio here - seems like you are after a rare corner case > here... > > We need determinism in the builds. Yes in this case it might be hard to > achieve but I do think we need to achieve it. > > So this patch isn't going in until we can avoid this option magically > floating, sorry. I've said this before and I've not changed my mind. > It is completely deterministic that it is *broken* for every one not using a DISTRO with X11; this is deterministic enough for me to justify it go in. As most of people didn't complain about this before, it is clear most use *x11* feature and thus this won't affect them. I see no point in delay it; complete determinism is better - sure - but a broken Qt toolchain for x11less systems does not improve it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 --089e012287c0b86f6804de7ecc04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 6, 2013 at 12:46 PM, Richard Purdie &= lt;= richard.purdie@linuxfoundation.org> wrote:
On W= ed, 2013-06-05 at 16:58 -0400, Denys Dmytriyenko wrote:
> On Wed, Jun 05, 2013 at 05:56:31PM -0300, Otavio Salvador wrote:
> > On Wed, Jun 5, 2013 at 5:53 PM, Saul Wold <sgw@linux.intel.com> wrote:
> >
> > > On 06/05/2013 01:10 PM, Otavio Salvador wrote:
> > >
> > >>
> > >>
> > >>
> > >> On Wed, Jun 5, 2013 at 5:07 PM, Denys Dmytriyenko <denis@denix.org
> > >> <mailto:denis@deni= x.org>> wrote:
> > >>
> > >> =A0 =A0 On Wed, Jun 05, 2013 at 02:43:07PM -0300, Otavio= Salvador wrote:
> > >> =A0 =A0 =A0> On Wed, Jun 5, 2013 at 2:23 PM, Nicolas = Dechesne <
> > >> =A0 =A0 =A0> nicolas.dechesne@linaro.org <mailto:nicolas.dechesne@**linaro.org<ni= colas.dechesne@linaro.org>
> > >> >>
> > >>
> > >> =A0 =A0 wrote:
> > >> =A0 =A0 =A0>
> > >> =A0 =A0 =A0> >
> > >> =A0 =A0 =A0> >
> > >> =A0 =A0 =A0> >
> > >> =A0 =A0 =A0> > On Wed, Jun 5, 2013 at 7:19 PM, Sau= l Wold <sgw@linux.intel.com > > >> =A0 =A0 <mailto:sgw@linux.intel.com>> wrote:
> > >> =A0 =A0 =A0> >
> > >> =A0 =A0 =A0> >> On 06/05/2013 10:12 AM, Otavio = Salvador wrote:
> > >> =A0 =A0 =A0> >>
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>> On Wed, Jun 5, 2013 at 1:58= PM, Saul Wold
> > >> =A0 =A0 <sgw@l= inux.intel.com <mailto:sgw@li= nux.intel.com>
> > >> =A0 =A0 =A0> >>> <mailto:sgw@linux.intel.com <mailto:sgw@linux.intel.com>>>
> > >> wrote:
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>> =A0 =A0 On 06/05/2013 09:32= AM, Nicolas Dechesne wrote:
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 On Wed, Jun= 5, 2013 at 6:30 PM, Saul Wold
> > >> =A0 =A0 <sgw@l= inux.intel.com <mailto:sgw@li= nux.intel.com>
> > >> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 <mailto:= sgw@linux.intel.com <mailto:<= br> > > >> sgw@linux.intel.c= om>>
> > >> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 <mailto:= sgw@linux.intel.com
> > >> =A0 =A0 <mailto:sgw@linux.intel.com> <mailto:sgw@linux.intel.com
> > >> =A0 =A0 <mailto:sgw@linux.intel.com>>>**>
> > >> =A0 =A0 =A0> >>> wrote:
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0= You could just directly put the nativesdk-libx11
> > >> =A0 =A0 in place
> > >> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 of the
> > >> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0= variable, no need to have the variable there.
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 yes, that&#= 39;s what I had initially, but found it was
> > >> =A0 =A0 less easy to
> > >> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 read...
> > >> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 with X11DEP= ENDS it's more 'obvious' that there is
> > >> =A0 =A0 something
> > >> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 special.. > > >> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 that said, = i can make the change if that's really
> > >> needed.
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>> =A0 =A0 We do use the X11DE= PENDS elsewhere when there are multiple
> > >> =A0 =A0 =A0> >>> =A0 =A0 dependencies, but I= also found cases where we just
> > >> =A0 =A0 include the
> > >> =A0 =A0 =A0> >>> =A0 =A0 dependency directly= in the test. I was trying pick a
> > >> =A0 =A0 direction:
> > >> =A0 =A0 =A0> >>> =A0 =A0 single entry no X11= DEPENDS, multiple entries use
> > >> X11DEPENDS.
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>> =A0 =A0 Comments, flames, .= ..
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>> Yes; I sent this patch in F= ebuary:
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 http://patchwork.openembedded.****org/patch/44759/<http= ://**
> > >> patchwork.openembedded.org/**patch/44759/<h= ttp://patchwork.openembedded.org/patch/44759/>
> > >> >
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>> Please use this one instead= of the recent one.
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >>>
> > >> =A0 =A0 =A0> >> Well reading back on that, it l= ooks like I was waiting for an
> > >> =A0 =A0 =A0> >> EXTRA_OECONF or related change = to the autoconf scripts.
> > >> =A0 =A0 =A0> >>
> > >> =A0 =A0 =A0> >> Sau!
> > >> =A0 =A0 =A0> >
> > >> =A0 =A0 =A0> >
> > >> =A0 =A0 =A0> > hmm. ok, sorry Otavio, i missed the= other patch. I will check
> > >> =A0 =A0 on my side
> > >> =A0 =A0 =A0> > too about EXTRA_OECONF.
> > >> =A0 =A0 =A0> >
> > >> =A0 =A0 =A0>
> > >> =A0 =A0 =A0> Nicolas, don't worry. It is normal t= o end redoing some stuff.
> > >> =A0 =A0 =A0>
> > >> =A0 =A0 =A0> Last time I checked it had no support in= Qt build system; I am
> > >> =A0 =A0 not sure if
> > >> =A0 =A0 =A0> it uses or not the host headers (in case= they exist) but it needs
> > >> =A0 =A0 testing
> > >> =A0 =A0 =A0> to be sure.
> > >>
> > >> =A0 =A0 I can confirm that it does not link against host= X11 when built w/o
> > >> that
> > >> =A0 =A0 dependency and nativesdk has no x11 libs/headers= . As I previously
> > >> =A0 =A0 mentioned,
> > >> =A0 =A0 we've been using this fix for over 6 months = on several releases built
> > >> on
> > >> =A0 =A0 different machines w/o problems...
> > >>
> > >>
> > >> In this case the patch can be merged 'as is'. > > >>
> > >>
> > > I am still concerned about a floating dependency here, imagi= ne the
> > > following:
> > >
> > > Build the toolchain with X11 enabled, nativesdk-libx11 is bu= ild, now
> > > rebuild with X11 disabled, the dependency is gone, but the l= ibraries and
> > > headers still exist in the sysroot and thus the configure wi= ll still enable
> > > x11 in qte, bad things happen.
> > >
> >
> > I expect different distro features to have different build dirs. = No?
> >
> >
> > > We need to have a disable flag to autotools.
> > >
> >
> > The qmake based system does not provide this; so to support it, i= t will
> > need to be a hack ...
>
> I agree with Otavio here - seems like you are after a rare corner case= here...

We need determinism in the builds. Yes in this case it might be= hard to
achieve but I do think we need to achieve it.

So this patch isn't going in until we can avoid this option magically floating, sorry. I've said this before and I've not changed my mind= .

It is completely=A0deterministi= c that it is *broken* for every one not using a DISTRO with X11; this is de= terministic enough for me to justify it go in. As most of people didn't= complain about this before, it is clear most use *x11* feature and thus th= is won't affect them.

I see no point in delay it; complete determ= inism is better - sure - but a broken Qt toolchain for x11less systems does= not improve it.=A0
=A0
--
Otavio Salvador =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 O.S. Systems
http://www.ossyst= ems.com.br =A0 =A0 =A0 =A0http://projetos.ossystems.com.br
Mobile: +55 (53) = 9981-7854 =A0 =A0 =A0 =A0 =A0 =A0Mobile: +1 (347) 903-9750
--089e012287c0b86f6804de7ecc04--