All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] On the semantic of BR2_HAVE_DEVFILES
Date: Thu, 23 Dec 2010 08:43:01 +0100	[thread overview]
Message-ID: <20101223084301.3bb4ed6e@surf> (raw)
In-Reply-To: <87wrn1tsjw.fsf@macbook.be.48ers.dk>

On Wed, 22 Dec 2010 22:18:43 +0100
Peter Korsgaard <jacmet@uclibc.org> wrote:

> This (and the rest of the series) should presumably only be done if
> !BR2_HAVE_DEVFILES?

Well, BR2_HAVE_DEVFILES is quite a mess, and it'd be good to clarify
what packages should do or do not regarding BR2_HAVE_DEVFILES. I
volunteer to summarize the outcome of the discussion and put that
summary into the documentation.

What I find odd is that :

 * On one side, when BR2_HAVE_DEVFILES is defined, in target-finalize,
   we don't remove .a, .la, header files, etc.

 * On the other side, when BR2_HAVE_DEVFILES is defined, in the same
   target-finalize, we also copy the .a, .la and headers files from the
   $(STAGING_DIR) to the $(TARGET_DIR).

So it really isn't clear what packages should do :

 * Should they install everything in $(TARGET_DIR), including
   development files (.a, .la and headers), and let target-finalize
   clean-up the unnecessary bits

 * Should they not install development files in $(TARGET_DIR), and rely
   on target-finalize to copy them back from $(STAGING_DIR)

Let's try to make one proposal as a starting point for the discussion:

 * All packages should install everything in $(TARGET_DIR), including
   development files

 * All packages should add to a <pkg>_EXTRA_DEVFILES variables the
   development files that are non-standard (i.e not headers or .a, .la
   files), so things like *-config scripts.

 * In target-finalize, when BR2_HAVE_DEVFILES is not selected, we
   remove all development files (as we do, but also the list of files
   in all <pkg>_EXTRA_DEVFILES). Note that with Lionel's work on
   packages, this clean-up phase will happen directly after the package
   installation, but that doesn't make much of a difference.

And we get rid of the copy thing that happens in target-finalize when
BR2_HAVE_DEVFILES is selected.

Obviously, with this scheme, switching from !BR2_HAVE_DEVFILES to
BR2_HAVE_DEVFILES involved a complete rebuild. But that does not seem
unreasonable.

Thoughts ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2010-12-23  7:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-22 17:25 [Buildroot] [pull request] Pull request for branch for-2011.02/remove-config-scripts Thomas Petazzoni
2010-12-22 17:25 ` [Buildroot] [PATCH 1/7] imagemagick: add patch to fix libxml2 issue and remove useless patch Thomas Petazzoni
2010-12-22 21:15   ` Peter Korsgaard
2010-12-23  7:33     ` Thomas Petazzoni
2010-12-22 17:25 ` [Buildroot] [PATCH 2/7] imagemagick: remove *-config scripts from TARGET_DIR Thomas Petazzoni
2010-12-22 21:18   ` Peter Korsgaard
2010-12-23  7:43     ` Thomas Petazzoni [this message]
2010-12-23  8:55       ` [Buildroot] On the semantic of BR2_HAVE_DEVFILES Peter Korsgaard
2010-12-22 17:25 ` [Buildroot] [PATCH 3/7] neon: remove neon-config script from TARGET_DIR Thomas Petazzoni
2010-12-22 17:25 ` [Buildroot] [PATCH 4/7] libdnet: remove dnet-config " Thomas Petazzoni
2010-12-22 17:25 ` [Buildroot] [PATCH 5/7] libpng: remove libpng*-config scripts " Thomas Petazzoni
2010-12-22 17:25 ` [Buildroot] [PATCH 6/7] libxml2: remove xml2-config script " Thomas Petazzoni
2010-12-22 17:25 ` [Buildroot] [PATCH 7/7] libxslt: remove xslt-config " Thomas Petazzoni

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=20101223084301.3bb4ed6e@surf \
    --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.