On Thu, Mar 26, 2020 at 11:29 AM Khem Raj <[email protected]> wrote: > > 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. >
I think IRC discussions confused me a bit, This patch will improve the situation for binutils since we dont have to run Autoconf which we are now doing on few selected directories where configure.ac has been changed due to our patches. This patch ensures that all configure scripts are up to date and do not require to be regenerated during do_configure step like common autotooled recipes. > > > > > Cheers, > > > > > > Richard > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#136788): https://lists.openembedded.org/g/openembedded-core/message/136788 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]] -=-=-=-=-=-=-=-=-=-=-=-
