From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id AB296A0526; Tue, 10 Nov 2020 13:53:41 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 860782B9D; Tue, 10 Nov 2020 13:53:40 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by dpdk.org (Postfix) with ESMTP id 286A82B93 for ; Tue, 10 Nov 2020 13:53:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605012817; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HZ9zHwihJNoaI/QaH5q01vKmoltsxNxR55CguL1dDsg=; b=YpWtwVx2igL4OLc0WK015H1RFgxvcMe3gk1JHaS0AToEJVFbZbDdrFH3Ain9hzMBa+86Hr kFB+9RPVQx2Y89kotczzzEzR517J+iuYSrItWpL0xeOzaT3Dhavr4rb+hj0A6Rr0G35iGP 0+/QqUoUZg3Ce0Jr8mtVi4Z3KdRGUkQ= Received: from mail-vs1-f70.google.com (mail-vs1-f70.google.com [209.85.217.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-204--AjQYZhQM5Gi2EpU1kUUAQ-1; Tue, 10 Nov 2020 07:53:35 -0500 X-MC-Unique: -AjQYZhQM5Gi2EpU1kUUAQ-1 Received: by mail-vs1-f70.google.com with SMTP id x3so2586748vsc.6 for ; Tue, 10 Nov 2020 04:53:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HZ9zHwihJNoaI/QaH5q01vKmoltsxNxR55CguL1dDsg=; b=TpXjYabaT1QnpYoZzLIovHgP0+p4r4OzGu5EtA8qcld9L0s2+T6ZXRyXk33lQaePyD rh//97YDTCD+nYKGaOIiqH0R4mVN1TqeK00+nuIRIClZyJ9eVDvp4KO1fbIiLxAFevEF RfbRX7ues7YSUBT+jgCckT6hxc/qFGtej1x9mv2t+ZO/Q2ftrMVo9lK+RDOfTc/KRWs3 ZO2dPjQLeY6A9W3COW6EHFJzqlZ+d4nwo8OAPxBNEGqKFCPnFbvli86yOKGAILJ8xW1e r4l+NO2GTKBxBdQQ4xF7O3Vi4gCX/45A3wxq3m5/OQtzzGIFWjQBie4kQtvbOWnYubvb awKA== X-Gm-Message-State: AOAM532OG5YchihOioIZlh4rghSjRd/PHkKfC3hQSkps6wP2ZIKAoRey yfpGNaFl6+lTALkEowfxFO5g3qHOK+LimYFgdG/RSs6gvYIlNzIqEslGhogTWrPgNpaomeqzGJA b74H18heLRhxYtAamp7E= X-Received: by 2002:ab0:380d:: with SMTP id x13mr9575249uav.41.1605012815125; Tue, 10 Nov 2020 04:53:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJyWNxrxxvqsHay8rYbWeblv2zg/cXpWra0/WaJsiZvLm/s5eqfp8vLFXSMV0HwbwbPFmLkij+AnKX3II84gfCA= X-Received: by 2002:ab0:380d:: with SMTP id x13mr9575238uav.41.1605012814948; Tue, 10 Nov 2020 04:53:34 -0800 (PST) MIME-Version: 1.0 References: <20201014104126.469517-1-conor.walsh@intel.com> <7206c209-ed4a-2aeb-12d8-ee162ef92596@ashroe.eu> <869dbb8b-1d7c-4e9a-b009-e89af3396354@ashroe.eu> In-Reply-To: <869dbb8b-1d7c-4e9a-b009-e89af3396354@ashroe.eu> From: David Marchand Date: Tue, 10 Nov 2020 13:53:24 +0100 Message-ID: To: "Kinsella, Ray" Cc: "Walsh, Conor" , dpdk-dev , Luca Boccassi , Dodji Seketeli , "Mcnamara, John" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v7 0/4] devtools: abi breakage checks X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Nov 3, 2020 at 11:07 AM Kinsella, Ray wrote: > Came across an issue with this. > > Essentially what is happening is that an ABI dump file generated with a newer versions of libabigail > is not guaranteed to be 100% compatible with a older versions. > > That then adds a wrinkle that we need may need to look at maintaining abi dump archives per distro release, > or libabigail version depending on how you look at it. This is something I had encountered. The Travis script flushes the ABI cache on a libabigail version change. When using the test-meson-builds.sh integration, the gen-abi.sh devtools script can be called to regenerate the dump files from the existing local binaries. > > An alter approach suggested by Dodi would be to just archive the binaries somewhere instead, > and regenerate the dumps at build time. That _may_ be feasible, > but you lose some of the benefit (build time saving) compared to archiving the abi dumps. > > The most sensible approach to archiving the binaries. > is to use DPDK release os packaging for this, installed to a fs sandbox. > > So the next steps are figuring out, which is the better option between > maintaining multiple abi dump archives, one per supported os distro. > or looking at what needs to happen with DPDK os packaging. > > So some work still to do here. I am still unconvinced about the approach, but I'll wait for your next proposal. -- David Marchand