Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] select and depends on for libraries
Date: Wed, 28 Mar 2012 23:01:40 +0200	[thread overview]
Message-ID: <201203282301.43724.arnout@mind.be> (raw)
In-Reply-To: <20120327002821.5b701e8e@skate>

On Tuesday 27 March 2012 00:28:21 Thomas Petazzoni wrote:
> Hello,
> 
> We typically use "select" to mark at the Kconfig level the dependencies
> between a package and its libraries. However, when such a dependency
> has some "depends on" dependencies, they must be replicated at the
> level of all packages that are selecting this dependency, i.e:
> 
> config FOO
> 	bool
> 
> config PACKAGE_A
> 	depends on FOO
> 
> config PACKAGE_B
> 	select PACKAGE_A
> 	depends on FOO # we must have this dependency
> 
> I now have the case of libffi. libffi cannot be built for various
> architectures, for example Blackfin (see
> http://autobuild.buildroot.org/results/3db2d6c1e77b2c6460bd8187588a3590a4329aaf/build-end.log).
> libffi being inherently architecture-specific, adding support for new
> architectures is not a two-lines fix. So, BR2_PACKAGE_LIBFFI should
> "depends on !BR2_bfin".
> 
> Unfortunately, libglib2 depends on libffi. So libglib2 would also have
> to carry the "depends on !BR2_bfin". And also the ~30 packages that
> "select BR2_PACKAGE_LIBGLIB2". And the absolutely enormous number of
> packages that "select BR2_PACKAGE_LIBGLIB2", either directly or
> indirectly.
> 
> Do we really want to do this?

 We don't really want to do this, but what's the alternative?

- Fix Kconfig to proporly handle mixed select/depend.  But that implies to 
either fork the kernel's Kconfig completely, or to upstream it.

- Don't use 'select', ever.  But than we have to modify even more packages,
and it's much less convenient to use.

- Treat libglib2 as one of the 'big features' like the toolchain options,
but that doesn't really change the problem (all dependents still have to
be updated to add a comment).

- Generate the Config.in files from some meta-format, so that the
generator can take care of depends propagation.  Definitely more work
than modifying Kconfig itself :-)


 I don't see a good solution :-(



 A workaround is the following:

- remove the 'depends on !BR2_bfin' from libffi;

- add the following to libffi.mk:
ifeq ($(BR2_bfin),y)
$(error libffi does not support Blackfin)
endif

- in the autobuild scripts, detect this type of error and ignore it.



 On the longer term I'm afraid it will boil down to fixing Kconfig.
But I guess that's hard, otherwise it would have been done already.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

      reply	other threads:[~2012-03-28 21:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-26 22:28 [Buildroot] select and depends on for libraries Thomas Petazzoni
2012-03-28 21:01 ` Arnout Vandecappelle [this message]

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=201203282301.43724.arnout@mind.be \
    --to=arnout@mind.be \
    --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