public inbox for gentoo-soc@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-soc@lists.gentoo.org
Subject: Re: [gentoo-soc] [xgreenlandforwyy@gmail.com: A question about BUILD_DIR variable in cmake.eclass under EAPI=8]
Date: Sat, 16 Jul 2022 12:15:28 +0200	[thread overview]
Message-ID: <08e9bf66f0b9a1c89448dd7a06cba08a9a935c20.camel@gentoo.org> (raw)
In-Reply-To: <YtKHCkmPrhlZ9zaW@HEPwuyy>

On Sat, 2022-07-16 at 17:38 +0800, wuyy wrote:
> 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 <xgreenlandforwyy@gmail.com> -----
> 
> Date: Fri, 15 Jul 2022 16:49:45 +0800
> From: wuyy <xgreenlandforwyy@gmail.com>
> To: Andreas Sturmlechner <asturm@gentoo.org>
> 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!
> 

Can you reproduce while running the test phase via emerge(1)?  Using
ebuild(1) is known to be buggy.

-- 
Best regards,
Michał Górny



  reply	other threads:[~2022-07-16 10:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-16  9:38 [gentoo-soc] [xgreenlandforwyy@gmail.com: A question about BUILD_DIR variable in cmake.eclass under EAPI=8] wuyy
2022-07-16 10:15 ` Michał Górny [this message]
2022-07-16 10:58   ` wuyy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=08e9bf66f0b9a1c89448dd7a06cba08a9a935c20.camel@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=gentoo-soc@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox