Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Installation of package files in staging and target
Date: Tue, 12 Jul 2011 00:01:17 +0200	[thread overview]
Message-ID: <20110712000117.3af73a1a@skate> (raw)

Hello,

Currently, each userspace package is allowed to install files in both
the staging directory and the target directory.

Typically, a "program" package will install its program(s) only in the
target directory, while a "library" package will install its library
and headers in the staging directory and in the target directory (the
headers, static libraries and other useless files are removed using
global mechanisms before creating the target filesystem image).

I have just sent a patch that proposes to enable debugging symbols by
default when building packages. This would currently ensure that all
libraries installed in 'staging' have debugging symbols. However,
programs would be built with debugging symbols, but as they are only
installed in 'target', the final binary would still be stripped.

I'd like to propose the following scheme :

 * The packages no longer install files in staging and target
   differently. They just install files.

 * All files are installed in both the staging and the target
   directory, by the package infrastructure.

 * The files in the staging directory are left untouched.

 * Some automatic cleanup is done in the target directory :
    - Stripping of binaries and libraries
    - Removal of static libraries, pkg-config files, header files,
      documentation, etc.
    - Removal of files listed in a per-package <pkg>_REMOVE_TARGET
      variable.

This would make the target directory be a cleaned up and stripped
*subset* of the staging directory. We would therefore have in the
staging directory the libraries *and* binaries with debugging symbols
for all packages.

What do you think about this ?

Of course, this is not something that is going to be implemented right
now. I'm just opening the discussion to see if this makes sense, and if
so, how we could move forward.

Regards,

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

             reply	other threads:[~2011-07-11 22:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-11 22:01 Thomas Petazzoni [this message]
2011-07-11 22:22 ` [Buildroot] Installation of package files in staging and target Yann E. MORIN
2011-07-12 10:55 ` Quotient Remainder
2011-07-12 11:51   ` Thomas Petazzoni
2011-07-12 15:23     ` Quotient Remainder
2011-07-12 17:39       ` Yann E. MORIN
2011-07-12 19:48         ` Quotient Remainder
2011-07-12 20:46           ` Yann E. MORIN
2011-07-12 21:45             ` Quotient Remainder
2011-07-13 12:54               ` Quotient Remainder
2011-07-14 16:30                 ` Quotient Remainder
2011-07-15 15:19                 ` Alper YILDIRIM

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=20110712000117.3af73a1a@skate \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox