From: Alsey Miller <alseycmiller@gmail.com>
To: James Hilliard <james.hilliard1@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>,
buildroot <buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH 1/4] package/pkg-cmake: allow overriding toolchain
Date: Tue, 29 Mar 2022 16:19:33 -0700 [thread overview]
Message-ID: <057A8C3C-8DAC-46A3-86AB-2DAA92A9368B@gmail.com> (raw)
In-Reply-To: <CADvTj4rQnote1-uhWj6SEuddjFoEt2sPmcAnvR=_1ugrtve81A@mail.gmail.com>
I’ve submitted a new series of patches that I’ve tested with your patch. So the `LIBDISPATCH_SUPPORTS_CMAKE_TOOLCHAIN` line is remove and all `pkg-cmake` changes.
> On Mar 29, 2022, at 1:10 PM, James Hilliard <james.hilliard1@gmail.com> wrote:
>
> On Tue, Mar 29, 2022 at 1:58 PM Alsey Miller <alseycmiller@gmail.com> wrote:
>>
>> That commit is not merged and only seems to override the C flags. How can we force cmake to use Clang for target packages? I would be fine with basing my work that patch if support for using Clang and as the C and C++ compiler is added.
>
> It should allow overriding any of the toolchain variables like this:
> https://patchwork.ozlabs.org/project/buildroot/patch/20220322232224.2842266-6-james.hilliard1@gmail.com/
>
> I think this will pretty much work as is with your libdispatch patch:
> https://patchwork.ozlabs.org/project/buildroot/patch/20220329185059.943889-2-alseycmiller@gmail.com/
>
> It should allow you to drop this part:
> LIBDISPATCH_SUPPORTS_CMAKE_TOOLCHAIN = NO
>
> You might also be able to drop some of the other conf opts since the toolchain
> file can then still be used with partial overrides.
>
>>
>>> On Mar 29, 2022, at 12:26 PM, James Hilliard <james.hilliard1@gmail.com> wrote:
>>>
>>> On Tue, Mar 29, 2022 at 1:18 PM Alsey Miller <alseycmiller@gmail.com> wrote:
>>>>
>>>> This change is necessary because if you specify the toolchain it will always use the GCC toolchain and C flags instead of the Clang cross compiler and custom C flags. This is not an issue for host packages, only for target.
>>>
>>> I think this is probably a better way of dealing with the issue:
>>> https://patchwork.ozlabs.org/project/buildroot/patch/20220322232224.2842266-5-james.hilliard1@gmail.com/
>>>
>>>>
>>>>> On Mar 29, 2022, at 11:50 AM, Alsey Coleman Miller <alseycmiller@gmail.com> wrote:
>>>>>
>>>>> Signed-off-by: Alsey Coleman Miller <alseycmiller@gmail.com>
>>>>> ---
>>>>> package/pkg-cmake.mk | 25 ++++++++++++++++++++++++-
>>>>> 1 file changed, 24 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/package/pkg-cmake.mk b/package/pkg-cmake.mk
>>>>> index 3b1db35fb6..9b36ee2b47 100644
>>>>> --- a/package/pkg-cmake.mk
>>>>> +++ b/package/pkg-cmake.mk
>>>>> @@ -57,7 +57,7 @@ $(2)_INSTALL_STAGING_OPTS ?= DESTDIR=$$(STAGING_DIR) install/fast
>>>>> $(2)_INSTALL_TARGET_OPTS ?= DESTDIR=$$(TARGET_DIR) install/fast
>>>>>
>>>>> $(3)_SUPPORTS_IN_SOURCE_BUILD ?= YES
>>>>> -
>>>>> +$(3)_SUPPORTS_CMAKE_TOOLCHAIN ?= YES
>>>>>
>>>>> ifeq ($$($(3)_SUPPORTS_IN_SOURCE_BUILD),YES)
>>>>> $(2)_BUILDDIR = $$($(2)_SRCDIR)
>>>>> @@ -82,6 +82,7 @@ ifeq ($(4),target)
>>>>> # documented as a standard CMake variable. If a package supports it,
>>>>> # it must handle it explicitly.
>>>>> #
>>>>> +ifeq ($(3)_SUPPORTS_CMAKE_TOOLCHAIN),YES)
>>>>> define $(2)_CONFIGURE_CMDS
>>>>> (mkdir -p $$($$(PKG)_BUILDDIR) && \
>>>>> cd $$($$(PKG)_BUILDDIR) && \
>>>>> @@ -104,6 +105,28 @@ define $(2)_CONFIGURE_CMDS
>>>>> )
>>>>> endef
>>>>> else
>>>>> +define $(2)_CONFIGURE_CMDS
>>>>> + (mkdir -p $$($$(PKG)_BUILDDIR) && \
>>>>> + cd $$($$(PKG)_BUILDDIR) && \
>>>>> + rm -f CMakeCache.txt && \
>>>>> + PATH=$$(BR_PATH) \
>>>>> + $$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
>>>>> + -DCMAKE_INSTALL_PREFIX="/usr" \
>>>>> + -DCMAKE_COLOR_MAKEFILE=OFF \
>>>>> + -DBUILD_DOC=OFF \
>>>>> + -DBUILD_DOCS=OFF \
>>>>> + -DBUILD_EXAMPLE=OFF \
>>>>> + -DBUILD_EXAMPLES=OFF \
>>>>> + -DBUILD_TEST=OFF \
>>>>> + -DBUILD_TESTS=OFF \
>>>>> + -DBUILD_TESTING=OFF \
>>>>> + -DBUILD_SHARED_LIBS=$$(if $$(BR2_STATIC_LIBS),OFF,ON) \
>>>>> + $$(CMAKE_QUIET) \
>>>>> + $$($$(PKG)_CONF_OPTS) \
>>>>> + )
>>>>> +endef
>>>>> +endif
>>>>> +else
>>>>>
>>>>> # Configure package for host
>>>>> define $(2)_CONFIGURE_CMDS
>>>>> --
>>>>> 2.35.1
>>>>>
>>>>
>>>> _______________________________________________
>>>> buildroot mailing list
>>>> buildroot@buildroot.org
>>>> https://lists.buildroot.org/mailman/listinfo/buildroot
>>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2022-03-29 23:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-29 18:50 [Buildroot] [PATCH 1/4] package/pkg-cmake: allow overriding toolchain Alsey Coleman Miller
2022-03-29 18:50 ` [Buildroot] [PATCH 2/4] package/libdispatch: add libdispatch package Alsey Coleman Miller
2022-03-29 18:50 ` [Buildroot] [PATCH 3/4] package/libdispatch: add fix for 32-bit arm Alsey Coleman Miller
2023-02-06 11:26 ` Arnout Vandecappelle
2022-03-29 18:50 ` [Buildroot] [PATCH 4/4] DEVELOPERS: add Alsey Miller for libdispatch Alsey Coleman Miller
2022-03-29 19:17 ` [Buildroot] [PATCH 1/4] package/pkg-cmake: allow overriding toolchain Alsey Miller
2022-03-29 19:26 ` James Hilliard
2022-03-29 19:58 ` Alsey Miller
2022-03-29 20:10 ` James Hilliard
2022-03-29 23:19 ` Alsey Miller [this message]
2022-06-20 23:14 ` James Hilliard
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=057A8C3C-8DAC-46A3-86AB-2DAA92A9368B@gmail.com \
--to=alseycmiller@gmail.com \
--cc=buildroot@buildroot.org \
--cc=james.hilliard1@gmail.com \
--cc=s.martin49@gmail.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