From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by sourceware.org (Postfix) with ESMTPS id 3E1CC3858C60 for ; Fri, 21 Jan 2022 23:08:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3E1CC3858C60 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-f51.google.com with SMTP id u14so5831127lfo.11 for ; Fri, 21 Jan 2022 15:08:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=y5bOe+o7PoFHXwyLoi9ue9qTOMyG6LuDdM5gn3266HE=; b=mvxEop9c8hnVkFTT+jIvDN4PXHnU1UTYSL4QpSJN3Kt/M9I8YKG7QZONFsaT2UiPoJ hnsMkGWBcsePstmummCX50lPVdlI1mietHuoAFNmkYI2M25KmGpxv9lExz3Bph+3VaG8 UX9R9sWtwR8xEbjlE65dUZh5Wt1wGMk8c5iMsW9DjpBO5bML+ouN22t8WSbObxmaE4Qh xinHvNlh96EXvPahRzMRZ9tmO7BNDc20W6MFMb3LnlFTDFvexkA2nhbi28Vl2yvAUNLO CehEex8xPoAcP0/H8mY4yzgXrESkWQuQoVWUKocuJhUBwFEkbjuNGydUDoQFeVr4Dfq3 iHTQ== X-Gm-Message-State: AOAM531N0zpRIeHDbDS9F6IZSk6IrOM3G/JkQJaPgPU+qtcBNnarbTt2 TFNDqYaE6vM9ofjBdaZO2w57z6io1YY+tA== X-Google-Smtp-Source: ABdhPJyRx/v3bf2tbTNgG2ktpeGnWEqxbHxdFi7BcOSyAffRJQPPTrDIPF4Ql5PEwgzo39ISt8m4Tw== X-Received: by 2002:a05:6512:925:: with SMTP id f5mr5206867lft.282.1642806498454; Fri, 21 Jan 2022 15:08:18 -0800 (PST) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id e7sm307764lfj.91.2022.01.21.15.08.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Jan 2022 15:08:18 -0800 (PST) Received: by mail-lf1-f46.google.com with SMTP id z19so161084lfq.13 for ; Fri, 21 Jan 2022 15:08:18 -0800 (PST) X-Received: by 2002:ac2:532d:: with SMTP id f13mr5060887lfh.669.1642806497857; Fri, 21 Jan 2022 15:08:17 -0800 (PST) MIME-Version: 1.0 References: <26fff1a3-7743-e0ce-f7a6-70b39a030118@embedded-brains.de> <41deefa7-d1ae-18f2-6a8e-25e002d85ed6@yahoo.de> In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Fri, 21 Jan 2022 17:08:06 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Question about autoreconf to regenerate configuration files To: "R. Diez" , Joel Sherrill , Newlib , Matthew Joyce Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3031.8 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2022 23:08:22 -0000 On Fri, Jan 21, 2022 at 4:09 PM Mike Frysinger wrote: > > On 21 Jan 2022 17:09, R. Diez via Newlib wrote: > > > [...] > > > The bootstrap time was large enough to > > > negatively impact our ability to do automated regression testing. > > > > A very long bootstrap time could be an issue. > > > > However, compilation time normally outweighs by far the Autotools regeneration step. Is that a problem in Newlib at the moment? > > autotools (autoreconf really) doesn't run in parallel, so every subdir > with a configure script needs a separate serialized run of all the tools. > newlib has many many of these (arguably, too many). > > on my quad core 4.2GHz AMD that is otherwise idle ... > > $ time (cd newlib && autoreconf) > real 5m22.170s > user 3m13.709s > sys 0m12.332s > > $ time (cd libgloss && autoreconf) > real 1m41.754s > user 0m43.505s > sys 0m3.618s > > > # Blackfin builds 8 copies (multilib) of newlib+libgloss by default. > $ time (cd build; ../configure --host=bfin-elf; make -j4) > real 1m40.950s > user 0m58.032s > sys 0m30.968s > > so yeah, autotools generation here is significant. This is on the order of what we saw using autotools with RTEMS. > > If Newlib wishes to depart from best practice, it would be nice to know the concrete issues in the context of this project, and not just some general "all solutions in this area seem to suck" justification. Sorry. I meant that more as all build systems have tradeoffs. You just have to be conscious of the pain points and who incurs them. >From an RTEMS use case, all our users build tools from source with something similar to BSD ports. These fetch source and apply patches. We rarely use the newlib release tarballs and track from git. I built an aarch64 toolchain yesterday and it tool about 25 minutes on my laptop. It's a 2.87Ghz i7 with 4 real cores. It's a few years old and far from the fastest but still faster than what I see user with when I teach RTEMS classes. This would add 5 minutes to that since I assume we can skip libgloss as we don't use it. If newlib goes to needing a bootstrap process, RTEMS will adjust. The question is how many newlib users get binaries and how many build it themselves. The burden goes on newlib developers, tool distributors, or end users building from source. This is something for the newlib community to decide > again, this isn't "just newlib". newlib is part of the historically combined > toolchain tree/ecosystem. that means you can take binutils, gdb, gcc, newlib, > libgloss, cgen, sim, zlib, etc... and have a single monolithic source tree and > build them all at once. the projects have separated a little bit in that they > have diff git repos, but the top-level dir and a few subdirs are still shared, > and some folks still hand merge them. newlib is part of that ecosystem and as > such, follows its conventions. changing newlib behavior would have a ripple > effect and is why consensus across all of them is desirable. although usually > if you can convince gcc to change, the rest will follow to keep things simple. > > i'm not advocating for this system, but i understand the trade-offs, and it's > been around longer than i've been a programmer. That's all I was trying to point out. Every build system and approach to using it has advantages and disadvantages. > -mike