On Thu, Mar 26, 2020 at 10:03 AM Khem Raj <[email protected]> wrote: > > On Thu, Mar 26, 2020 at 5:45 AM Richard Purdie > <[email protected]> wrote: > > > > On Wed, 2020-03-25 at 16:16 -0700, Khem Raj wrote: > > > libtool patch will result in configure file regeneration, instead of > > > doing that at build time, do it in patch itself, this avoids running > > > autoconf before configure step. > > > > > > Since binutils needs specific version of autoconf ( which is 2.69 ) > > > this will break on systems using newer or older verisons of autoconf > > > in current state. > > > > > > Signed-off-by: Khem Raj <[email protected]> > > > Cc: Ross Burton <[email protected]> > > > --- > > > meta/recipes-devtools/binutils/binutils.inc | 8 +- > > > .../binutils/0007-Use-libtool-2.4.patch | 26583 ++++++++++++ > > > ---- > > > 2 files changed, 20352 insertions(+), 6239 deletions(-) > > > > Whilst I appreciate the intent here, our policy is to autoreconf most > > things in general. This allows us to more easily support newer > > architectures and platforms. > > > > There is a significant build speed benefit from not autoreconf'ing > > things but where do we draw the line? > > > > in general this is fine but binutils, gcc , glibc can not be treated > in general category > since they have dependencies on specific versions of autotools > unfortunately, it currently > works for binutils because our version of autoconf matches with what > binutils expects > as of now, but this will skew if this changes in future. In nutshell, > the auto-fu in these > packages is quite involved and has hard dependencies on specific > versions of tools > needed to reconfig them. > > > I'm also worried about patches which touch both configure and > > configure.ac since the timestamp changes can cause things to autoreconf > > even when we're trying to avoid that. As such this is actually quite a > > risky change given past bad experiences :( > > We were not fully reconfiguring binutils even now, because of other > autotool sversion mimatches > only autoconf was being run which does not change the case if > configure was say regenerated > as you say. > > > > > I'm not completely against it but I am worried. > > > > perhaps addresses some of your concerns.
after some IRC discussions, I think it better for us to drop this change. > > > Cheers, > > > > Richard > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#136769): https://lists.openembedded.org/g/openembedded-core/message/136769 Mute This Topic: https://lists.openembedded.org/mt/72553705/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
