From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 7F3B8158094 for ; Sat, 16 Jul 2022 09:37:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6823BE069C; Sat, 16 Jul 2022 09:37:55 +0000 (UTC) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EDA18E069C for ; Sat, 16 Jul 2022 09:37:54 +0000 (UTC) Received: by mail-pl1-x633.google.com with SMTP id z1so5072309plb.1 for ; Sat, 16 Jul 2022 02:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:mime-version:content-disposition; bh=zgdO0urMZO6SjOJU6ngyJTHOplaRNcnBS9QeT7LdZ4w=; b=WgYK8vLqI1gIBNUyrxUP5Qpo0gN8yda1XamLgwtlV3jm1c80ZHgunl02GoF9UG6P6J iaVnCJEaqcBZFnn8Uf3R5OG4TOjyaueG9URef9vl5yijU+bQcAmusj4Fwx5ffuFf0MZD OtQSviLqMq9VSyjQMJSFuH/8J4/+0vlpymQmkzsLDqoZeHJ9wDmT9aieJZ0PcW2UGyfQ mpMNkds6W4xhGk7eUdwvl2J09uLH0GYJH33YfKbSjamyzFjffJv01EY2NcrDI6Gf9wqd HOVOwveNhhacPN0WPfKhRPafjr0roulfNTL9LPL62Lt2OjaLn6qG3EIz2sJmR2S6nLhf iFMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=zgdO0urMZO6SjOJU6ngyJTHOplaRNcnBS9QeT7LdZ4w=; b=5L6I2kG7aiUdm++MvOjE7JEecj7Fgx+nEhM/GaAJ+l9Iw3YDyVohDpO5FxHAZo2qT3 AK41J6imVDPdLfMiFR3z5qDWFh4fljPkxdwhJ2MF78dGckYfwvoQmROafuhEF6MP+eiH OhZVye83hCzvFBKXaG5SNyKXv/MGfPmu/aF46h+jhl23T9lCGv21qEA7GJrxZOXabn12 flfCfzMxhQ+B/xtMbzBGNxbwlsuEtR6viNFzzRrbVe/yubDKO9mdeSMbp1TRAgy1zdwu Gn2prjjzdskOt7r/i8ot0PNcwVDQN1c0ZiFn2ygXjpJwscnQlp7nHIyk76LOMvc4K+/i xjtQ== X-Gm-Message-State: AJIora8/3ryCbhhXJM5U1De3SldHYNkkM7CBcExAM7Z7HbKAy7fh/KJR JG1U+smhc35Z9tTb1EILSBN2Z06T2D6HTXLx X-Google-Smtp-Source: AGRyM1uvfvw1LkBg6b8VT2akERTXJGIc7Bz8LVowmlr9psWBQXoxNX7c8+Y5+ZYanzSDC9Ixu4GAaw== X-Received: by 2002:a17:902:cf06:b0:16b:cc33:5bce with SMTP id i6-20020a170902cf0600b0016bcc335bcemr18050193plg.152.1657964273969; Sat, 16 Jul 2022 02:37:53 -0700 (PDT) Received: from localhost (49.212.183.201.v6.sakura.ne.jp. [2403:3a00:202:1120:49:212:183:201]) by smtp.gmail.com with ESMTPSA id h187-20020a6283c4000000b005289e190956sm5547105pfe.177.2022.07.16.02.37.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Jul 2022 02:37:53 -0700 (PDT) Date: Sat, 16 Jul 2022 17:38:18 +0800 From: wuyy To: gentoo-soc Subject: [gentoo-soc] [xgreenlandforwyy@gmail.com: A question about BUILD_DIR variable in cmake.eclass under EAPI=8] Message-ID: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Archives-Salt: 8d9c2d50-0042-49ed-acdc-cd261295a22a X-Archives-Hash: 3c2f2517990abe30157902fb6b7b087e Hello all, Below is the my question about BUILD_DIR variable in cmake.eclass. I have previously raised it in IRC channel, but did not get it clear, so I tried to ask the author of cmake.eclass. It seems that Andreas may be busy recently and I haven't receive a reply, and I'll keep wait. Thus, I forward this question here so we can discuss it and keep a public record. If the problem is confirmed to be rather important, I think we can move the discussion to Gentoo-dev mailing list. ----- Forwarded message from wuyy ----- Date: Fri, 15 Jul 2022 16:49:45 +0800 From: wuyy To: Andreas Sturmlechner Subject: A question about BUILD_DIR variable in cmake.eclass under EAPI=8 Hello Andreas, I'm a student participating in Google Summer of Code this year, packaging ROCm. I have met a problem when using cmake.eclass, and I'm not sure whether it should be called a bug or it's just a feature, so I want to personally ask you, the author of corresponding code. As I observe the BUILD_DIR variable is no longer globally set in cmake.eclass under EAPI=8, with this change: -# ${WORKDIR}/${P}_build. -: ${BUILD_DIR:=${WORKDIR}/${P}_build} +# ${CMAKE_USE_DIR}_build (in EAPI-7: ${WORKDIR}/${P}_build). +[[ ${EAPI} == 7 ]] && : ${BUILD_DIR:=${WORKDIR}/${P}_build} +# EAPI-8: set inside _cmake_check_build_dir So I have to use this variable in ebuild after _cmake_check_build_dir which is inside cmake_src_prepare. That's not an issue in src_prepare. Also this variable can be used in following phases. Everything seems nice, until I begin debugging and polishing src_test. After a successful src_compile, I come to the src_test, which has bugs. I fixed the bug and rerun ebuild xxx src_test, but it unexpectedly failed, because BUILD_DIR is empty! To summarize, BUILD_DIR can live to other phases when phases are executed in one call, but cannot be kept if the previous steps are skipped. This is not a problem for most scenarios, but it's a bit annoying when developing and debugging ebuilds. I have to call _cmake_check_build_dir explicitly before using BUILD_DIR, although src_prepare has been run. I wonder this may be a bug, but maybe it's designed to work that way for some reasons I don't know. If you think this is a bug, I can put it on bugzilla and find a fix to it. Thank you very much! Best regards -- Yiyang Wu ----- End forwarded message ----- --