From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80169126C02 for ; Fri, 4 Jul 2025 19:59:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751659142; cv=none; b=juzZ13kAmKtWqxeQu346VEPmQS66UQBnI/mBB4D7IZwJmboQSgRmOU+mVrTziPTe2zmedONnc+7fbQ8kRtslLazTId41tS+F1FXal+QkQUSAJt2XhZqBD+WrrVaaST+/MZXruk8z0Wz3Ldp2YvswHyKVpF762AhOjnNzkCPLYHs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751659142; c=relaxed/simple; bh=/WCU5sG/O157KFVyrEYduJsuzv1fWFFZc/iKrhzoggI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rDuQBEsNkBq/UJ3i3nGQlKuEkYGOflO1arPySwCLt9NXBJtmoiU25vtCa5H0b4L3MW/3gGyxyaPEpNEM2aqwGxFfGIi/sjPBRo66X62anq2JBfMa2s7KJG32V+l2mza2nuU5g7Ier9zUa6KouqvwZELEBhRCuJqdMEZsbds70bs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mOpkxuqK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mOpkxuqK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 280CBC4CEE3; Fri, 4 Jul 2025 19:59:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751659142; bh=/WCU5sG/O157KFVyrEYduJsuzv1fWFFZc/iKrhzoggI=; h=Date:Reply-To:Subject:To:Cc:References:From:In-Reply-To:From; b=mOpkxuqKWCunh02YCkKB8NERNl109/5QeKfN6owpxgJy8my4RAcEKgf88BptpA6Nl YpiKhQR5qEeU58c3aaHudhsNbyf0jIYdiV1oAUDT3f7SqAzm/palYYnhWPIB3Fa7eL ZaQzKVylD4asXi3qHmYHPn6DFjlo214zyUTRAFST9D5FP0LwpyIfhgbncCJNcE9ixV Z715vG2eKyStcwwsKxmyHHBdBOaCTL6/aidCLlnpLq+oxl5Wh+R6shqcemnKlvBVNd M1XORwJHd8hdjfqlHpu6Xbnx27pXdb8FH9QnRpn9WI5CwXEatgiD20qM6+F139lQ26 lzGEph0luyHWw== Message-ID: <7dcf62c9-e670-454a-8c4b-37116479fb3b@kernel.org> Date: Fri, 4 Jul 2025 21:58:59 +0200 Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: Daniel Gomez Subject: Re: [PATCH] Makefile: Add support for user makefile params To: Chuck Lever , Luis Chamberlain Cc: kdevops@lists.linux.dev, Daniel Gomez References: <20250704-b4-params-v1-1-42dd4ff478b3@samsung.com> <585de3f6-c604-433c-bbce-8f686c6afb33@oracle.com> Content-Language: en-US From: Daniel Gomez Organization: kernel.org In-Reply-To: <585de3f6-c604-433c-bbce-8f686c6afb33@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04/07/2025 17.26, Chuck Lever wrote: > On 7/4/25 7:26 AM, Daniel Gomez wrote: >> From: Daniel Gomez >> >> Introduce a params.mk file for user-defined Makefile parameters. >> Users can refer to params.mk.sample to see the available configuration >> options and create their own params.mk accordingly. When enabled via >> Kconfig, a params.mk will be automatically generated at the specified >> directory using the sample as a template. When enabled, >> Makefile will attempt to include params.mk if it exists. >> >> Example: Enable Makefile verbosity and Ansible Verbosity Level 4. >> >> File: params.mk >> >> V = 1 >> AV = 4 >> >> Signed-off-by: Daniel Gomez >> --- >> We use GNU Make as a wrapper mainly for Kconfig and Ansible. In order >> to assist kdevops users to change certain options we expose certain >> features to the cli interface via Makefile parameters. A few examples >> are the verbosity of the ansible-playbook command (-v, -vv...) via AV >> parameter. Or the Linux tree git reference (Kconfig) to be used via >> LINUX_TREE_REF. This seems convenient and has been increasing over time. >> Enough parameters have been added than I personally tend to forget >> the exact variable/argument/parameter names. For that, documentation >> may be best but when using a large combination of these options, the >> cli becomes inconvenient by itself. To help with command cli parameters, >> this patch adds a file params.mk.sample that will generate a params.mk >> (if it doesn't exist already) with all parameters disabled. But the file >> will contain examples of how to use each of the options available via >> cli interface. The main Makefile will parse this first and will make it >> available as if the user would pass them through the command line making >> it easier to handle, specially when multiple options are used. >> >> Thoughts? I meant to send this as RFC but I forgot to change the prefix before sending. I'll keep as is for the next iterations. > > Why is a new Kconfig option needed? Instead, can the param.mk file > either exist or not, and "make" will work either way? I agree. At first, I had it disabled by default in the new Kconfig option. But I don't see why not having always this feature (no kconfig needed). If the file is not present then, it will create one based on the sample file and everything would be comment it out. > > > I'm glad to see the comments documenting each variable in the sample > file. Some of these I did not know about before. Are they documented > somewhere else as well? Having them all in one place is great. I think documentation may be spread. But adding a standalone documentation file for cli + the sample config is not incompatible. I'll work on that. > > But, the use of "[ section name ]" suggests this file might be an > INI file, though it's actually just "VAR = value" with comments. A > block comment at the top that explains the format would be helpful, > and perhaps find a different way of demarcating the sections. Thanks for the suggestion and examples. Makes sense to me.