make menuconfig时出现 #include CURSES_LOC错误

本文介绍了在Ubuntu系统中遇到的编译配置错误问题及解决方案。该错误源于系统缺失ncurses-devel套件,导致编译过程中无法找到必要的curses.h文件。通过安装libncurses5-dev库可以有效解决这一问题。

In file included from scripts/kconfig/lxdialog/checklist.c:24:0:

scripts/kconfig/lxdialog/dialog.h:31:20: fatal error: curses.h: 没有那个文件或目录

 #include CURSES_LOC

                    ^

compilation terminated.

make[2]: *** [scripts/kconfig/lxdialog/checklist.o] 错误 1

make[1]: *** [menuconfig] 错误 2

make: *** [menuconfig] 错误 2


这是因为ubuntu系统中缺少一个套件 ncurses devel

sudo apt-get install libncurses5-dev


转自:  http://xouou.iteye.com/blog/2154702

<think>嗯,用户这次的问题集中在Linux驱动开发中的条件编译逻辑,特别是两种不同触摸屏配置的头文件包含问题。从用户引用的代码片段来看,ta应该是在阅读或修改GSL触摸屏驱动代码,可能遇到了不同型号的配置兼容性问题。用户似乎已经有一定的内核驱动开发经验,因为ta能准确指出Makefile中的条件编译语句和头文件中的配置数组。但ta对条件编译中如何选择不同头文件的逻辑还不明确,这其实是Kconfig和Makefile协同工作的经典机制。我注意到用户引用了两段驱动代码:一段是Makefile的条件编译,另一段是头文件中的硬件配置数组。这说明ta的问题很具体——就是想知道当CONFIG_TOUCHSCREEN_GSLX680和CONFIG_TOUCHSCREEN_GSL_CC600P这两个宏被定义,驱动代码如何包含正确的头文件。这个问题需要从三个层面解释:首先是Kconfig的配置生成逻辑,然后是Makefile的条件编译,最后是C代码中的预处理器指令。用户特别关注头文件包含部分,所以重点应该放在#ifdef的应用场景上。那些#ifdefined(CONFIG_XX)||defined(CONFIG_YY)的用法在实际驱动代码中很常见,用示例说明会更直观。用户没有提供具体的头文件代码,所以需要举出典型的代码结构例子。考虑到内核驱动的规范性,gslX680.h和gsl_cc600p.h这样的命名是合理的推测。另外补充文件路径的说明也很重要,因为内核驱动通常有严格的目录结构。对了,用户提到的“gslx680_pad.h”很关键,这说明不同型号可能共享部分基础头文件。这点在回答需要强调,可以补充说明驱动开发者常通过#ifdef隔离差异代码,再包含公共头文件的做法。不过用户没问这么深,当前回答的深度应该就够了。</think> 理解条件编译中不同触摸屏配置的头文件包含逻辑需结合Linux内核的Kconfig构建系统和C语言的预处理器指令。以下是核心逻辑解析: ### 一、配置逻辑层级 1. **Kconfig定义** - 在`Kconfig`文件中定义配置选项: ```kconfig config TOUCHSCREEN_GSLX680 bool "GSLX680 Touchscreen" help Enable support for GSLX680 touch controller config TOUCHSCREEN_GSL_CC600P bool "GSL CC600P Touchscreen" help Enable support for GSL CC600P touch controller ``` - 用户通过`make menuconfig`选择编译选项自动生成`.config`文件 2. **Makefile条件编译** - 驱动目录的Makefile根据`.config`决定编译对象: ```makefile obj-$(CONFIG_TOUCHSCREEN_GSLX680) += gslx680.o obj-$(CONFIG_TOUCHSCREEN_GSL_CC600P) += gsl_cc600p.o ``` ⇒ 当宏被设置为`y`或`m`,对应驱动才会编译[^1] ### 二、头文件包含机制 1. **驱动源文件中的预处理逻辑** - 在C文件(如`gslx680.c`)开头通过宏控制头文件包含: ```c #ifdef CONFIG_TOUCHSCREEN_GSLX680 #include "gslX680.h" #elif defined(CONFIG_TOUCHSCREEN_GSL_CC600P) #include "gsl_cc600p.h" #endif ``` - 或使用更灵活的包含方式: ```c #if defined(CONFIG_TOUCHSCREEN_GSLX680) || \ defined(CONFIG_TOUCHSCREEN_GSL_CC600P) #include "gsl_common.h" // 公共头文件 #endif ``` 2. **配置数据的差异化处理** - 在头文件中通过宏隔离芯片特定配置: ```c // gsl_config.h #ifdef CONFIG_TOUCHSCREEN_GSLX680 static unsigned int config_data[] = { 0x8a44e0, 0x200, ... // X680专用配置 }; #elif defined(CONFIG_TOUCHSCREEN_GSL_CC600P) static unsigned int config_data[] = { 0x9b01f0, 0x300, ... // CC600P专用配置 }; #endif ``` 如思立微触屏的配置数组[^2] ### 三、执行流程示例 ```mermaid graph TD A[用户menuconfig选择] --> B(生成.config) B --> C{Makefile解析} C --> |CONFIG_GSLX680=y| D[编译gslx680.o] C --> |CONFIG_GSL_CC600P=m| E[编译gsl_cc600p.ko] D --> F[gslx680.c包含gslX680.h] E --> G[gsl_cc600p.c包含gsl_cc600p.h] ``` ### 四、关键设计原则 1. **编译隔离性** - 通过`#ifdef`确保不同驱动的代码/配置不会相互干扰 - 避免未启用驱动的代码占用空间 2. **芯片差异封装** - 硬件相关配置(如寄存器地址)严格隔离在宏保护块内 - 公共功能提取到`gsl_common.h`等共享文件 > 注:实际项目中常采用`gslx680_pad.h`类头文件集中管理配置数据,通过条件编译注入不同芯片参数[^2],这种设计符合Linux驱动"配置与代码分离"的最佳实践。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值