From: Patrick Steinhardt <ps@pks.im>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org, Ed Reel <edreel@gmail.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 2/3] cmake: fix compilation of clar-based unit tests
Date: Tue, 15 Oct 2024 11:09:11 +0200 [thread overview]
Message-ID: <Zw4xNwnrLicx2nDa@pks.im> (raw)
In-Reply-To: <Zw2RNsptlkHCyTgi@nand.local>
On Mon, Oct 14, 2024 at 05:46:30PM -0400, Taylor Blau wrote:
> On Mon, Oct 14, 2024 at 04:06:44PM +0200, Patrick Steinhardt wrote:
> > The compilation of clar-based unit tests is broken because we do not
> > add the binary directory into which we generate the "clar-decls.h" and
> > "clar.suite" files as include directories. Instead, we accidentally set
> > up the source directory as include directory.
>
> I am confused. What is the difference between CMAKE_SOURCE_DIR and
> CMAKE_BINARY_DIR here, and why does the difference between the two
> matter?
This is for out-of-tree builds. The outputs generated by CMake are
written into the binary directory, which is not the source directory
where the Git source files are stored.
> > diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> > index 62af7b33d2f..093852ad9d6 100644
> > --- a/contrib/buildsystems/CMakeLists.txt
> > +++ b/contrib/buildsystems/CMakeLists.txt
> > @@ -1042,7 +1042,7 @@ file(WRITE "${CMAKE_BINARY_DIR}/t/unit-tests/clar.suite" "${clar_decls}" "${clar
> > list(TRANSFORM clar_test_SUITES PREPEND "${CMAKE_SOURCE_DIR}/t/unit-tests/")
> > list(TRANSFORM clar_test_SUITES APPEND ".c")
> > add_library(unit-tests-lib ${clar_test_SUITES} "${CMAKE_SOURCE_DIR}/t/unit-tests/clar/clar.c")
> > -target_include_directories(unit-tests-lib PRIVATE "${CMAKE_SOURCE_DIR}/t/unit-tests")
> > +target_include_directories(unit-tests-lib PUBLIC "${CMAKE_BINARY_DIR}/t/unit-tests")
>
> This also changes the 'scope' parameter of 'target_include_directories'
> from PRIVATE to PUBLIC, but the commit message doesn't mention such a
> change.
It does mention it, it's the "propagate the include directories" part.
> Is it intentional? If so, can the commit message be updated to explain
> why this is done? If not, is this a stray change that snuck in?
>
> (If all of this is obvious to you, I apologize for the confusion on my
> end. I'm not at all familiar with our CMake bits, so the extra
> explanation would help me quite a bit in making sense of this.)
That's fair. I'll clarify the message a bit to provide more context.
Patrick
next prev parent reply other threads:[~2024-10-15 9:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 3:23 Bug report Ed Reel
2024-10-14 6:10 ` Johannes Schindelin
2024-10-14 14:06 ` [PATCH 0/3] cmake: fix autogenerated clar headers Patrick Steinhardt
2024-10-14 14:06 ` [PATCH 1/3] Makefile: extract script to generate clar declarations Patrick Steinhardt
2024-10-14 21:42 ` Taylor Blau
2024-10-15 9:08 ` Patrick Steinhardt
2024-10-14 14:06 ` [PATCH 2/3] cmake: fix compilation of clar-based unit tests Patrick Steinhardt
2024-10-14 21:46 ` Taylor Blau
2024-10-15 9:09 ` Patrick Steinhardt [this message]
2024-10-14 14:06 ` [PATCH 3/3] cmake: set up proper dependencies for generated clar headers Patrick Steinhardt
2024-10-14 21:47 ` Taylor Blau
2024-10-14 21:40 ` [PATCH 0/3] cmake: fix autogenerated " Taylor Blau
2024-10-15 9:46 ` [PATCH v2 " Patrick Steinhardt
2024-10-15 9:46 ` [PATCH v2 1/3] Makefile: extract script to generate clar declarations Patrick Steinhardt
2024-10-15 19:24 ` Taylor Blau
2024-10-18 15:21 ` Toon Claes
2024-10-21 6:59 ` Patrick Steinhardt
2024-10-15 9:46 ` [PATCH v2 2/3] cmake: fix compilation of clar-based unit tests Patrick Steinhardt
2024-10-15 9:46 ` [PATCH v2 3/3] cmake: set up proper dependencies for generated clar headers Patrick Steinhardt
2024-10-15 19:25 ` [PATCH v2 0/3] cmake: fix autogenerated " Taylor Blau
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=Zw4xNwnrLicx2nDa@pks.im \
--to=ps@pks.im \
--cc=Johannes.Schindelin@gmx.de \
--cc=edreel@gmail.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
/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;
as well as URLs for NNTP newsgroup(s).