All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.