From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id CE53348E45 for ; Mon, 29 Jan 2024 10:21:46 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8970068D1EB; Mon, 29 Jan 2024 12:21:43 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E5A5D68CCB5 for ; Mon, 29 Jan 2024 12:21:36 +0200 (EET) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=pmJrzmK9; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id ACFB52405F2 for ; Mon, 29 Jan 2024 11:21:36 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id upvr0yVPJs7n for ; Mon, 29 Jan 2024 11:21:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1706523695; bh=oGJ4ZliY4Pb3UqWb+uUdcmvDs46pEgJ6bV8I39/0hko=; h=Subject:From:To:In-Reply-To:References:Date:From; b=pmJrzmK9dNqBCzexpcqQ7QkceAf2HfvD1ZoXrAYSyy1GpDEfv0lVjG3/GGeUuWwhM 0Fkoxt//FKhjEUdPquPsTfM0oKLqZov2sMtpZtviSxYMzWv08Q4NdQ5PiXYu1cWCVI WejOhPu/qEPbBP/ZN5It7yOIvkVRxF4LpAqlGBq/xoyyDCxLrwd5pUeCxWK9VB+ia+ /SJSD180TN+nf0T/233hYFQbqJGXHztnf7Ut1LN58EESr6J10NJR7Dnuf7z2fbmplv MubJmVQaPrMGOZITMb+1wsQZKlSXf3u3CwbeCFZkgHcB4O69lOaYDDl7lQunpu0kTg r/VIBCDLnjKEA== Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id E0AB72404E5 for ; Mon, 29 Jan 2024 11:21:35 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 19C231601B9; Mon, 29 Jan 2024 11:21:35 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <20240128174950.20735-1-anton@khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Mon, 29 Jan 2024 11:21:35 +0100 Message-ID: <170652369508.1197.9274216714495603536@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] lavc: move bitstream filters into bsf/ subdir X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting Andreas Rheinhardt (2024-01-29 10:57:19) > Anton Khirnov: > > +# add libavcodec/ to include path for bsfs > > +$(addprefix libavcodec/, $(sort $(filter bsf/%,$(OBJS_BSF-yes)))): CPPFLAGS += -I$(SRC_PATH)/libavcodec/ > > 1. Why sort? To get rid of duplicates, otherwise the flags can be added multiple times. > 2. Adding dependencies for stuff not in this folder is different from > how we do it for arch-specific stuff. Yes, but as I said in the previous email - bitstream filters tend to include more headers from libavcodec/ than code in arch/. By my count, the 96 *.[ch] files in under libavcodec/x86 only include 98 headers from libavcodec/, 1.02 per file on average. By contrast the 43 *.c files under bsf/ include 187 files from libavcodec/, which averages to 4.35 per file. So IMO it makes sense to avoid the pointless noise and busywork from adding libavcodec/ prefixes to all those includes. I would also be fine with adding -Ilibavcodec for arch files. > 3. And actually, it is worse: Imagine someone changed > h265_profile_level.c in such a way that h265_profile_level.o now relies > on stuff provided by a different translation unit. Then you need to add > said dependency to all the components that require h265_profile_level.o. > If such a dependency exists in another Makefile for a subfolder, it is > likely that this will be forgotten. > (Of course, seeing that a BSF requires h265_profile_level.o might make > the developer think twice whether it is really a good idea to add this > new code to it.) That's an argument against subfolders in general though, not against modifying include flags. And it seems to me we have an overwhelming consensus in favor of subfolders. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".