From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout01.t-online.de (mailout01.t-online.de [194.25.134.80]) by sourceware.org (Postfix) with ESMTPS id BD9DA3858CD1 for ; Sun, 10 Mar 2024 15:12:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD9DA3858CD1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=t-online.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=t-online.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BD9DA3858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=194.25.134.80 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710083563; cv=none; b=IQMu8nKNl0aQlKKCjEvYZcxfp8ONbqIX8stcUhoXJy7+x+5sOpuIsCyqYc6zVEs9KCkCAg6liR6R/swbJ/TrY1ZL2WLYYJn9yFiNSrGz1po0Kn94M9uHMiNIhTwBvG5ks65BZVTz/3IOknXgGc4wt3QJtHrFlPjB3HStooO+Aa8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710083563; c=relaxed/simple; bh=N/0R76uGVg3CxZyC5q8FwLlbk5JYmL7yuXeZUYbz2OA=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=PlVJ0BmPJU6G00qKY8cyGgX8/mlux7qQzXCTceBSOIem5Lij8A0ICUrWIDccOfmmq95iy/mIEbk4F6zXmaxQxdk0CPXkQYYRsgw5oASeqeAhLn01FqBlebcaXKzEJqc/YIP8n77OYXGWgWnqPTjOHaOQwy3OD4jgCK89LCx6Tcw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fwd72.aul.t-online.de (fwd72.aul.t-online.de [10.223.144.98]) by mailout01.t-online.de (Postfix) with SMTP id 6E4B84E1B for ; Sun, 10 Mar 2024 16:12:40 +0100 (CET) Received: from [192.168.2.102] ([87.187.47.57]) by fwd72.t-online.de with (TLSv1.3:TLS_AES_256_GCM_SHA384 encrypted) esmtp id 1rjKqs-0ZWKhM0; Sun, 10 Mar 2024 16:12:38 +0100 Subject: Re: [PATCH cygport] Add more checks of SOURCE_DATE_EPOCH To: cygwin-apps@cygwin.com References: <06513e22-04c3-d0fd-ec1a-bddd845ae926@t-online.de> <7d8f27ba-b825-4ed5-9d3b-50170e834ec6@dronecode.org.uk> <4e277f6b-882d-4aaa-bbed-bb505dec7deb@dronecode.org.uk> Reply-To: cygwin-apps@cygwin.com From: Christian Franke Message-ID: Date: Sun, 10 Mar 2024 16:12:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 SeaMonkey/2.53.16 MIME-Version: 1.0 In-Reply-To: <4e277f6b-882d-4aaa-bbed-bb505dec7deb@dronecode.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TOI-EXPURGATEID: 150726::1710083558-5101D95D-95AC880D/0/0 CLEAN NORMAL X-TOI-MSGID: 1fab0eec-bcdc-4a3f-ab35-7961909dca98 X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: Jon Turney wrote: > On 26/02/2024 19:53, Christian Franke via Cygwin-apps wrote: >> >>> Would it not make more sense to just re-export it if set? >> >> If the cygport file decides to set but not export it, there is >> possibly no need to do it. An example is smartmontools.cygport which >> passes the unexported variable as a parameter to configure. > > Ok, but exporting it is harmless there, right? I'm not aware of any corner cases where exporting would break something. But leaving the decision to the user would allow to handle such cases. It would also allow to check whether it makes a difference and if yes, which files are affected. > > >>> (so that commands like "SOURCE_DATE_EPOCH=something cygport foo" >>> work as expected?) >>> >> >> Would make no difference as the 'VAR=val CMD...' syntax already >> exports the variable to the CMD: >> >> $ unset FOO; FOO=bar sh -c 'sh -c "sh -c printenv\ FOO"' >> bar >> > Ah, right. > > So you seem to be saying that the only situation where it's set but > not exported is where it's set in the cygport. > > So we're just making people (need to remember to) explicitly write > "export SOURCE_DATE_EPOCH" in their cygport where needed? Exactly.