From: Robert P. J. Day <rpjday@crashcourse.ca>
To: buildroot@busybox.net
Subject: [Buildroot] a philosophical question about Config.in and "comment" directives
Date: Fri, 17 Apr 2015 12:28:55 -0400 (EDT) [thread overview]
Message-ID: <alpine.LFD.2.11.1504171224440.12726@localhost> (raw)
In-Reply-To: <55313266.9000600@mind.be>
On Fri, 17 Apr 2015, Arnout Vandecappelle wrote:
> On 17/04/15 17:00, Yann E. MORIN wrote:
> > Rovert, All,
> >
> > On 2015-04-17 08:58 -0400, Robert P. J. Day spake thusly:
> > [--SNIP--]
> >> to distinguish between these two "levels" of dependency, i think it
> >> would be far clearer to rewrite a file like that as:
> >>
> >> if BR2_arm
> >>
> >> config BR2_PACKAGE_A10DISP
> >> bool "a10disp"
> >> depends on BR2_LINUX_KERNEL
> >> help
> >> Program to change the display mode of Allwinner ARM SOCs running
> >> the linux-sunxi kernel (and not the mainline kernel.)
> >>
> >> http://github.com/hglm/a10disp
> >>
> >> comment "a10disp needs a Linux kernel to be built"
> >> depends on !BR2_LINUX_KERNEL
> >>
> >> endif
> >>
> >> that layout makes it far clearer that the entire option depends on
> >> arm or you see *nothing* and, further, internally, the dependencies
> >> in the comment list *only* those dependencies that the user will be
> >> warned that they need if they want this selection.
>
> I completely agree.
>
> >>
> >> i just think having the dependency line
> >>
> >> depends on BR2_arm
> >>
> >> in both the config and comment directives is unnecessary duplication,
> >> and that that kind of dependency should be moved up to encompass the
> >> entire Config.in file, however that's best done.
> >>
> >> thoughts?
> >
> > Well, you are right that "it would make moere sense" from a theoretical
> > point of view, and that there is no functional difference.
i know there's no functional difference, and that's why i'm quite
prepared for people to suggest it's just meaningless code churn.
> > BTW, there are other such architectural options, like MMU, that we
> > handle the same way as well.
in fact, that was exactly the other example that jumped out at me --
the duplication of the test for BR2_USE_MMU in quite a number of
recipes. that's the test that got me thinking about this.
anyway, just my $0.02 ...
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
next prev parent reply other threads:[~2015-04-17 16:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-17 12:58 [Buildroot] a philosophical question about Config.in and "comment" directives Robert P. J. Day
2015-04-17 15:00 ` Yann E. MORIN
2015-04-17 16:18 ` Arnout Vandecappelle
2015-04-17 16:28 ` Robert P. J. Day [this message]
2015-04-17 16:35 ` Yann E. MORIN
2015-04-20 19:19 ` Peter Korsgaard
2015-04-20 19:29 ` Robert P. J. Day
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=alpine.LFD.2.11.1504171224440.12726@localhost \
--to=rpjday@crashcourse.ca \
--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