From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 31A1F3858D37 for ; Tue, 16 Apr 2024 15:33:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 31A1F3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 31A1F3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713281585; cv=none; b=QI1m5YNI+bHoc9KfB5LihkEl0F46CKWsNFlcqxbysxlBJa+ebD36ZEKmvi3OdnFMBwzxRRGH57NTu1g7bsFl0l+qZkXbNu+lcBvm9HcKAPi4zlh2znzxU9YGtMrokZp0kXwP4UeVk39NiN0Bmgous8tZQS9PbcCjBxXwfnmC+GM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713281585; c=relaxed/simple; bh=rNXuJpBDXB60lPGXCpBTKZNnNgvwPXoWdANbwtufQaI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=D4/YnqYS1ipQGlqmqD8ajYAfjaiT7jKq8P60HuYfWqhOsV4Rv9NGvVTwANE8sxmGZ8nzUS/cS7vvaj4duy4p+L9weHhVlpWaa/k/o5eIs7qj/U8qIi2V7eA5+yL3s0cJTHUI73uuSEOVSoAPadLeIY6q62O/WUlo4ri+Nx6Qbyw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1713281579; bh=rNXuJpBDXB60lPGXCpBTKZNnNgvwPXoWdANbwtufQaI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=RBtQWMHOhZyO9EFTuGmve5SubJyvkohWA/j2EoBEK9Jm7h6QrVr006yGZR2gNdOBj ZkMeEgYBIQ6ovOVt8CZQ4mwrf8JJWjqRo8dWALZfaLFzEgH5xkxGRj6t6t4v058WAc zafWe+K4XOx/roxdIZZz2Jdrw3tZWGG5WO+q+T7A= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 6CE291E092; Tue, 16 Apr 2024 11:32:59 -0400 (EDT) Message-ID: <96fda049-f7a5-4527-bfb2-0ec5cdefca13@simark.ca> Date: Tue, 16 Apr 2024 11:32:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/6] autoregen.py: Use autoreconf in most GCC directories To: Christophe Lyon Cc: buildbot@sourceware.org References: <20240412200559.1649050-1-christophe.lyon@linaro.org> <20240412200559.1649050-5-christophe.lyon@linaro.org> Content-Language: en-US From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2024-04-16 10:47, Christophe Lyon wrote: >> If I call `aclocal` without args in gcc/gcc, it re-generates aclocal.m4 >> fine, because it got the include path info from configure.ac. If I >> remove the `AC_CONFIG_MACRO_DIRS` line from gcc/gcc/configure.ac and run >> aclocal.m4, then I am missing a bunch of m4 files in the resulting >> aclocal.m4. If I remove the `ACLOCAL_AMFLAGS` variable from >> gcc/gcc/Makefile.am, it has no effect on `aclocal`. That variable only Sorry, I wrote Makefile.am here, it should be Makefile.in. >> exists for the benefit of the Makefile rule that regenerates aclocal.m4, >> lower in Makefile.am. But I would argue that it's unnecessary, since >> that info is encoded in configure.ac, so the rule could call aclocal >> without any -I args. > > Of course: aclocal does NOT read Makefile.am, but autoreconf does. Ok, I wasn't aware of autoreconf getting flags for aclocal from ACLOCAL_AMFLAGS in Makefile.am, now I see it in the docs. But it seems to me like autoreconf will "just work" in most cases then: - for directories with a Makefile.am, autoreconf will read the -I flags specified in Makefile.am/ACLOCAL_AMFLAGS and pass them to aclocal. - for directories without a Makefile.am (like GDB), autoreconf will call aclocal without -I flags, but aclocal will use the include paths specified in configure.ac/AC_CONFIG_MACRO_DIRS. > So what I noticed for the 'gcc' subdir is that autoreconf will > generate the same contents but also print a few warnings. > This is because when calling aclocal with some -I flags, the contents > of those included .m4 files is taken into account before scanning > configure.ac, so macros like AM_PATH_PROG_WITH_TEST are defined before > being used, while when using autoreconf (thus calling aclocal without > any -I flag), those .m4 files are processed later, leading to warnings > that AM_PATH_PROG_WITH_TEST is "not found in library". IIUC, there's > an iterative process which means that things are re-assessed later. > > So.... it seems it's not a real problem to use autoreconf as you > suggest, but we'll see such warnings in the buildbot logs (not causing > errors IIUC). I don't really know how this is supposed to work then, it seems illogical to me. aclocal recommends using AC_CONFIG_MACRO_DIRS: https://www.gnu.org/software/automake/manual/html_node/Local-Macros.html So it seems to me like it should consider the macros found in these directories when processing the rest of the files... Simon