All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <peter@korsgaard.com>
To: Romain Naour <romain.naour@gmail.com>
Cc: Julien Olivain <ju.o@free.fr>,
	"Yann E . MORIN" <yann.morin.1998@free.fr>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/2] support/dependencies: introduce BR2_HOST_CMAKE_AT_LEAST
Date: Tue, 06 Jun 2023 22:22:27 +0200	[thread overview]
Message-ID: <87cz2849z0.fsf@48ers.dk> (raw)
In-Reply-To: <20230605095607.332091-1-romain.naour@gmail.com> (Romain Naour's message of "Mon, 5 Jun 2023 11:56:06 +0200")

>>>>> "Romain" == Romain Naour <romain.naour@gmail.com> writes:

 > Some packages (e.g. libjxl) requires a quite recent cmake version,
 > that is not yet available in most distributions, especially those
 > LTS versions.

 > Currently, when we bump the minum cmake version we require, it gets
 > bumped for all packages, regardless of their own minimum required
 > version, which means that a given configuration will trigger the
 > build of our host-cmake even if the packages that require it are not
 > enabled and those that are would be content with the system-provided
 > cmake.

 > Since host-cmake can take quite some time to build, this can get a
 > bit annoying to pay the price of a host-cmake build that would
 > otherwise not be needed.

 > Some packages even use an alternative build system when available
 > since they requires a more recent version of cmake than the our
 > minum cmake version
 > (wpewebkit use Ninja: 78d499409f71d8a22b0632c8ebc06f67ee6ae6dd).

 > We introduce config options that packages can select to indicate
 > what minimal cmake version they require, and use that version as the
 > required minimal version required by the current configuration [0].

 > We would like to ensure that the currently selected minimum cmake
 > version is indeed lower (or equal) to the cmake version we package,
 > but that is not possible: dependencies.mk is parsed before we parse
 > packages, so we do not yet know the cmake version we have, and we
 > can't invert the parsing order as we need to know the requires
 > dependencies before we parse packages (so that we can build their
 > dependency rules in Makefile). So we can only add comments in both
 > places, that refer to the other location.

 > [0] note that this is yet not optimal, as in such a case, host-cmake
 > would be in the dependency chain of all cmake-based packages, even
 > for those packages that do not require it. The optimum would be for
 > each package to gain such a dependency on an as-needed basis, but
 > this is by far more complex to achieve, and would only speed up
 > cases where a single package is built from scratch (e.g. with:
 > make clean; make foo), which is not worth optimising (yet?)

 > Signed-off-by: Romain Naour <romain.naour@gmail.com>
 > Cc: Julien Olivain <ju.o@free.fr>
 > Cc: Arnout Vandecappelle <arnout@mind.be>
 > Cc: Peter Korsgaard <peter@korsgaard.com>
 > Cc: Yann E. MORIN <yann.morin.1998@free.fr>
 > Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
 > ---
 > v2: Use the commit log suggested by Yann
 >     http://lists.busybox.net/pipermail/buildroot/2023-June/668312.html

Committed, thanks.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  parent reply	other threads:[~2023-06-06 20:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-05  9:56 [Buildroot] [PATCH 1/2] support/dependencies: introduce BR2_HOST_CMAKE_AT_LEAST Romain Naour
2023-06-05  9:56 ` [Buildroot] [PATCH 2/2] package/libjxl: requires host-cmake >= 3.19 Romain Naour
2023-06-06 20:23   ` Peter Korsgaard
2023-06-14 14:53   ` Peter Korsgaard
2023-06-06 20:22 ` Peter Korsgaard [this message]
2023-06-14 14:53   ` [Buildroot] [PATCH 1/2] support/dependencies: introduce BR2_HOST_CMAKE_AT_LEAST Peter Korsgaard

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=87cz2849z0.fsf@48ers.dk \
    --to=peter@korsgaard.com \
    --cc=buildroot@buildroot.org \
    --cc=ju.o@free.fr \
    --cc=romain.naour@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=yann.morin.1998@free.fr \
    /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.