Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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
========================================================================

  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