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] [2010.02] Package infrastructure ready
Date: Sun, 29 Nov 2009 00:36:12 +0100	[thread overview]
Message-ID: <20091129003612.0dd95e2b@surf> (raw)

Hello,

I've now completed the work I wanted to do on the new package
infrastructures, and consider it ready for inclusion into the next
version of Buildroot, 2010.02. I'm therefore asking people to review
the patches and give their opinion and comments.

Unless there are comments, I don't plan to make any further change
before officially sending these patches, right after the 2009.11
release.

The code is available at :
 http://git.buildroot.net/~tpetazzoni/git/buildroot/log/?h=package-infrastructure

The documentation has been updated accordingly. I've put online the
corresponding version :
 http://free-electrons.com/~thomas/buildroot.html#add_packages

There are a few points on which I'd like to have your input:

 * The macro for the generic package infrastructure is named
   PKGTARGETS, and for the autotools infrastructure, the macro is named
   AUTOTARGETS. I don't particularly like this naming, but what's your
   opinion ? Do you have other proposals ? Wouldn't something like
   make-generic-package and make-autotools-package be more explicit ?
   Too long ?

 * The generic infrastructure is in package/Makefile.package.in. Maybe
   I should put it into package/Makefile.generic.in. What's your
   opinion ?

 * I have a more complicated point about how the directory containing
   the source code is referenced from the actions listed in the
   PKG_xxxx_CMDS variables.

   We can use $(@D), which is the directory that contains the stamp
   file, so it is the directory that has been extracted by the tarball.
   $(@D) is short and works well in most situations.

   The situation where $(@D) doesn't work is when the
   configure/Makefile stuff is in fact in a subdirectory of the tarball
   (and not in the root directory). In this case, the package should
   define PKG_SUBDIR = foo, and the package infrastructure will define
   PKG_SRCDIR. Therefore, the package should use $$($$(PKG)_SRCDIR)
   (double quoting needed otherwise the variable is evaluated before it
   is defined). I find this rather ugly.

   Therefore, my proposal is :

    * In the generic infrastructure, to let the .mk developer handle
      this problem. He has to use $(@D) or $(@D)/something.

    * In the autotools infrastructure, keep the PKG_SUBDIR mechanism we
      add, so that the $$($$(PKG)_SRCDIR) trick is hidden in
      Makefile.autotools.in.

Thanks for your input,

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

             reply	other threads:[~2009-11-28 23:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-28 23:36 Thomas Petazzoni [this message]
2009-12-07 21:18 ` [Buildroot] [2010.02] Package infrastructure ready Thomas Petazzoni
2009-12-07 21:33   ` Peter Korsgaard
2009-12-10 18:51     ` Thomas Petazzoni
2009-12-08 10:22   ` Will Newton

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