Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH v2 3/3] devtool: provide support for devtool menuconfig command.
Date: Tue, 05 Mar 2019 12:46:12 +1300	[thread overview]
Message-ID: <1832894.xLyTEtpz5K@localhost.localdomain> (raw)
In-Reply-To: <1548445982-25182-4-git-send-email-chandana.kalluri@xilinx.com>

On Saturday, 26 January 2019 8:53:02 AM NZDT Sai Hari Chandana Kalluri wrote:
> +def menuconfig(args, config, basepath, workspace):
> +    """Entry point for the devtool 'menuconfig' subcommand"""
> +
> +    rd = "" 
> +    kconfigpath = ""
> +    pn_src = ""
> +    localfilesdir = ""
> +    workspace_dir = ""
> +    tinfoil = setup_tinfoil(basepath=basepath)
> +    try:
> +      rd = parse_recipe(config, tinfoil, args.component, appends=True, filter_workspace=False)
> +      if not rd:
> +         return 1
> +
> +      pn =  rd.getVar('PN', True)
> +      if pn not in workspace:
> +         raise DevtoolError("Run devtool modify before calling menuconfig for %s" %pn)

Strictly speaking we have check_workspace_recipe() for this. It could be that we should extend the message printed by that to be a bit more friendly and suggest devtool add/modify/upgrade first, but I'd like to be consistent.

>...
> +      #add check to see if oe_local_files exists or not
> +      localfilesdir = os.path.join(pn_src,'oe-local-files') 
> +      if not os.path.exists(localfilesdir):
> +          bb.utils.mkdirhier(localfilesdir)
> +          #Add gitignore to ensure source tree is clean
> +          gitignorefile = os.path.join(localfilesdir,'.gitignore')
> +          with open(gitignorefile, 'w') as f:
> +                  f.write('# Ignore local files, by default. Remove this file if you want to commit the directory to Git\n')
> +                  f.write('*\n')

We should already be handling this in devtool-source.bbclass, but I'm guessing the hardlinking you're adding bypasses that, so we likely need to handle that separately during devtool modify rather than here (preferably without duplicating code).

> +    parser_menuconfig = subparsers.add_parser('menuconfig',help='allows altering the system component configuration', description='launches the make menuconfig command, allows user to make changes to configuration. creates a config fragment', group='advanced') 
> +    parser_menuconfig.add_argument('component', help='compenent to alter config')

To be consistent with other subcommands and a bit more readable this should be something like:

    parser_menuconfig = subparsers.add_parser('menuconfig', help='Alter build-time configuration for a recipe', description='Launches the "make menuconfig" command (for recipes where do_menuconfig is available), allowing you to make changes to the build-time configuration. Creates a config fragment corresponding to changes made.', group='advanced') 
    parser_menuconfig.add_argument('recipename', help='Recipe to reconfigure')

Additionally, I would really like to see some oe-selftest tests for this along with the changes.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre




  parent reply	other threads:[~2019-03-04 23:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-25 19:52 [PATCH v2 0/3] Devtool: provide easy means of reconfiguring Sai Hari Chandana Kalluri
2019-01-25 19:53 ` [PATCH v2 1/3] devtool modify: Update devtool modify to copy source from work-shared if its already downloaded Sai Hari Chandana Kalluri
2019-03-04 23:46   ` Paul Eggleton
2019-01-25 19:53 ` [PATCH v2 2/3] devtool modify: Create a copy of kernel source within work-shared if not present Sai Hari Chandana Kalluri
2019-01-25 19:53 ` [PATCH v2 3/3] devtool: provide support for devtool menuconfig command Sai Hari Chandana Kalluri
2019-02-07 17:07   ` Chandana Kalluri
2019-03-04 23:46   ` Paul Eggleton [this message]
2019-03-11 21:19     ` Chandana Kalluri

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=1832894.xLyTEtpz5K@localhost.localdomain \
    --to=paul.eggleton@linux.intel.com \
    --cc=chandana.kalluri@xilinx.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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