All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 00/30] Splitting the toolchain-external package
Date: Tue, 25 Oct 2016 16:54:04 +0200	[thread overview]
Message-ID: <20161025165404.2c91f30b@free-electrons.com> (raw)
In-Reply-To: <f0262d9f-d9e0-9690-7a51-a094dd57c06b@mind.be>

Hello,

On Tue, 25 Oct 2016 16:26:19 +0200, Arnout Vandecappelle wrote:

> > Then all toolchain packages are introduced but are not yet used since
> > the new toolchain-external infra will be added latter.  
> 
>  Meh, I don't like that. You should introduce the infra and then convert the
> toolchains one by one. Or is there some reason why that is difficult?

This is not possible if you want a bisectable patch series. You can't
have some of the toolchains handled by the old stuff, and some of the
toolchains handled by the new stuff, because the entire point of the
series is to replace the toolchain-external package from a real package
to a virtual one. So this has to be done in one go. You can't have the
Linaro toolchain living as a separate package, whose build is triggered
by the toolchain-external virtual package, and at the same time the
Sourcery toolchain handled in the old way, directly within the
toolchain-external package.

I originally did the patch series, and turned this around many times,
and what Romain is proposing here is really the only reasonable way
that I could find.

> > Before introduce the new toolchain-external infra, some specific
> > functions and logic are moved into a separate file (toolchain utility,
> > toolchain wrapper, variables definition, uClibc, musl and bfin).  
> 
>  This part I don't like either. For me, splitting into separate files
> *decreases* readability and ease of use, because you have to consult these
> different files to understand what's going on. Splitting is useful when:
>  - there is a really clear separation of concerns (e.g. pkg-cmake and
> pkg-autotools are clearly unreleated);
>  - or the same "code" is "called" from several places (e.g. the pkg-generic
> infra is used both by pkg-cmake and pkg-autotools);
>  - or the file becomes really large (top-level Makefile is more than 1000 lines).
> 
>  For me, pkg-toolchain-external*.mk is all really closely related so it can go
> in one file.
> 
>  In addition, I don't like that all these pkg-toolchain-external*.mk files are
> included in no particular order from the top-level Makefile with 'include
> toolchain/*/*.mk'. In fact pkg-toolchain-external.mk defines
> toolchain-external-package and it gets used by toolchain-external.mk (that
> includes toolchain/toolchain-external/*/*.mk). So if toolchain-external.mk
> happens to get read before pkg-toolchain-external.mk, things will fail
> miserably. I believe we've had problems with that before, haven't we?
> 
>  So, my proposal would be to either keep everything together in
> toolchain-external.mk, or move pkg-toolchain-external.mk one level up (then it
> gets included before toolchain/*/*.mk).

I'm personally fine with your proposal, we can keep everything in
pkg-toolchain-external.mk, both the infrastructure itself and all its
helper functions.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2016-10-25 14:54 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-23 20:48 [Buildroot] [PATCH 00/30] Splitting the toolchain-external package Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 01/30] toolchain-external: pass CC and CFLAGS as arguments Romain Naour
2016-10-25 10:50   ` Arnout Vandecappelle
2016-10-23 20:48 ` [Buildroot] [PATCH 02/30] " Romain Naour
2016-10-25 11:07   ` Arnout Vandecappelle
2016-10-25 11:44     ` Thomas Petazzoni
2016-10-25 12:46       ` Arnout Vandecappelle
2016-10-25 12:48         ` Thomas Petazzoni
2016-10-25 12:57           ` Arnout Vandecappelle
2016-10-23 20:48 ` [Buildroot] [PATCH 03/30] toolchain-external: pass arguments CROSS to install wrapper Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 04/30] toolchain-external: pass arguments CC, CFLAGS, INSTALL_DIR while installing gdbserver Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 05/30] toolchain-external-blackfin-uclinux: new package Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 06/30] toolchain-external-arago-armv7a: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 07/30] toolchain-external-arago-armv5te: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 08/30] toolchain-external-custom: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 09/30] toolchain-external-linaro-aarch64: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 10/30] toolchain-external-linaro-arm: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 11/30] toolchain-external-linaro-armeb: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 12/30] toolchain-external-musl-cross: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 13/30] toolchain-external-codesourcery-aarch64: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 14/30] toolchain-external-codesourcery-arm: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 15/30] toolchain-external-codesourcery-mips: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 16/30] toolchain-external-codesourcery-niosII: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 17/30] toolchain-external-codesourcery-sh: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 18/30] toolchain-external-codesourcery-x86: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 19/30] toolchain-external-codesourcery-amd64: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 20/30] toolchain-external-synopsys-arc: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 21/30] toolchain-external-codescape-img-mips: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 22/30] toolchain-external-codescape-mti-mips: " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 23/30] toolchain/toolchain-external: move functions and utility logic into a separate file Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 24/30] toolchain/toolchain-external: move wrapper " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 25/30] toolchain/toolchain-external: move the definition of various variables " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 26/30] toolchain/toolchain-external: move uClibc specific logic " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 27/30] toolchain/toolchain-external: move musl " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 28/30] toolchain/toolchain-external: move bfin " Romain Naour
2016-10-23 20:48 ` [Buildroot] [PATCH 29/30] toolchain/toolchain-external: move external toolchain definition " Romain Naour
2016-10-25  9:55   ` Thomas Petazzoni
2016-10-23 20:48 ` [Buildroot] [PATCH 30/30] toolchain-external: introduce and use external toolchain infra Romain Naour
2016-10-25 10:38 ` [Buildroot] [PATCH 00/30] Splitting the toolchain-external package Thomas Petazzoni
2016-10-25 14:26 ` Arnout Vandecappelle
2016-10-25 14:54   ` Thomas Petazzoni [this message]
2016-10-25 15:11     ` Arnout Vandecappelle
2016-10-25 15:38       ` Thomas Petazzoni
2016-10-25 18:03         ` Romain Naour

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=20161025165404.2c91f30b@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.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 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.