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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.