All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Dario Binacchi <dario.binacchi@amarulasolutions.com>,
	buildroot@buildroot.org
Subject: Re: [Buildroot] [RFC PATCH 1/1] package/automake: include .m4 files of autoconf-archive
Date: Sun, 13 Aug 2023 22:39:23 +0200	[thread overview]
Message-ID: <20230813223923.008e4347@windsurf> (raw)
In-Reply-To: <20230813124037.GX421096@scaer>

Hello,

On Sun, 13 Aug 2023 14:40:37 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> After thinking a bit on this, here's what I think we should try;
> 
> For packages that have _AUTORECONF = YES, we forcibly add
> host-autoconf-archive to their _DEPENDENCIES, and always set the macros
> search path as proposed here. Supposedly, having macros from
> autoconf-archive available should not be a cause for failure to
> successfully autorconf, otherwise that would not work on random systems
> which have it installed for other reasons, like native builds on
> standard distros; also, a missing directorry in the macro search list
> should not be a cause for failure.
> 
> Consequently, we can drop the ad-hoc dependencies in the individual
> packages, and drop the ad-hoc include directove as well.
> 
> host-autoconf-archive is a plain autocnf package, without dependencies
> (save for the autoconf machinery), and it only ever installs a buncha
> files, does not compile anything, so it is pretty fast. Adding it to all
> autoreconfigured packages should have a minimal, barely noticeable
> impact on the build time.
> 
> If the above causes too much breakage, then even this patch was going to
> be incorrect, as it would unconditionally add the autocon-archive path
> to the search list for all packages that indirectly have
> autoconf-archive in their dependencies.

We have 336 packages that set AUTORECONF = YES. Out of these 336
packages, only 8 need host-autoconf-archive.

To me, it makes no sense to add host-autoconf-archive to those 336-8
packages that need autoreconf, but do not use any of the macros
provided by host-autoconf-archive. One of Buildroot's beauty is its
minimalism: it builds only what's needed, and every time it builds
something, there is a solid reason for it. I would really dislike if we
were to start building useless dependencies, even if admittedly
host-autoconf-archive is small and quick to build. But small and quick
to build is not the only thing, it's also about whether it makes sense.
I regularly stare at my build going on, and when something gets built
that I don't understand why its gets pulled into the build, I check
with "make graph-depends" why it is there, and sometimes investigate
further to make sure there's a good justification. To me, this is an
important property of Buildroot, and I would really like to keep this
aspect of Buildroot.

Especially, I don't see what problem we would solve by making
host-autoconf-archive a dependency of all packages that do AUTORECONF =
YES. What problem would this solve?

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2023-08-13 20:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-28 11:30 [Buildroot] [RFC PATCH 1/1] package/automake: include .m4 files of autoconf-archive Dario Binacchi
2023-07-28 21:01 ` Thomas Petazzoni via buildroot
2023-07-29 14:47   ` Dario Binacchi
2023-07-29 21:03     ` Thomas Petazzoni via buildroot
2023-08-13 12:40       ` Yann E. MORIN
2023-08-13 20:39         ` Thomas Petazzoni via buildroot [this message]
2023-08-29 17:09           ` Dario Binacchi

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=20230813223923.008e4347@windsurf \
    --to=buildroot@buildroot.org \
    --cc=dario.binacchi@amarulasolutions.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.