Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] KConfig Proposal

Hi Sergey,
As far as putting it into the CDT project, it's simply because the projects that use KConfig (that I know of) are C/C++ based. That's why I was wondering on the call if CDT wanted it. I have no real idea of which CDT users are working on what, but I'd be interested to hear. Here, all the internal devs use kconfig, which is why it's in our product first.
Thanks,
Jason

From: "Sergey Prigogin" <eclipse.sprigogin@xxxxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Sent: Wednesday, December 5, 2012 12:14:43 PM
Subject: Re: [cdt-dev] KConfig Proposal

Hi Jason,
What are the advantages of having the KConfig tool as part of CDT as opposed to a separate project? Do you have an estimate of the percentage of current CDT users who would benefit from the KConfig tool?

-sergey

On Wed, Dec 5, 2012 at 10:55 AM, Jason Litton <jason@xxxxxxxxxxxxxxx> wrote:
Hi all,
Doug asked me to send a proposal to the mailing list yesterday. He suggested the KConfig tool be an optional feature. I've never written this kind of proposal before, so if there's info missing or you want more, please let me know. I'll be as responsive as I can.

Need: CDT provides debugging tools for C, C++ based projects, many of which use the KConfig standard (defined at http://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt) to generate menus and configuration files, which are then pulled in during build. Currently, the only way to access project specific configuration menus is through the command line (usually using make menuconfig). CDT, as an IDE is missing an important link in the develop/build/deploy chain.

Proposed solution:
CDT should provide a view that can:
1) Perform all file operations necessary to load and parse a KConfig tree.
2) Use the generated tree to create menus on the fly, since KConfig menus are dynamic.
3) Dynamically reload menus as options change to account for dependencies in the KConfig variables.
4) Provide defense against improperly formatted KConfig files. There is no error checking in KConfig right now, so devs are pretty loose with the standards.
5) Load a previous configuration file at load time and apply previously selected options to the current tree.
6) Generate a configuration file that is functionally equivalent to a configuration file generated by the command line utility.

Current Status:
I've built a tool that meets the above requirements. It's in test now and looking good. It is in a layer above CDT, so it uses some internal Util stuff we provide for convenience, but that can be pretty easily ported. It's also been built for Indigo, but according to the Platform group, moving it from Indigo to Juno *should* be just drag and drop (though I'll believe it when I see it). In short, I have to do some code scrubbing to push it to CDT, but it's not a Herculean effort.

Thanks,
Jason

 

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top