Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool
Date: Wed, 16 Oct 2019 21:01:29 +0200	[thread overview]
Message-ID: <20191016210129.4043da12@windsurf.home> (raw)
In-Reply-To: <CADYdroMp8GzXS+zQ0a+T-eeqDiMggbybn+gu6H4Y2x-d4GTkdA@mail.gmail.com>

Hello,

On Wed, 16 Oct 2019 18:28:02 +0200
Norbert Lange <nolange79@gmail.com> wrote:

> > Thanks for this, however I don't think we will ever merge this until a
> > system-provided meson can effectively be used.  
> 
> Well I do effectively use it, meson and its dependencies multiply my build-time,
> builds systemd and my libfuse3 package fine.
> 
> Patch #1 is a freestanding improvement, I hope there arent issues with merging
> at least that one?

Yes, of course PATCH 1/4 is totally independent from this discussion,
and can/will be considered separately. I looked at it briefly, I
haven't made up my mind yet, but I agree it is completely separate.

> > What about working on merging
> > 0001-Only-fix-RPATH-if-install_rpath-is-not-empty.patch to upstream
> > Meson, in this form or another form ? This would definitely pave the
> > way to using the system-provided Meson.  
> 
> I'm in no way involved with meson, AFAIK this was proposed for upstream already?

You don't have to be involved with Meson to work on it. Many of us
regularly contribute patches to upstream projects without being
involved in any way with those projects.

> > Another (more useful ?) thing to look at: is it possible to use the
> > system-provided Python for Meson and Ninja, when python3 is provided by
> > the system ? I think Meson and Ninja by themselves are not long at all
> > to build, and it would be a much more useful direction for this patch
> > series.  
> 
> Define "useful". The patches work correctly for me (tm), and I dont
> use more than 1000 included packages that are useless for me (tm).
> Even if meson is not ready (again: it is for me), then improving
> buildroot ahead of it causes no harm?

Because today meson requires a Buildroot patch, and in fact what really
adds to the build time is not building host-meson or host-ninja, but
really the fact that it requires the build of host-python3. And Python
3.x is now widely available on most build machines. So the idea would
be, instead of relying on system-provided meson/ninja, to still build
our own meson/ninja, but really the system-provided python3.

> If I were cynical, Id say I prefer spending time porting packages to
> CMake rather than trying to fix meson.

I don't think the point of this discussion is to decide whether cmake,
meson or autotools, or whatever is the best build system.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2019-10-16 19:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16 11:19 [Buildroot] allow build infrastructure to pick up installed meson tool Norbert Lange
2019-10-16 11:19 ` [Buildroot] [PATCH 1/4] package/pkg-meson: move crosscompilation support out of package Norbert Lange
2019-10-16 11:19 ` [Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool Norbert Lange
2019-10-16 13:48   ` Thomas Petazzoni
2019-10-16 16:28     ` Norbert Lange
2019-10-16 19:01       ` Thomas Petazzoni [this message]
2019-10-16 20:16         ` Yann E. MORIN
2019-10-16 20:31           ` Norbert Lange
2019-10-16 21:08             ` Thomas Petazzoni
2019-10-17 10:58               ` Norbert Lange
2019-10-16 20:22         ` Norbert Lange
2019-10-16 16:47     ` Yann E. MORIN
2019-10-16 17:22       ` Norbert Lange
2019-10-16 11:19 ` [Buildroot] [PATCH 3/4] prepare build infrastructure to pick up installed ninja tool Norbert Lange
2019-10-16 11:19 ` [Buildroot] [PATCH 4/4] support/dependencies: use a helper script for common checks Norbert Lange

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=20191016210129.4043da12@windsurf.home \
    --to=thomas.petazzoni@bootlin.com \
    --cc=buildroot@busybox.net \
    /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