ProtoBuf是Google提出的语言中立、平台无关、可扩展的数据序列化协议。比起XML、JSON等格式它更小、更简单、更快。

使用ProtoBuf，你只需要定义消息结构一次，就可以自动生成各种语言的代码来读写消息结构。

你需要ProtoBuf编译器，才能把消息定义文件编译为各种语言的源代码。执行下面的命令安装编译器：

git clone https://github.com/google/protobuf.git
cd protobuf/
./autogen.sh
./configure --prefix=/usr
make && sudo make install
sudo ldconfig

按照上述命令安装ProtoBuf后，路径/usr/include/google/protobuf下会包含一些proto文件。

上述构建步骤完成后，你可以使用protoc命令来编译.proto文件，产生特定编程语言的代码：

protoc 
    --proto_path=IMPORT_PATH     # .proto文件中的import指令的搜索路径，默认当前目录
    # 不同语言代码的输出目录
    --cpp_out=DST_DIR 
    --java_out=DST_DIR 
    --python_out=DST_DIR 
    --go_out=DST_DIR 
    --ruby_out=DST_DIR 
    --javanano_out=DST_DIR 
    --objc_out=DST_DIR 
    --csharp_out=DST_DIR 
    # 待编译的proto文件
    path/to/file.proto

ProtoBuf在.proto文件中定义消息结构或者RPC服务。

/* ProtoBuf版本 */
syntax = "proto3";
// 导入其它消息定义文件
import "google/protobuf/timestamp.proto";
// 包名，默认对应Go的包名
package gmem;

// 定义消息，消息是一系列字段的聚合
message User {
    // 保留标签和字段名。这些是以前曾经使用，但是废弃的字段。为了保证新旧定义的兼容性，废弃的字段应该不再使用
    reserved 15, 9 to 11;
    reserved "foo", "bar";

    // 支持的数据类型：
    // bool  float double string bytes
    // 变长整数：int32 int64 uint32 uint64 sint32 sint64
    // 固定长度整数：fixed32 fixed64 sfixed32 sfixed64

    // 等于号的后面的数字必须是唯一的，作为串行化后字段的标签。1-15号字段比起16+字段串行化后少一个字节
    string stringType = 1; // A string must always contain UTF-8 encoded or 7-bit ASCII text. Default value = ""

    // Number Types, Default Value = 0
    int32 int32Type = 2; // Uses Variable Length Encoding. Inefficient For Negative Numbers, Instead Use sint32.
    int64 int64Type = 3; // Uses Variable Length Encoding. Inefficient For Negative Numbers, Instead Use sint64.
    uint32 uInt32Type = 4; // Uses Variable Length Encoding
    uint64 uInt64Type = 5; // Uses Variable Length Encoding
    sint32 sInt32Type = 6; // Uses Variable Length Encoding. They are efficient in encoding for negative numbers.
                           // Use this instead of int32 for negative numbers
    sint64 sInt64Type = 7; // Uses Variable Length Encoding. They are efficient in encoding for negative numbers.
    // Use this instead of int64 for negative numbers.

    fixed32 fixed32Type = 8; // Always four bytes. More efficient than uint32 if values are often greater than 2^28.
    fixed64 fixed64Type = 9; // Always eight bytes. More efficient than uint64 if values are often greater than 2^56

    sfixed32 sfixed32Type = 10; // Always four bytes.
    sfixed64 sfixed64Type = 11; // Always Eight bytes.

    bool boolType = 12; // Boolean Type. Default Value = false

    bytes bytesType = 13; // May contain any arbitrary sequence of bytes. Default Value = Empty Bytes

    double doubleType = 14;
    float floatType = 15;


    // 消息内部可以定义枚举，枚举本身不是字段
    enum TelType {
        MOBILE = 0;  // Tag 0 is always used as default in case of enum
        HOME = 1;
        WORK = 2;
        OTHER = 3;
    }
    // 可以内嵌消息定义，消息定义本身不是字段
    message TelNum {
        string number = 1;
        TelType type = 2;
    }
    // 如果声明repeated则字段可以重复0-N次。字段的顺序在串行时被保留
    repeated TelNum phones = 3;
    repeated string aliases = 4;

    // 多个字段，但是每个消息只会出现其中一个
    oneof version {
        string version = 5;
        int32 apiversion = 6;
    }
    // 映射格式支持，这类字段不能是repeated
    map<string, User> relatedUsers = 7;
    
    // ProtoBuf 3提供的字段类型
    google.protobuf.Timestamp dob = 8;
}

// 在Message 中可以引用其它消息类型
message Person {
    string fname = 1;
    string sname = 2;
}

message City {
    Person p = 1;
}

// Message定义可以是内嵌的
message NestedMessages {
    message FirstLevelNestedMessage {
        string firstString = 1;
        message SecondLevelNestedMessage {
            string secondString = 2;
        }
    }
    FirstLevelNestedMessage msg = 1;
    FirstLevelNestedMessage.SecondLevelNestedMessage msg2 = 2;
}

// Any类型：允许你使用消息作为嵌入类型，且不需要它们的proto定义，Any持有任意的串行化为字节数组的数字+一个代表
// 其全局唯一类型标识符的URL
import "google/protobuf/any.proto";
message AnySampleMessage {
    repeated google.protobuf.Any.details = 1;
}

// 任意值类型的映射
map<string, google.protobuf.Any>
// 类似于结构
google.protobuf.Struct

你可以在.proto中定义一个RPC服务：

service UserService {
    rpc Query (string) returns (User);
}

ProtoBuf编译器可以生成服务的（指定语言的）接口代码和桩代码。

你可以在.proto文件中声明一系列的选项，这些选项不会从根本上改变消息结构或者服务语义，但是会在特定上下文中影响编译器的行为：

// 生成的Java包名
option java_package = "cc.gmem";
// 在不同的Java文件中生成顶级消息、枚举、服务的定义
option java_multiple_files = true;
// 影响Java和C++代码生成器的行为
option optimize_for = SPEED | CODE_SIZE | LITE_RUNTIME;

对于.proto文件：

syntax = "proto3";
import "google/protobuf/timestamp.proto";
package digital;

option java_package = "com.dangdang.digital";

message Media {
    uint64 mediaId = 1;
    uint64 saleId = 2;
    string title = 3;
    uint32 chapterCnt = 4;
    uint32 wordCnt = 5;
    bool isFull = 6;
    string authorName = 7;
    string publisher = 8;
    google.protobuf.Timestamp publishDate = 9;
    uint32 price = 10;
    uint32 paperBookPrice = 11;
}

需要安装protoc-gen-go：

go get -u github.com/golang/protobuf/protoc-gen-go

注意$GOPATH/bin需要加入到PATH环境变量。

执行下面的命令将上节的.proto编译为Go代码：

cd /home/alex/Go/workspaces/default/digital-api
mkdir digital

protoc -I=proto --go_out=./digital Media.proto

生成的文件如下：

package digital

import proto "github.com/golang/protobuf/proto"
import fmt "fmt"
import math "math"
import google_protobuf "github.com/golang/protobuf/ptypes/timestamp"

// 下面的语句用于抑制unused import报错
var _ = proto.Marshal
var _ = fmt.Errorf
var _ = math.Inf

// 生成的Go结构体，注意字段名被自动大写
type Media struct {
	MediaId        uint64                     `protobuf:"varint,1,opt,name=mediaId" json:"mediaId,omitempty"`
	SaleId         uint64                     `protobuf:"varint,2,opt,name=saleId" json:"saleId,omitempty"`
	Title          string                     `protobuf:"bytes,3,opt,name=title" json:"title,omitempty"`
	ChapterCnt     uint32                     `protobuf:"varint,4,opt,name=chapterCnt" json:"chapterCnt,omitempty"`
	WordCnt        uint32                     `protobuf:"varint,5,opt,name=wordCnt" json:"wordCnt,omitempty"`
	IsFull         bool                       `protobuf:"varint,6,opt,name=isFull" json:"isFull,omitempty"`
	AuthorName     string                     `protobuf:"bytes,7,opt,name=authorName" json:"authorName,omitempty"`
	Publisher      string                     `protobuf:"bytes,8,opt,name=publisher" json:"publisher,omitempty"`
	PublishDate    *google_protobuf.Timestamp `protobuf:"bytes,9,opt,name=publishDate" json:"publishDate,omitempty"`
	Price          uint32                     `protobuf:"varint,10,opt,name=price" json:"price,omitempty"`
	PaperBookPrice uint32                     `protobuf:"varint,11,opt,name=paperBookPrice" json:"paperBookPrice,omitempty"`
}
// 为结构定义了一些方法
func (m *Media) Reset()                    { *m = Media{} }
func (m *Media) String() string            { return proto.CompactTextString(m) }
func (*Media) ProtoMessage()               {}
func (*Media) Descriptor() ([]byte, []int) { return fileDescriptor0, []int{0} }

// 为所有字段定义了Get
func (m *Media) GetMediaId() uint64 {
	if m != nil {
		return m.MediaId
	}
	return 0
}
// ...

执行下面的命令将上节的.proto编译为Java代码：

# Java包所需的目录会自动生成
protoc -I=proto --java_out=/home/alex/JavaEE/projects/idea/digital-client/src/main/java Media.proto

需要添加Maven依赖：

<dependency>
    <groupId>com.google.protobuf</groupId>
    <artifactId>protobuf-java</artifactId>
    <version>3.5.1</version>
</dependency>

media := &digital.Media{
    AuthorName:     "汪震",
    ChapterCnt:     8,
    IsFull:         true,
    MediaId:        1000000,
    PaperBookPrice: 6400,
    Price:          640,
    PublishDate:    &google_protobuf.Timestamp{Seconds: int64(time.Now().Second())},
}
// 序列化为字节
out, err := proto.Marshal(media)
if err != nil {
    log.Fatal(err)
}
log.Printf("marshalled size: %v", len(out))
fname := "/tmp/media.data"
ioutil.WriteFile(fname, out, 0644)

// 反序列化
in, err := ioutil.ReadFile(fname)
media = new(digital.Media)
proto.Unmarshal(in, media)
log.Println(media.AuthorName) 

使用Struct类型，可以方便的映射map[string]any：

var vars map[string]any

var variables *structpb.Struct
variables, err = structpb.NewStruct(vars)
if err != nil {
	return nil, err
}
return &GetInstanceVariablesResponse{
    // *_struct.Struct  对应"google/protobuf/struct.proto"的google.protobuf.Struct
	Variables: variables,
}, nil

// 要将Struct转换为map，只需要
variables.AsMap()

使用Struct类型，可以方便的映射字典：

from google.protobuf.struct_pb2 import Struct
from google.protobuf import json_format

data = {
    "id": 123,
    "name": "example"
}

struct_obj = Struct()
json_format.ParseDict(data, struct_obj)

package com.dangdang.digital;

import com.google.protobuf.Timestamp;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.junit.Test;

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;

public class ProtoBufTest {

    private static final Logger LOGGER = LogManager.getLogger( ProtoBufTest.class );

    public static final String FNAME = "/tmp/media.data";

    @Test
    public void testWrite() throws IOException {

        MediaOuterClass.Media.Builder builder =
            MediaOuterClass.Media.newBuilder()
                                 .setAuthorName( "汪震" )
                                 .setChapterCnt( 8 )
                                 .setIsFull( true )
                                 .setMediaId( 1000000 )
                                 .setPaperBookPrice( 6400 )
                                 .setPrice( 640 )
                                 .setPublishDate( Timestamp.newBuilder().setSeconds( System.currentTimeMillis() / 1000 ).build() );
        // 生成Java对象
        MediaOuterClass.Media media = builder.build();
        FileOutputStream fos = new FileOutputStream( FNAME );

        // 写入到文件
        media.writeTo( fos );
    }

    @Test
    public void testRead() throws IOException {
        FileInputStream fis = new FileInputStream( FNAME );
        MediaOuterClass.Media media = MediaOuterClass.Media.parseFrom( fis );
        LOGGER.debug( media.getAuthorName() );
    }
}

开源项目protoc-go-inject-tag支持为Protobuf生成的结构体添加自定义标签：

go get github.com/gmemcc/protoc-go-inject-tag

message Media {
    // @inject_tag: db:"media_id"
    uint64 mediaId = 1;
}

对于上述proto，执行命令：

protoc -I=proto --go_out=. Media.proto
# 生成Tag：
protoc-go-inject-tag -input=Media.pb.go -remove=true

最终的结构如下：

type Media struct {
	// @inject_tag: db:"media_id"
	MediaId uint64 `protobuf:"varint,1,opt,name=mediaId" json:"mediaId,omitempty" db:"media_id"`
} 

此项目Fork了golang/protobuf，提供了额外的代码生成器。支持特性：

1. 更快的序列化/反序列化
2. 更加规范的Go结构
3. 和goprotobuf兼容
4. 支持生成测试、Benchmark代码

要生成具有更快序列化/反序列化能力的代码，安装：

go get github.com/gogo/protobuf/protoc-gen-gofast

示例：

protoc --gofast_out=. myproto.proto

使用此特性，就不能使用任何其它的gogoprotobuf扩展。 

调用形式和golang/protobuf一样：

protoc --gofast_out=plugins=grpc:. my.proto

安装protoc-gen-gogo：

go get github.com/gogo/protobuf/proto
go get github.com/gogo/protobuf/jsonpb
go get github.com/gogo/protobuf/protoc-gen-gogo
go get github.com/gogo/protobuf/gogoproto

此扩展允许定制生成结构的JSON Tag，示例：

bool include_public = 2 [(gogoproto.jsontag) = "includePublic,omitempty"];

此命令能够解析Proto文件，然后根据你指定的选项来生成代码。

protoc [OPTION] PROTO_FILES

import "github.com/gogo/protobuf/gogoproto/gogo.proto";

-I $GOPATH/src

protoc \
    # 从这里寻找impirt
    -I$GOPATH/src  \
    # 直接指定Proto源文件
    -Ipkg/apis/chart/v1 pkg/apis/chart/v1/chart_service.proto \
    # 基于protoc-gen-gogo来生成Go代码，启用grpc支持，输出的根目录为当前目录，具体路径取决于go_package
    --gogo_out=plugins=grpc:.

插件Protobuf Support为IntelliJ平台提供了proto编辑器，完整支持Protocol Buffer 3。安装后，需要注意设置Include Path：

如果需要使用google.protobuf.Timestamp等类型，则需要将ProtoBuf安装前缀/include目录包含在列表中。

The post Protocol Buffers初探 appeared first on 绿色记忆.

PHPStorm是一个基于IntelliJ平台跨平台的PHP集成开发环境，支持从5.3到最新的7.0的PHP版本。该IDE同时包含了WebStorm的功能，因此如果购买了PHPStorm，不需要再购买WebStorm。

PhpStorm支持将工程部署到本地或者远程服务器，或者从远程服务器同步到本地。对于远程服务器，需要进行FTP或者SFTP的配置。

File ⇨ Settings，定位到B,E,D ⇨ Deployment，点击右侧面板的+号，出现类似下面的界面：

勾选Visible only for this project则其它工程无法看到此部署配置，Folder填写本地HTTP服务器的部署根目录。

切换到Mappings选项卡，可以配置工程中目录与服务器目录的映射关系：

在选项卡Excluded Paths中，可以排除掉不需要在工程、服务器之间同步的文件。

在Project窗口中，右击某个节点，或者在编辑器上右击，均可执行Upload to Server name操作，完成部署。

注意在Debug时，必须先把工程中修改的文件部署到服务器上。

File ⇨ Settings，定位到Languages & Frameworks ⇨ PHP ⇨ Debug，参考下图设置：

Run ⇨ Break at first line in PHP scripts，取消勾选，否则每个PHP文件的第一行都会中断执行，很烦人。

File ⇨ Settings，定位到Languages & Frameworks ⇨ PHP ⇨ Servers，在此对被调试的Web服务器进行配置。

注意工程目录与服务器绝对路径之间的映射关系要设置正确，PHP脚本在服务器上的绝对路径会在Debug会话中传递到PhpStorm，PhpStorm依据前述的映射关系确定源码位置。你必须保证工程文件和服务器文件内容一致。

参考下图进行设置：

你还需要配置调试的入口点。点击工具栏 左侧的下拉按钮，选择Edit Configurations，点击+号，选择PHP Web Application，参考下图进行设置：

注意，如果你的服务器使用HTTPS协议，则Start URL必须填写完整的URL。

选中刚刚完成的Debug配置，按Alt + Shift + D或者点击工具栏上的甲虫图标即可启动调试，顺利的话，程序将在你设置好的断点处暂停。

默认情况下PHPStorm的编辑器，在类、方法前面显示一条水平横线作为分隔符，要去除，可以按如下步骤：

Preferences ⇨  Editor  ⇨ Colors & Fonts  ⇨ General ⇨ Code ⇨ Method separator color，取消颜色设置。

The post PhpStorm知识集锦 appeared first on 绿色记忆.

WebStorm是基于IntelliJ平台的，深受前端开发者欢迎的IDE。该IDE对大量前端技术/框架，例如SASS、AngularJS 2提供及时的支持，该IDE也可以用来进行Node.js的开发。

WebStorm能够自动索引当前模块内的JS文件，用于代码智能提示。如果JS位于其它模块中则无法提示，这种情况下可以使用外部JavaScript库机制，为任意模块提供代码智能提示。

定位到Settings ⇨ L & F ⇨ JavaScript ⇨ Libraries，右边列出已经安装的JavaScript库。

点击Download，可以下载一些官方的库：

点击Download and Install即可安装相应的库。

点击Add，可以添加自定义库，例如ExtJS 4.1.1：

点击OK即可添加新的库。

无论是下载还是手工添加的JS库，都会出现在Settings ⇨ L & F ⇨ JavaScript ⇨ Libraries右侧的库列表中，勾选的库对当前工程可见。

The post WebStorm知识集锦 appeared first on 绿色记忆.

RubyMine是一款基于IntelliJ平台的IDE，用于Ruby以及Ruby on Rails开发。该IDE内置了对JavaScript、HTML等Web开发技术的支持。

Ubuntu 14.04下，调试时RubyMine提示：The gem debase required by the debugger is not currently installed. would you like to install it ?

点击Yes后，安装失败，提示： ERROR: Failed to build gem native extension ... Installing base gem Unable to require openssl, install OpenSSL and rebuild ruby (preferred) or use non-HTTPS sources

解决方法一，使用非HTTPS源：

gem source -r https://rubygems.org/
gem source -a http://rubygems.org/

解决方法二，安装libssl-dev并重新构建Ruby：

sudo apt-get install libssl-dev
cd ruby-2.1.9
./configure prefix=/home/alex/Ruby/2.1.9
make clean
make && make install

The post RubyMine知识集锦 appeared first on 绿色记忆.

IDEA是一个历史悠久的Java集成开发环境，它始于2001年，以智能化著称。IDEA基于IntelliJ平台，分为社区版、商业版。IDEA目前自带JRE，此JRE仅仅用于IDEA的运行，不能做开发用。

在IDEA中，你总是在“工程”的上下文中工作，工程代表了一个完整的软件解决方案，包括代码助手、重构、代码风格一致性在内的功能都在工程内进行。

工程本身不包含开发相关的内容，例如源码、构建脚本或者文档。它主要用于组织模块并提供公共的设置。模块才是代码的容器。

IDEA使用普通的XML文件来存储工程的配置信息、及其包含的组件。并支持两种存储工程配置的格式：

.idea

IDEA允许在这两种格式之间进行转换：File ⇨ Save as Directory-Based Format

模块是工程中一个可以独立编译、运行、调试、测试的单元。模块的配置信息默认存放在其内容根目录（Content root folder）下的

.iml

Content root指的是包含模块所有文件目录。IDEA允许一个模块拥有多个Content root，但是通常都是一个。

某些时候没有Conent root的模块会有特殊用途，例如用来指定一组依赖关系。

IDEA使用不同图标来区分模块中不同的目录。你可以在目录上右键 ⇨ Mark Directory As来设置目录的类型。常用的目录类型及图标包括：

图标	目录类型说明
	Content Root：标识一个模块的内容根目录
	普通目录
	源代码根目录，如果把某个目录分配为此类型，则IDEA会在构建过程中编译其中的源代码
	自动生成的源代码根目录
	测试源代码根目录，用于将测试代码和产品代码隔离
	自动生成的测试源代码根目录
	资源文件根目录，在构建过程中会原样拷贝到输出目录
	测试资源文件根目录
	排除目录，这类目录“几乎”被IDEA忽略 该目录中的代码得到受限制的代码提示，外部目录中的代码的自动完成列表不会出现该目录中的内容，搜索时IDEA忽略此目录 将某些不重要的目录设置为排除目录，可以提高IDE的性能

一个模块的依赖是指，该模块使用的（因而依赖于的）其它实体。一个模块依赖可以是：模块使用的SDK、模块使用的库、相同工程中的其它模块。术语“模块依赖”专指第三种。

依赖的优先级由Project Structure ⇨ Modules ⇨ Dependencies页签指定，你可以手工调整顺序：

顺序决定了在编译期间，javac寻找类的优先级；也决定了运行时（普通Java程序）寻找类的优先级。 

Facet代表模块使用的框架、技术或者语言。一个模块可以添加多个Facet，使用某些Facet可能需要下载框架组件。

在IDEA中构件这一术语，可以指定两个不同却相关的事物：

1. 构件可以指你期望从工程输出的内容的规则（specification）
2. 构件可以指上述规则的实际产出

构件可以简单的是一个或者多个模块打包而成的JAR、WAR或者EAR，对于后两者，Web/Java EE Application的Facet相关的资源会一并打包到WAR/EAR中。你也可以生成自定义格式的构件。

简而言之，构件允许你把（一个或者多个模块）编译后的代码、关联的库、资源文件、元数据文件（例如Facet的部署描述符）等一并成一个可部署的单元。

构件还可以包含其它构件。

库是指在你的模块中以只读方式使用的、已编译的代码的集合。

库可以附带源码、API文档，这可以方便的进行Debug，或者在IDE中查看inline文档。

你可以定义三种级别的库：

这类库允许你使用特定于某种JavaEE服务器/Servlet容器的类。每当你添加了一个应用程序定义后，IDEA会自动创建相应的应用服务器库：

为了减少在开发机器之间转移工程的复杂性，IDEA引入路径变量（path variables），路径变量指向一个目录/文件的绝对路径。当使用位于工程外部的第三方库时，路径变量特别有用。

在IDEA中Scope表示一组文件、包或者目录。使用Scope你可以得到一个过滤后的视图，用于关注于特定操作。对于大规模的工程来说，Scope特别有效。IDEA提供了一系列预定义的Scope，你还可以自定义Scope。

你可以在Project工具窗口中浏览Scope。

可以分为两类：

1. Shared Scopes：可以供团队成员使用，存放在.idea/scopes目录或*.ipr中（这也是为什么工程元数据可能需要提交到VCS的原因）
2. Local Scopes：自己本地使用

所谓编译，就是指把*.java源文件通过javac/eclipse/ajc等编译器处理，生成*.class文件。

所谓构建，是指编译源代码、拷贝资源文件，必要的情况下进行打包。

编译、构建的结果，总是存放在工程/模块的输出目录下，默认的输出目录为out，使用Maven时一般为target。

在IDEA的Build菜单下，有多个相似的菜单项，说明如下：

下表列出的快捷键，全部基于Eclipse的Keymaps。

1. File ⇨ New ⇨ Project，弹出New Project对话框
2. 切换到Java Enterprise选项卡，选择合适的Java EE version。默认情况下是Java EE 7
3. 切换到Java选项卡，选择合适的Project SDK。注意，这里可以添加JDK，以后的工程自动感知已添加的JDK
4. 勾选Java EE ⇨ Web Application，Servlet规范的版本会显示在下面
5. 下一步，给工程命名并指定目录位置，完成

工程src目录右击 ⇨ New ⇨ Servlet，创建任意一个Servlet，IDEA会触发错误提示，原因是没有找到Servlet API。

在代码中红色HttpServlet文字上Alt + Enter，Add Java EE 6 JARs to module dependencies。在弹出对话框中点选Download，然后点击Configure，参考喜下图设置：

确定后，IDEA会下载JavaEE库。这些库会在Project Structure的Platform Settings ⇨ Global Libraries中出现，并且被当前工程自动引用。Servlet中的报错会消失，JSP也可以获得代码自动完成提示了。

File ⇨ Project Structure，切换到Artifacts，配置“构件”（如果使用Maven或者Gradle等构建工具，则不需要在此配置）。参考下图：

默认的，IDEA已经生成一个构件——解包（exploded）部署的war。点击可以定义新的构件，构件类型包括JAR、WAR、EAR、JavaFx应用等等。

在右侧窗格，你可以修改构件的名称、输出目录。勾选Build on make，则在构建工程时，IDEA会自动生成此构件。

在下面的Output Layout选项卡中，可以定义构件包含的内容、目录结构：

1. 在此选项卡的左侧，可以为构件添加目录、归档文件，或者添加工程组件的一个拷贝——例如模块的编译输出（Module Output）、目录和文件、JavaEE资源等
2. 在此选项卡的右侧，可以双击，把某个元素添加到构件默认位置，或者拖拽到构件的任意位置。已经添加过的元素，不显示

File ⇨ Settings ⇨ B,E,D ⇨ Application Servers，点击可以配置新的服务器。IDEA支持绝大部分主流的JavaEE应用/Web服务器。

Run ⇨ Edit Configurations，点击创建新的运行/调试配置。以Tomcat为例，选择Tomcat Sever ⇨ Local。在右侧窗格顶部可以设置此配置的名称，例如“Tomcat v8.0 Server at localhost:8080”。右侧窗格有多个选项卡，可以分别进行配置：

在选项卡的下面，还有一个Before launch配置，可以指定启动服务器之前需要执行的动作。 

在工具栏上选择运行配置，然后点击右侧的按钮，IDEA将启动应用服务器（运行/调试模式）并且部署Web应用。

在运行期间，依据运行配置的On Update action、On frame deactivation设置，IDEA可能自动把更新后的类、资源文件同步到服务器。你可以在Application Servers工具窗口中查看服务器代码是不是最新的：

如果某个构件后面跟着[Republish]，你可以点击按钮，将最新的代码同步到服务器。

当你从结构上更改一个类，比如修改了一个方法的签名，或者修改某个框架的配置文件，IDEA无法进行热部署，必须重启服务器。此时你可以借助JRebel插件。

参考：WebStorm智能提示

下载一个官方库后，IDEA会弹出一个对话框，你有机会将库添加为某个模块的依赖：

被添加JS库依赖的模块，可以在Project Structure ⇨ Modules对话框点选模块，然后在右侧Dependencies中看到此依赖：

遗憾的是，通过按钮你只能添加Java库，看不到JS库，这可能是个BUG。

自定义库在IDEA 2016.1下无法工作（你没有机会将其添加为模块依赖），可能是BUG 。

手工解决办法是，先添加好自定义库，然后修改相关模块的.iml文件，添加：

<!-- 添加类似下面的一行 -->    
    <!-- name为你的自定义库的名称 -->
    <!-- 如果你的库的Type是Global则level设置为application，否则设置project -->
    <orderEntry type="library" name="ExtJS 4.1.1" level="application" />
  </component>
</module>

修改完毕后立即生效。

IDEA没有工作区（Workspace）这一概念，这意味着你同时只能（在一个窗口）处理一个工程（Project）。在Eclipse中，你常常把若干个相互关联的工程在同一工作区中打开，在IDEA中你必须将它们组织为单个工程的多个模块。对于不相关的工程，建议在多个IDEA窗口中打开。

Eclipse和IDEA中重要术语的对应关系如下表：

IDEA同样没有透视图（Perspective）的概念，这个特点和Visual Studio类似，但和Eclipse迥异。在Eclipse中你可以切换到不同的透视图，来完成相应的工作，IDEA则没有这个必要，IDEA会智能的管理工具窗口——类似于Eclipse中的视图（View），这些窗口会在和当前任务相关时显示。

你可以拖拽以重新排列工具窗口，或者设置其为浮动模式。通过Window ⇨ Store Current Layout as Default可以保存当前工具窗口的布局，对以后所有工程生效。

某些工具窗口可以和编辑器联动，在工具窗口标题上栏上点击右键：

1. Autoscroll to Source：点击工具窗口中的条目后，编辑器自动切换到对应文件或者代码行
2. Autoscroll from Source：切换编辑器或代码行后，自动选中工具窗口中匹配的条目

这两项功能默认都是关闭的。Scroll from Source可以通过按钮手工触发。

IDEA会自动保存修改后的文件，并且能够从Local History中撤销重构。你之前不停按Ctrl + S的习惯可以改改了。IDEA会在编译、关闭文件时、IDE失去焦点时自动存储文件到磁盘。你还可以在A & B ⇨ System Settings 中设置IDE空闲多长时间后自动保存。

默认情况下IDEA不会自动的编译代码。你可以开启自动编译，但是当有程序在运行时，自动编译不会执行，此时你必须Ctrl + F9强制编译。

Eclipse使用自己的编译器，而IDEA默认使用JDK中的javac。Eclispse编译器对错误更加容忍，有些时候允许运行不能通过编译的代码。要切换到Eclipse编译器，可以B,E,D ⇨ Compiler ⇨ Java Compiler，设置Use compiler。要允许执行无法编译的代码，需要在Run/Debug Configurations中把Make替换为Make, no error check

要执行类似于Eclipse的Quick fix（Ctrl + 1），可以Alt + Enter。

要自动生成构造器、Getter/Setter，可以Alt + Insert。

IDEA的自动完成功能更加智能化，也比较复杂，分为：基本自动完成、次要基本自动完成、智能完成、次要智能完成、语句补全。

按Ctrl + J 可以插入模板代码，按Ctrl + Alt + J可以用模板围绕选中代码。你可以在Editor ⇨ Live Templates添加自己的模板。

IDEA支持特别的Postfix自动完成，你可以在Editor ⇨ General ⇨ Postfix Completion中查看可用的Postfix模板。

前面提到过，即使你设置了自动编译，在程序运行时IDEA不会自动编译。这样代码就不会Auto reload，要自动重新载入改变的类，你需要：

1. 对于普通Java程序：明确构建Ctrl + F9
2. 对于服务器上的程序：通过Ctrl + F10更新服务器

目前Java领域流行的构建工具包括Maven、Gradle，IDEA对它们提供了良好的内置支持。

当你创建/导入一个Maven/Gradle工程后，可以自由的修改pom.xml、build.gradle。修改这些配置文件引发潜在的构建配置发生的改变必须最终同步到IDEA的工程模型中。当你在配置文件中声明WAR等构件时，IDEA会自动配置Project Structure ⇨ Artifacts下的IDEA构件。

要手工完成上述同步，可以在Maven/Gradle工具窗口中点击按钮。要启用自动化同步，可以：

1. 对于Maven：B,E,D ⇨ Build Tools ⇨ Maven ⇨ Importing，勾选Import Maven projects automatically
2. 对于Gradle：B,E,D ⇨ Build Tools ⇨ Gradle，勾选Use auto-import

注意：

1. IDEA允许任何Maven Goal或者Gradle Task在“运行”之前执行（通过Run/Debug Configuration设置）
2. 当在IDEA中执行编译、构建操作时，IDEA使用自己的构建流程。此流程一般会比较快，但是可能和Maven/Gradle构建的结果不一致，当不一致发生时，你可以使用Maven goal或者Gradle task代替IDEA的Make

在Maven Projects工具窗口，你可以右击生命周期阶段或者目标，并指定在Make/Rebuild/Run之前/后自动触发执行。

这是一个真实的、已经维护了多年的工程，由5个Maven工程组成，其中一个包含11个Maven模块。这些工程使用了AspectJ编译时织入、maven-war-plugin的overlay、Spring、Hibernate等框架或插件。

Create New Project ⇨ Empty Project，创建一个空白的容器工程：

这样的工程创建后，工程内容根目录中除了.idea目录外没有任何内容。打开此工程后，IDEA自动打开Project Structure对话框，提示添加模块。

为了便于管理，我们把工程牵涉到的模块（一系列Maven工程）从VCS签出，存放在新工程pems-trunk的根目录下。然后点击 ⇨  Import Module，选择从工程根目录导入，如下图：

点击OK，出现如下对话框：

选择Maven，点击Next。注：通过Maven Projects工具窗口中的进行导入，与此导入方式效果一样。

点击Next后，出现如下对话框：

设置如下：

1. 勾选Search for projects recurively，以便递归的在子目录中查找Maven工程
2. 勾选Keep project file in，指定一个位置（例如.idea目录，或者工程根目录），可以集中的存放*.iml文件，避免对纯Maven工程的污染
3. 勾选Create IntelliJ IDEA modules for aggregator projects，为多模块Maven工程的每个模块分别创建IDEA模块
4. 勾选Create module groups for multi-module Maven projects，自动为多模块Maven工程创建模块分组

点击下一步，选择合适的Maven profile，再次下一步，出现类似如下界面：

该界面列出所有待导入的Maven工程的列表，注意，对于多模块Maven工程，只有容器工程（packaging=pom）才会出现在此列表中。

点击Next，选择IDEA工程使用的Project SDK，保持和Maven工程的JDK版本要求一致，然后点击Finish完成导入。我多次尝试，设置Project SDK没有效果，必须手工到Project Structure ⇨ Project Settings ⇨ Project中设置，在这个工程中，需要设置Project SDK为1.6、Project language level为6。

导入完毕后，在Project工具窗口中，可以看到如下的IDEA模块（组）：

可以看到，IDEA对pems、security-monitoring两个Maven工程创建了模块分组，包含模块配置的*.iml文件存放在IDEA工程的根目录下。

打开Project Structure ⇨ Modules，可以看到IDEA成功识别到工程使用了AspectJ，并且自动配置了AspectJ Facet：

最好在Settings ⇨ B,E,D ⇨ Java Compile设置一下IDEA的ajc的Command line parameters，和aspectj-maven-plugin保持一致，例如

-showWeaveInfo -XnoInline -outxml -Xlint:ignore -1.6 

打开Project Structure ⇨ Artifacts，可以看到IDEA自动处理了Overlay：

打开Settings ⇨ B,E,D ⇨ Compiler ⇨ Java Compiler，可以看到编译器被设置为Ajc。尽管我们在pom.xml中并没有指定对aspectjtools的依赖，但是IDEA很聪明的猜测到了它的位置。

需要注意的是，IDEA完全是依据POM中的依赖列表来识别AspectJ和Overlay，与aspectj-maven-plugin、maven-war-plugin插件的配置无关。IDEA不会（像Eclipse的m2e Connector那样）识别这些插件进而改变IDEA工程模型

上面我们提到过，IDEA可以成功识别WAR的overlays，但是它却不支持maven-war-plugin的excludes规则：

<overlay>
    <groupId>com.kingsmartsi</groupId>
    <artifactId>pems-rpt</artifactId>
    <excludes>
        <exclude>WEB-INF/lib/sshe-utils-*.jar</exclude>
        <exclude>WEB-INF/lib/security-monitoring-core-*.jar</exclude>
        <exclude>WEB-INF/lib/comm-tools-*.jar</exclude>
        <exclude>WEB-INF/lib/commons-lang-*.jar</exclude>
        <exclude>WEB-INF/lib/commons-logging-*.jar</exclude>
    </excludes>
</overlay>

这导致本来需要排除掉的内容进入需要部署war构件，例如上面的pems-web-manager:war exploded。要解决此问题，你可以逐个修改参与overlay的war构件，将不需要的内容从它本身的输出列表中排除，例如：

排除掉某些JAR包后，IDEA会作为错误看待，并且显示在Project Structure 左侧面板的“Problems”中，构件上也被打上波浪线提示。要去除这些提示很简单，只需要把这些构件的Type改为“Other”即可：

你可能发现这种处理方式太过繁琐，下面有两种备选方案：

1. 运行Tomcat前，调用maven-war-plugin插件的Goal生成pems-web-manager:war exploded构件的目录内容。这样就可以遵循excludes规则，后续的Build Artifacts操作也不会破坏此规则。默认的IDEA在启动Tomcat前自动执行Build Artifacts操作
2. 不使用maven-war-plugin的overlay的excludes功能。以该工程为例，excludes的目的是排除掉低版本的commons-lang:1.0，这完全可以（也应当）用Maven传递性依赖排除机制来实现

这个比较奇葩，工程内有两个Hibernate实体类，引用了同一个

@AnyMetaDef(name="device")

@Any ( metaDef = "device" )

现在的问题是，在Eclipse下部署到Tomcat，@AnyMetaDef必须定义在A类上；在IDEA下部署到Tomcat，@AnyMetaDef必须定义在B类上。否则就会报错：Unable to find @AnyMetaDef for an @(ManyTo)Any mapping ...

看样子和类的加载顺序有关系，而这两个类的加载顺序受运行环境的影响。

最简单的解决办法就是重复定义一个@AnyMetaDef并指定不一样的名字，由于@Any很少用到，这不会导致过分的维护压力。

当工程内包含大量JavaScript时，会验证增加IDEA分析代码的压力，此时你可以把不需要参与搜索、代码分析的：

1. 目录 Mark Directory As ⇨ Excluded
2. JS文件 Mark as Plain Text

但是要注意，Excluded的目录不会发布到Tomcat服务器，可能会导致404错误。 

最好通过命令行来添加，通过IDEA的GUI添加可能出现问题，取决于项目的组织方式。

参考Web应用开发一节创建一个Tomcat服务器，把pems-web-manager:war exploded、sshe-static:war exploded两个构件添加到Run/Debug Configurations的Deployment选项卡，然后在Server选项卡设置合适的参数：

设置完毕后点击确定，在工具栏选择此Run/Debug Config，点击或即可启动Tomcat。

按照上图的配置，运行期间发生修改（或新添加）的类、资源文件会在切换到其它窗口后、Update操作后（Ctrl + F10）自动同步到Tomcat服务器，同步后IDEA会在Run/Debug工具窗口上方弹出类似下面的气泡提示：

应当使用Maven来打包，首先为所有顶级Maven工程创建Run/Debug Config，Command line可以设置为

clean install -Dmaven.test.skip=true

IntelliJ IDEA本身的网络代理配置，不会影响到Maven命令的执行，因此，你需要配置Maven代理。参见：Maven知识集锦

IDEA不会拷贝构件到其它目录，直接使用out/target目录下构建好的目录或者war包。

以Maven工程为例，如果使用exploded构件，那么：

1. 一般方式启动Tomcat：使用/target/artifactid-version/中的类和Web资源。目录artifactid-version由Build Artifacts动作生成
2. JRebel方式启动Tomcat：使用/target/classes中的类、使用/src/main/webapp下的Web资源

如果你把资源文件存放在src/main/java下，那么删除这些资源文件后，exploded构件目录不会同步。放在src/main/resources下则没有此问题。

一直显示：loading archetype list，但是无法加载完毕。

解决办法：

1. 尝试删除/home/alex/.IntelliJIdeaxxxx.xx/system/maven目录后重试
2. 尝试修改Preferences ⇨ Build Tools ⇨ Maven ⇨ Importing，修改 VM options for importer 为-Xmx1024m后重试

例如和Spring联用时，调试注解了@Transactional的方法的时候，Debug工具窗口看不到本地变量的信息。

解决办法： Settings ⇨ B,E,D  ⇨ Compiler  ⇨ Java Compiler，设置Ajc Options / Command line parameters，添加

-preserveAllLocals

此外还有提示 'this' is not available的情况，可以改用

ajc$this

目前很多Docker的CLI选项Docker Integration插件不识别。手工编写的JSON file示例如下：

{
    "HostConfig": {
        "NetworkMode": "local",
        "Dns": [
            "172.21.0.1",
            "178.79.131.110",
            "223.6.6.6"
        ]
    },
    "NetworkingConfig": {
        "EndpointsConfig": {
            "local": {
                "Gateway": "172.21.0.99"
            }
        }
    }
}

上面的例子示例了如何配置容器的网络参数，注意MAC、IP地址参考docker inspect的结果或者docker-java进行设置没有效果。 

要使用yyyy-MM-dd HH:mm格式的时间，为Intellij提供环境变量

export LC_TIME=sv_SE

The post IntelliJ IDEA知识集锦 appeared first on 绿色记忆.

CLion是基于Intellij平台的IDE，主要用于C/C++开发。它使用CMake工程模型，你对CMakeLists.txt的任何更改都会反映到IDE中，CLion调用CMake的命令行完成工程构建。

-Dvar=name

当通过CLion创建新工程时，CMakeLists.txt会自动创建。当工程结构复杂时，你可以手工为子目录创建CMakeLists.txt文件。

当你打开不是基于CMake的工程时，CLion允许做的事情很少——不能编辑代码、不能构建或运行。这种情况下你可以使用CMake的导入功能或者手工创建CMakeLists.txt文件。

手工修改CMakeLists.txt后，需要Reload工程才能体现出修改。当需要Reload时CMake工具窗口会有提示。你还可以启用Auto-Reload。

如果需要在构建前清空CMake的缓存条目，可以定位到CMake工具窗口 ⇨ Cache选项卡，点击按钮。

点击右侧的向下箭头，选择Edit Configurations，可以修改某个条目使用的构建配置，默认支持CMake的四种构建配置。

你可以在CMakeLists.txt中添加自定义的构建配置：

# 必须是第一个变量定义
set(CMAKE_CONFIGURATION_TYPES "CustomType1;CustomType2" CACHE STRING "" FORCE)

打开既有CMake工程或者创建新工程后，默认的CLion把CMakeLists.txt所在目录作为工程根目录（Project root directory）看待，要改变此行为，可以Tools ⇨ CMake ⇨ Change Project Root。

# 可选的BEFORE/AFTER关键字用于控制搜索顺序
include_directories(BEFORE ${MY_SOURCE_DIR}/src )

# 设置C编译器的位置
set (CMAKE_CXX_COMPILER, "C:\\MinGW\\bin\\g++")
# 启用C99标准
set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=c99")
# 启用C++ 11标准
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
# 启用警告
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -Wall")

add_library (my_library STATIC|SHARED|MODULE ${SOURCE_FILES})

# 使用BOOST库
find_package(Boost)
IF (Boost_FOUND)
    include_directories(${Boost_INCLUDE_DIR})
endif()
set (Boost_USE_STATIC_LIBS OFF) # enable dynamic linking
set (Boost_USE_MULTITHREAD ON)  # enable multithreading
find_package (Boost COMPONENTS REQUIRED chrono filesystem)
# 声明链接到BOOST库
target_link_libraries (my_target ${Boost_LIBRARIES})

add_subdirectory (project1) # 把project1包含到主工程
add_subdirectory (project2) # 把project2包含到主工程

点击 Run ⇨ Attach to Process... 可以调试运行中的进程。当Debug工具窗口提示Debugger attached to process ...后，点击左侧的Pause Program按钮，这时GDB窗格支持输入。

你可能需要设置源码搜索路径，否则设置断点时GDB窗格提示No source file named /home/alex/CPP/project ...要设置源码搜索路径，在GDB窗格中输入set directories命令，示例：

set directories /home/alex/CPP/projects/clion/envoy

你可以启动任意应用程序并调试，此程序不一定是CLion通过Cmake构建出来的。

点击 Run ⇨ Edit Configurations，添加一个Application类型的配置，Executable选择你需要调试的应用程序的绝对路径：

注意：把Before launch下面的Build项去掉。

然后点击调试按钮即可。

脚本示例：

#!/usr/bin/env bash
gdbserver --once localhost:2345 envoy ...

配置示例截图：

基于gdbserver进行远程调试时，特别需要注意路径映射的问题。

Remote端使用（符号表中的）相对路径貌似无效，确定决定路径，可以按照如下步骤：

1. 使用gdb连接到gdbserver：
   

   (gdb) target remote localhost:2345

2. 打印源码列表：

   (gdb) info sources
   /proc/self/cwd/source/exe/main_common.cc ...
   /proc/self/cwd/bazel-out/k8-dbg/bin/include/envoy/common ...
   /home/alex/.cache/bazel/_bazel_alex/3a80e9c345550f05d77beb52ded4f5f3/external/envoy_deps_cache_2c744dffd279d7e9e0910ce594eb4f4f/libevent.dep.build/libevent-release-2.1.8-stable/build/../ratelim-internal.h

3. 通过打印当前栈追踪，查看符号表中的源码路径：

   (gdb) where
   #0  epoll_wait (epfd=<optimized out>, events=events@entry=0x2e00a80, maxevents=<optimized out>, timeout=timeout@entry=100) at ../epoll_sub.c:66
   #1  0x00000000010b7709 in epoll_dispatch (base=0x2e70000, tv=<optimized out>) at ../epoll.c:462
   #2  0x00000000010ad8dd in event_base_loop (base=0x2e70000, flags=0) at ../event.c:1947
   #3  0x0000000000a5067c in Envoy::Event::DispatcherImpl::run (this=0x2d9d3f0, type=Envoy::Event::Dispatcher::RunType::Block) at source/common/event/dispatcher_impl.cc:165
   #4  0x00000000009d74c5 in Envoy::Server::InstanceImpl::run (this=0x2e2d200) at source/server/server.cc:466
   #5  0x0000000000425baa in Envoy::MainCommonBase::run (this=0x2e2c8b0) at source/exe/main_common.cc:103
   #6  0x000000000040cd68 in Envoy::MainCommon::run (this=0x2e2c480) at bazel-out/k8-dbg/bin/source/exe/_virtual_includes/envoy_main_common_lib/exe/main_common.h:86
   #7  0x000000000040a4bf in main (argc=19, argv=0x7fffffffd238) at source/exe/main.cc:37 

4.  可以看到source目录对应到的是/proc/self/cwd/source目录。假设Debugger端的源码路径是/home/alex/CPP/projects/clion/envoy/source，则需要建立两者的路径映射

CLion默认指定的构建树的位置，可以在Messages窗口看到，通过CLion执行一次构建，可以看到类似：

bin/cmake --build /home/alex/.CLion2016.1/system/cmake/generated/sds-1b689bf9/1b689bf9/Debug --target sds -- -j 8

的消息，你只需要CD到

--build

make install

也无法调用对象的方法、查看其字段值。

出现此问题的原因是，目标对象在编译时没有开启调试信息。如果使用GCC，尝试添加编译参数-O0 -g3。 

The post CLion知识集锦 appeared first on 绿色记忆.

IntelliJ是JetBrains公司的一个基础软件平台，主要用于构建IDE。IDEA、WebStorm、PHPStorm、CLion、PyCharm、RubyMine、DataGrip、Android Studio等IDE均基于此平台构建。本文记录通用于这些IDE的知识。 

IntelliJ中在编辑器左侧、下面、右侧的若干小面板，被称为工具窗口。工具窗口名字前面可能有N: 前缀，你可以使用Alt + N快速切换到此工具窗口。

大部分工具窗口支持快速搜索（Speed Search）功能，你只需要聚焦目标工具窗口，然后直接输入你需要搜索的内容，即可定位到匹配条目。

IntelliJ引入视图模式这一特性，允许IDE以不同方式呈现：

IntelliJ支持比较智能化的代码提示（Code Assist），在你输入的时候匹配的候选代码提示会自动出现。匹配方式不仅仅限于前缀，不连续的字符也可以用于筛选匹配，例如输入mtm可以匹配myTestMethod方法。

对于JavaScript等动态语言，IntelliJ可以分析得到工程中所有的变量、函数名称，用于代码提示，而不考虑代码的上下文，例如：

var cmp = null;
// 输入到cmp.init，IDEA即可给出initRenderData提示，这是因为在工程的某个文件中定义了initRenderData()方法
// 尽管从山下文判断，此提示是不正确的
cmp.initRenderData();

这种提示方式很有效，特别是在记不清函数名称的时候，但是工程中代码过多时，IntelliJ会消耗大量时间分析代码，造成卡顿。 

IntelliJ支持独特的Postfix自动完成，你可以输入

false.if

if(false){}

IntelliJ支持自定义模板代码，这些代码可以插入到当前编辑器中，或者环绕当前编辑器中被选中的代码。

要自定义LiveTemplate，可以Settings ⇨ Editor ⇨ Live Templates，然后点击右侧的按钮添加新的模板。你可以为模板设置一个缩写，这样，在编辑器里输入缩写后，按Tab即可自动完成。

要插入模板，可以使用Intellij的智能提示，或者使用快捷键：Ctrl + J、Ctrl + Alt + J。

预定义变量：

Live template的强大之处在于，它允许你自定义模板变量，变量的值可以从IntelliJ提供的大量函数中推导出。这样，你就可以很方便的在模板在插入上下文信息，例如类名、方法名、当前时间等信息。例如下面的Live template，它可以向当前Java类中插入日志记录器的声明语句：

下表列出的快捷键，基于Eclipse方案修改得到：

Change list是一个很体贴的功能，它允许你把纳入版本控制的文件分组，每次只提交其中的一组。某些配置文件需要针对本地环境修改，每个开发者都不一样。这些本地修改不能提交到VCS，这时可以把它们添加到另外一个变更集中，防止误提交。

在提交对话框中，左面板的又上角由一个Change list下拉框，你可以选择当前要提交的变更集：

左侧待提交文件列表中，你可以右击任何目录、文件，修改它们所属的变更集。

Settings  ⇨  Version Control  ⇨ GitHub，在这里设置你的GitHub用户名和密码

Settings  ⇨  Version Control  ⇨ Git：

1. Auto-update if push of the current branch was rejected：如果勾选，当Push失败后，会自动从远程仓库拉取更新
2. Allow force push：是否允许强制Push

VCS ⇨ Import into Version Control ⇨ Share Project on GitHub，弹出下面的对话框：

点击Share后，IDE会使用你的账号，在GitHub上面创建一个空白的裸仓库。

在下一个弹出的对话框中，你可以选择需要添加的文件，并提交。

注意，提交仅仅是针对你本地的Git仓库。要Push到GitHub，需要VCS ⇨ Git ⇨ Push（Eclipse方案下快捷键为Ctrl + Shift + K） ：

可以看到，本次Push会在远程仓库初始化master分支。在后续的开发过程中，你随时可以把本地的Tag一同Push到远程仓库。

上图中：

1. 当前位于develop分支上，看黄色标签
2. 本地仓库的develop分支，和远程仓库的develop分支，处于同步状态，看绿色标签和紫色标签重合
3. 本地仓库的master分支位于commit4（绿色标签），远程仓库的master分支位于commit5（紫色标签）

在此时，你可以点击右下角 Git:develop ⇨ Remote Branches ⇨ Merge，把任意分支合并到develop分支。例如，合并master分支，之后Git Log变为：

可以看到，合并后默认自动提交。现在的情况是，本地仓库的develop和远程的develop不同步了。你可以执行一下Push：

这时develop分支的绿、紫标签又在一起了。

在develo commit 3（57a408d）上右击，Reset Current Branch to Here ... ⇨ Hard，现在变为：

注意黄色小标的位置。

我们可以强制Push版本57a408d到远程仓库，替换掉最新的673bb5c。在Push弹窗中，点击右下角Push按钮的下箭头，选择Force Push。提交后，服务器的develop分支的版本变的和本地一致：

其它开发人员，切换到develop分支后，执行Update Project，紫色标签的位置和远程仓库（被强制Push的）变的一致：

 这时，此开发人员比远程仓库多出来的develo commit 6，可以Push，也可以右键  ⇨ Undo Commit，撤销掉提交。提交撤销后，其导致的修改将存在于当前工作区。

这里提到的主题，是指IDE本身的组件（例如菜单、按钮）的样式风格。和编辑器色彩方案不同，Intellij平台没有提供细粒度的控制，只允许用户在三个预置的主题中选择。

最近Intellij平台下的IDE分别发布2016.1版本，升级后，我注意到Linux下的GTK+主题存在BUG，编辑器面板等地方出现多余灰色边框（IDEA-152424），非常难看。等了几个月了，这个BUG还没有修复，为了拯救完美主义强迫症的自己，动手改吧……

我的想法是，把默认的Intellij主题中的蓝色调改为Ubuntu的橙色调风格，而不是去修复GTK+主题。这主要是考虑到默认主题在三大OS上都大量使用，JetBrains在此主题上花费的精力会比较多。相比之下，Linux下的GTK+主题由于用户较少，一直存在各种BUG。

虽然没研究过Intellij平台的源码，但是既然它是基于Swing的，我觉得应该找一些和LookAndFeel有关的类作为代码分析的入口。

我以CLion为例尝试。打开lib目录下最大的jar包，反编译，大概浏览了一下代码，发现com.intellij.ide.ui.laf包和主题相关，而IntelliJLaf类则对应了默认的IntelliJ主题。清空配置文件intellijlaf.properties的内容，启动CLion后发现完全界面完全变样了，由此推断，修改此配置文件是最简单的主题定制方式。修改并测试后，以下配置项被调整：

# 面板中选区的背景色
intellijlaf.selectionBackground=F07746
# 复选框边框，上半部分
CheckBox.darcula.borderColor1.selected=CC5627
# 复选框边框，下半部分
CheckBox.darcula.borderColor2.selected=CC5627
# 复选框背景，上半部分
CheckBox.darcula.backgroundColor1.selected=F58456
# 复选框背景，下半部分
CheckBox.darcula.backgroundColor2.selected=EC7B4D
# 选中复选框中的小钩子的阴影色
CheckBox.darcula.shadowColor.selected=90553C
# 获得焦点的复选框的颜色
CheckBox.darcula.focusedArmed.backgroundColor1.selected=F58456
CheckBox.darcula.focusedArmed.backgroundColor2.selected=EC7B4D
CheckBox.darcula.focused.backgroundColor1.selected=E7976D
CheckBox.darcula.focused.backgroundColor2.selected=E7976D
# 下拉列表箭头颜色
ComboBox.darcula.arrowFillColor=D96334
ComboBox.darcula.arrowFocusedFillColor=EC7B4D
# 按钮背景颜色
Button.darcula.selection.color1=EC7B4D
Button.darcula.selection.color2=CC5627
# 数字字段按钮背景色
Spinner.darcula.enabledButtonColor=D96334
# 树选区边框颜色
Tree.selectionBorderColor=D96334

保存并更新压缩包后，重启CLion，可以发现一部分UI组件的配色改变了，但是聚焦的按钮、搜索框、复选框、单选框等组件依然会显示出蓝色。

其实切换到到深色主题Darcula，会发现那种蓝色也是存在的。进一步查看代码，可以发现IntelliJLaf的父类是DarculaLaf，原来浅色主题是从深色主题继承扩展而来的（比较反直觉…）。对某些控件加上蓝色发光效果，是DarculaLaf了类具有的一个行为，IntelliJLaf可能仅仅是继承了这一行为。

继续分析了一会代码，发现com.intellij.ide.ui.laf.darcula.DarculaUIUtil类中硬编码了发光效果的颜色，修改该类的两个成员，编译后替换同名文件：

public class DarculaUIUtil {
    public static final Color GLOW_COLOR = new JBColor(new Color(204, 86, 39), new Color(240, 119, 70));
    private static Color a() {
        return new JBColor(new Color(204, 86, 39), new Color(240, 119, 70));
    }
} 

以上步骤都完毕后，单选框还是顽固的蓝色，呵呵，又一个硬编码的颜色需要修改：

public class DarculaRadioButtonUI extends MetalRadioButtonUI {
    protected void paintIcon(JComponent var1, Graphics2D var2, Rectangle var3, Rectangle var4) {
        ...
        JBGradientPaint var11 = new JBGradientPaint( var1, new Color(240, 119, 70), new Color(204, 86, 39) );
    }
} 

最终效果的截图在这里，只是把IntelliJ主题的蓝色系改为橙色系，但是和Ubuntu系统很搭配呢。

这个可以通过IDE设置：Settings ⇨ Editor ⇨ General，展开到Editor ⇨ Selection background，修改为F07746。该设置不但影响编辑器窗口，还会影响到Terminal、Messages、Event Log等基于文本的Tool window。

Window ⇨ Store Current Layout as Default

安装jayatana：

sudo add-apt-repository ppa:danjaredg/jayatana
sudo apt-get update
sudo apt-get install jayatana

修改IntelliJ的配置文件：

# 添加下面的内容
-javaagent:/usr/share/java/jayatanaag.jar

此方法适用于任何Swing程序。

最新版本（至少2018）版本的Intellij，不再需要jayatana，而且jayatana可能导致Intellij功能异常。要启用全局菜单，搜索Action ，Experimental Features，勾选

linux.native.menu

安装修复过字体渲染的OpenJDK：

sudo add-apt-repository ppa:no1wantdthisname/openjdk-fontfix
sudo apt-get update
sudo apt-get install openjdk-7-jdk

修改IntelliJ的配置文件：

# 添加下面的内容
-Dawt.useSystemAAFontSettings=lcd
-Dswing.aatext=true
-Dsun.java2d.xrender=true
-Dsun.java2d.pmoffscreen=false

修改IntelliJ的启动脚本，使用刚下载的OpenJDK：

export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-amd64

更进一步，可以安装Infinality，提升Ubuntu下字体渲染。

Ubuntu14下的基于IntelliJ平台的IDE，有两个地方可以设置字体：

1. A & B ⇨ Appearance，Override Default fonts by 。这里可以设置IDE界面字体，包括菜单、Tool Window、Quick documentation弹窗等
2. Editor ⇨ Color & Fonts ⇨ Font。这里可以设置编辑器字体

默认情况下，系统语言设置为中文时，不进行任何设置就可以正常显示中文。

如果设置上面的第1项，需要保证选中的字体中包含中文字符的支持，否则很多地方的中文会显示为空心小方块。

最新的2016版本发布后，IntelliJ平台内置了修改后的Open JDK，提升了字体渲染效果，而且比进行过Fontfix的Open JDK字体更加清晰。试用后发现，系统语言设置为英文时，Quick documentation弹窗、搜索框中的中文都是乱码。除了把1设置为某种中文字体。

问题是，英文系统下默认字体“Ubuntu”比其它字体美太多，实在不想弃用。所以我把Wenquanyi Micro Hei中的中文合并到Ubuntu中，生成一个新字体“Ubuntu Micro Hei”，调整Hint后，发现英文部分显示效果和Ubuntu字体几乎无差，中文也支持了。下面是截图：怎么样，是不是觉得比Mac OS X的渲染效果还惊艳（注：安装了Infinality，并且渲染风格设置为OS X；IntelliJ中字体Antialiasing设置为Subpixel）

下面提供字体的下载链接：Ubuntu Micro Hei。

只需要记住：右侧面板显示的是，当前时间点相对左侧选中的那个事件（时间点）发生之前，文件的差别：

1. 如果某个文件当前是有的，那个时间点是没有的，文件名称显示为绿色
2. 如果某个文件在两个时间点都存在，但是有改动，文件名称显示为蓝色
3. 如果某个文件在当前是没有的，而那个时间点是有的，文件名称显示为灰色

示例截图：

在这个例子中。我们最后做了一条回退操作，在这之前，我们删除了两个文件，添加了一个文件。因而回退后，相对于回退前是添加了两个文件，删除了一个文件。 一定要明白“事件之前”而不是之后，如果是之后，那么Difference应该不存在。

首先在钥匙串应用中删除对应的条目，然后通过IntelliJ 进行SVN操作，根据提示输入密码、点击记住。后续系统会提示是否允许IntelliJ访问钥匙串，选择总是允许。

在Ubuntu下，默认的你无法定制某些Alt + *的快捷键，原因是分配给Global菜单了。

要解决此问题，打开Settings ⇨ A & B ⇨ Appearance，右侧找到Window Options区域，勾选 Disable mnemonics ...

Inatellij 2017以后的版本，在Ubuntu下用IBUS输入中文，上屏时会出现闪烁。调试可以发现，它先渲染出一个英文字符大小的方框，然后在渲染出中文字符。

这个问题和零延迟渲染特性有关，设置系统属性

-Deditor.zero.latency.rendering=false

The post IntelliJ平台知识集锦 appeared first on 绿色记忆.

CMake是一个开源的可扩展工具，用于独立于编译器的管理构建过程。CMake必须和本地构建系统联合使用，在每个源码目录中，需要编写CMakeLists.txt文件，以声明如何生成标准的构建文件（例如GNU Make的Makefiles，或者MSVS的解决方案）。

CMake支持所有平台的内部构建（in-source build）和外部构建（out-of-source build）。内部构建的源码目录和二进制目录为同一目录，即CMake会改变源码目录的内容。通过外部构建，可以针对单个源码树进行多重构建（Multiple builds ）。

CMake会生成一个方便用户编辑的缓存文件，当其运行时，会定位头文件、库、可执行文件，这些信息被收集到缓存文件中。用户可以在生成本地构建文件之前编辑它。

CMake命令行支持自动或者交互式的运行。CMake还提供了一个基于QT的GUI，其名称为cmake-gui。注意此GUI同样依赖于环境变量的正确设置。

CMakeLists.txt包含一系列的命令，每个命令都是

COMMAND (args…)

CMake支持简单的变量，它们或者是字符串，或者是字符串的列表。引用一个变量的语法是

${VAR_NAME}

如果向一个命令传递列表变量，效果等同于向它逐个传递列表成员：

set(V 1 2 3)    # V的值是1 2 3
command(${V})   # 等价于command(1 2 3)

要把一个列表变量作为整体传递，只需要加上双引号即可： 

command("${V}")   # 等价于command("1 2 3")

 CMake可以直接访问环境变量和Windows注册表，前者使用语法

$ENV{VAR}

[HKEY_CURRENT_USER\\SOFTWARE\\path;key]

# 读取环境变量
message(STATUS "LD_LIBRARY_PATH=$ENV{LD_LIBRARY_PATH}" )
# 设置环境变量
set(ENV{PATH} "/home/alex/scripts")

1. 支持多个底层构建工具，例如GNU Make、MSVC、XCode等等，可以生成这些构建工具需要的配置文件
2. 通过分析环境变量、Windows注册表等，自动搜索构建所需的程序、库、头文件
3. 支持创建复杂的命令
4. 很方便的在共享库、静态库两种构建方式之间切换
5. 自动生成、维护C/C++文件依赖关系，并且在大部分平台上支持并行构建

在开发跨平台软件时，CMake具有以下额外优势：

1. 可以测试机器字节序和其它硬件特性
2. 统一的构建配置文件
3. 支持依赖于机器特定信息的配置，例如文件的位置

# Ubuntu
sudo apt-get install cmake
# Redhat
yum install cmake
# Mac OS X with Macports
sudo port install cmake
# Window https://cmake.org/files/v3.5/cmake-3.5.2-win32-x86.zip

C++源码：

#include <iostream>

using namespace std;

int main() {
    return 0;
}

要通过CMake编译上述文件，需要在同一目录下放置CMakeLists.txt文件：

# 需要最小的CMake版本
cmake_minimum_required(VERSION 3.3)
# 工程的名称，会作为MSVS的Workspace的名字
project(intellij_taste)

# 全局变量：CMAKE_SOURCE_DIR CMake的起始目录，即源码的根目录
# 全局变量：PROJECT_NAME 工程的名称
# 全局变量：PROJECT_SOURCE_DIR 工程的源码根目录的完整路径

# 全局变量：构建输出目录。默认的，对于内部构建，此变量的值等于CMAKE_SOURCE_DIR；否则等于构建树的根目录
set(CMAKE_BINARY_DIR ${CMAKE_SOURCE_DIR}/bin)  # ${}语法用于引用变量
# 全局变量：可执行文件的输出路径
set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR})
# 全局变量：库文件的输出路径
set(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR})
# 设置头文件位置
include_directories("${PROJECT_SOURCE_DIR}")
# 设置C++标志位
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
# 设置源文件集合
set(SOURCE_FILES main.cpp)
# 添加需要构建的可执行文件，第二个以及后续参数是用于构建此文件的源码文件
add_executable(intellij_taste ${SOURCE_FILES})

在上述目录中执行下面两条命令，即可执行构建：

# 创建一个build子目录作为构建树
mkdir build && cd build && cmake .. && cd ..

# 在build/bin子目录中生成可执行文件：
# cmake --build <dir> [options] [-- [native-options]]
cmake --build build -- -j3  # --表示把其余选项传递给底层构建工具

# 注意，亦可使用底层构建系统，例如make命令或者MSVC的IDE
cd build
make -j3

CMake包含一系列重要的概念抽象，包括目标（Targets）、生成器（Generators）、命令（Commands）等，这些命令均被实现为C++类。理解这些概念后才能编写高效的CMakeLists文件。

下面列出这些概念之间的基本关系：

1. 源文件：对应了典型的C/C++源代码
2. 目标：多个源文件联合成为目标，目标通常是可执行文件或者库
3. 目录：表示源码树中的一个目录，常常包含一个CMakeLists.txt文件，一或多个目标与之关联
4. 本地生成器（Local generator）：每个目录有一个本地生成器，负责为此目录生成Makefiles，或者工程文件
5. 全局生成器（Global generator）：所有本地生成器共享一个全局生成器，后者负责监管构建过程，全局生成器由CMake本身创建并驱动

CMake的执行开始时，会创建一个cmake对象并把命令行参数传递给它。cmake对象管理整体的配置过程，持有构建过程的全局信息（例如缓存值）。cmake会依据用户的选择来创建合适的全局生成器（VS、Makefiles等等），并把构建过程的控制权转交给全局生成器（调用configure和generate方法）。

全局生成器负责管理配置信息，并生成所有Makefiles/工程文件。一般情况下全局生成器把具体工作委托给本地生成器执行，全局生成器为每个目录创建一个本地生成器。全局/本地生成器的分工取决于实现，例如：

1. 对于VS，全局生成器负责生成解决方案文件，本地生成器负责每个目标的工程文件
2. 对于Makefiles，全局生成器生成总体的Makefile，本地生成器则负责生成大部分Makefile

每个本地生成器包含一个cmMakefile对象，其中存放CMakeList.txt的解析结果。

CMake的每一个命令也被实现为C++类，该类主要包括两个成员：

下图显示cmake、生成器、cmMakefile、命令等类型的关系：

cmMakefile对象中存放的最重要的对象是目标（Targets），目标代表可执行文件、库、实用工具等。每个

add_library

add_executable

add_custom_target

下面的语句创建一个库目标：

# 创建一个静态库，包含两个源文件
add_library(foo STATIC foo1.c foo2.c)

上述命令声明的foo可以作为库名称在工程的任何地方使用。CMake知道如何将此名称转换为库文件。命令的（可选的）第二个参数声明库的类型，有效值包括： 

如果不声明库类型，则CMake依据变量

BUILD_SHARED_LIBS

与库目标类似，可执行目标也可以指定特定的选项，例如WIN32会导致操作系统调用WinMain而不是main函数。

使用

set_target_properties

get_target_properties

set_property

get_property

# 修改目录使用的头文件目录，注意，全局的include_directories会此目标忽略
set_property (TARGET jsonrpc
  PROPERTY INCLUDE_DIRECTORIES
    ${JSONCPP_INCLUDE_DIRS}
    ${Boost_INCLUDE_DIRS}
    ${CMAKE_CURRENT_SOURCE_DIR}
    ${CMAKE_CURRENT_SOURCE_DIR}/jsonrpc
)

# 同时设置多个属性
set_target_properties(jsonrpc PROPERTIES VERSION ${PROJECT_VERSION} SOVERSION ${PROJECT_VERSION_MAJOR})

常用目标属性如下表：

set_target_properties(
    cstudy PROPERTIES
    INCLUDE_DIRECTORIES /home/alex/.local/include
    # 使用定制的glibc库
    LINK_FLAGS "-Wl,-rpath=/home/alex/.local/lib  -Wl,--dynamic-linker=/home/alex/.local/lib/ld-linux-x86-64.so.2"
)

全部目标属性请参考官网。

使用

target_link_libraries

对于声明的每个库，CMake会跟踪其依赖的所有其它库，这种依赖关系需要用上述命令来设置：

add_library(foo foo.cpp)
#foo库依赖于bar库
target_link_libraries(foo bar)

add_executable(foobar foobar.cpp)
#foobar显式依赖foo，隐式依赖bar，后两者都会被链接到foobar中
target_link_libraries(foobar foo)

和Target类似，源文件也被建模为C++类，也支持读写属性（通过set_source_files_properties、get_source_files_properties或更加一般的命令）。最常用属性包括：

其它偶尔可能用到的CMake类型包括Directory、Generator、Test、Property等。Directory、Generator、Test的实例同样（与目录、源文件类似）关联属性。

属性是一种键值存储，它关联到一个对象。读写属性最一般的方法是上面提到的get/set_property命令。所有可用的属性可以通过

cmake -help-property-list

目录的属性包括：

目录和生成器对象会在CMake处理你的源码树时自动创建。

CMakeLists中的变量和普通编程语言中的变量很类似，变量的值要么是单个值，要么是列表。CMake自动定义一系列重要的变量。

要引用变量，必须使用

${VARNAME}

CMake中变量的作用域和普通编程语言略有不同，当你设置一个变量后，变量对当前CMakeLists文件、当前函数、以及子目录的CMakeLists、任何通过

INCLUDE

当处理一个子目录、调用一个函数时，CMake创建一个新的作用域，其复制当前作用域全部变量，在子作用域中对变量的修改不会对父作用域产生影响。要修改父作用域中的变量，可以在set时指定特殊选项：

set (name Alex PARENT_SCOPE)

变量的值可以是一个列表，这样的变量可以被展开为多个值：

set(fruit apple peach strawberry )
foreach(f ${fruit})
    message("Do you want ${f}")
endforeach()

常用变量如下表：

set(CMAKE_C_FLAGS "-std=c11 -pthread")

set(CMAKE_C_FLAGS_DEBUG "-g -O0")

有些时候你可能期望用户通过CMake的UI输入一些变量的值， 这时变量必须作为缓存条目。当CMake运行时，它会向二进制目录输出缓存文件（Cache file），缓存文件中的变量值通过CMake的UI展示给用户。

使用这种缓存的目的之一是，存储用户的选项，避免重新运行CMake时，反复要求用户输入相同的信息。

option

option(USE_PNG "Do you want to use the png library?")

用户可以通过UI设置USE_PNG的值，并且在未来这一值会保存在缓存中。使用CLion作为IDE时，可以在CMake窗口中点击Cache选项卡，查看或者编辑缓存条目：

除了

option

find_file

set

# CACHE选项表示此变量作为缓存条目
# ON为默认值
# BOOL为变量类型，支持BOOL、PATH、FILEPATH、STRING
set(USE_PNG ON CACHE BOOL "Do you want to use the png library?")

缓存条目的另外一个目的是， 存储那些难以确定的关键变量，这些变量可能对用户不可见。通常这些变量是系统相关的，例如

CMAKE_WORDS_BIGENDIAN

位于缓存中的变量具有一个属性指示它是否为“进阶的”（advanced），默认的CMake GUI隐藏进阶条目。要标记一个缓存条目为进阶的，可以：

mark_as_advanced(VAR_NAME)

某些情况下，你可能需要限制缓存条目的值范围在一个有限的集合中，这是可以设置条目的

STRINGS

# 设置名为CRYPT_BACKEND的缓存条目的值为Open SSL
set(CRYPT_BACKEND "Open SSL" CACHE STRING)
# 设置上述缓存条目的取值范围
set_property(CACHE CRYPT_BACKEND PROPERTY STRINGS "Open SSL" "LibDES")

即使变量存在于缓存，你仍然可以在CMakeLists中覆盖它（改变作用域中此变量的值）。只需要不带CACHE选项调用set命令，即可覆盖缓存中同名变量的值。 

另一方面，一旦变量值已经缓存，你一般无法在CMakeLists中改变缓存的值（与上述覆盖是两回事）。也就是说，当缓存中有VARNAME时，

set(VARNAME ON CACHE BOOL )

FORCE

CACHE

构建配置允许工程使用不同方式构建：debug、optimized或者任何其它标记。CMake默认支持四种构建配置：

依据生成器的不同，CMake处理构建配置的方式有所差异，CMake尽可能遵循底层本地构建系统的约定，这意味着使用Makefiles、VS时构建配置影响构建的方式有所不同：

1. VS支持构建配置的概念，在IDE中你可以选择Debug、Release配置，CMake只需要对接到VS的构建配置即可
2. Makefile默认同时（CMake运行时）只能有一种配置被激活。使用

   CMAKE_BUILD_TYPE

    变量可以指定目标配置。如果此变量为空，则不给构建添加额外标记。如果此变量设置为上面四种构建配置之一，则相应的变量、规则——例如

   CMAKE_CXX_FLAGS_<CONFIGNAME>

    被添加到compile line中。可以使用下面的方式来分别基于Debug、Release配置进行构建：
   

   # 创建工程目录的两个兄弟目录，CD到其中分别执行：
   cmake ../project -DCMAKE_BUILD_TYPE:STRING=Debug
   cmake ../project -DCMAKE_BUILD_TYPE:STRING=Release 

CMake由CMakeLists.txt驱动，此文件包含构建需要的一切信息。

除了用于分隔命令参数，其余空白符一律被忽略。反斜杠可以用来指示转义字符。

project (projectname, [CXX], [C], [JAVA], [NONE])

和普通编程语言一样，CMake支持条件、循环控制结构，同时支持子过程（macro、function）

if (FOO)
else(FOO)
endif(FOO)
# 上面把if的条件在else、endif中重复，这是可选的。因此我们可以简单的写作：
if (FOO)
else()
endif()

在else、endif上重复条件，有助于if-else-endif匹配检查，特别是多层嵌套时。

CMake同样支持elseif：

if(MSVC80)
  #...
elseif(MSVC90)
  #...
elseif(APPLE)
  #...
endif()

条件命令支持受限的表达式语法，如下表所列：

marjor[.minor[.patch[.tweak]]]

set(name Alex)
if(${name} MATCHES A.*x)
    message(${name})
endif()

CMake操作符优先级从高到底：

1. 括号分组：()
2. 前缀一元操作符：EXISTS、COMMAND、DEFINED
3. 比较操作符：EQUAL、LESS、GREATER及其变体，以及MATCHES
4. 逻辑非：NOT
5. 逻辑或于：AND、OR

foreach (item  list)
    # do something with item
endforeach (item)

此命令用于迭代一个列表，第一个参数是每次迭代使用变量的名称，其余参数为被迭代的列表

注意，在循环内部，你可以使用迭代变量构造另外一个变量的名字，例如

${NAME_OF_${item}}

此命令用于基于条件的迭代：

while(${COUNT} LESS 2000)
    set(TASK_COUNT, ${COUNT})
endwhile()

此命令用于中断foreach/while循环。

CMake中的函数很类似于C/C++函数。你可以向函数传递参数，除了依据形参名外，你还可以使用

ARGC

ARGV

ARGN

ARG0

ARG1

函数内部是一个新作用域，类似于add_subdirectory生成的新作用域一样，函数调用前的作用域被拷贝并传递到函数内部，函数返回时，新作用域消失。

函数的第一个形参是函数的名称，其它参数构成传统的形参列表：

function(println msg)
    message(${msg} "\n")
    set ( msg ${msg} PARENT_SCOPE )  #设置父作用域中变量的值
endfunction()

println(Hello)

此命令拥有从函数中返回，或者在listfile命令中提前结束。

宏于函数类似，但是宏不会创建新的作用域。传递给宏的参数也不被作为变量看待，而是在执行宏前替换为字符串：

macro (println msg)      #同样的，括号中第一个项目是宏的名称
    message(${msg} "\n")
endmacro()

对于宏， ARGC、ARG0、ARG1等也可以使用。ARG0代表传递给宏的第一个参数。

CMake是一个不断进化的工具，随着新版本的推出，会不断有新的命令被加入。很多时候，我们需要检查当前CMake版本是否支持某些特性。

我们可以使用if命令判断某个命令是否可用：

if(COMMAND some_new_command)
    #...
endif()

或者直接检查CMake的版本：

if (${CMAKE_VERSION} VERSION_GREATER 1.6.1)
endif()

另外，还可以声明要求的最低的CMake版本：

cmake_minimum_required(VERSION 2.8)

所谓模块，仅仅是存放到一个文件中，一系列CMake命令的集合。我们可以用

include

# 此模块用于查找TCL库
include (FindTCL)
# 找到后，将其加入到链接依赖中
target_link_libraries (FOO ${TCL_LIBRARY})

包含一个模块时，可以使用绝对路径，或者是基于CMAKE_MODULE_PATH的相对路径，如果此变量未设置，默认为CMake的安装目录的Modules子目录。

模块依据用途的不同可以分为：

# png库依赖于zlib
include(FindZLIB)  # 查找zlib库
if (ZLIB_FOUND)    # 往往在找到后设置LIBNAME_FOUND变量
    # 查找头文件位置并存入变量
    find_path(PNG_PNG_INCLUDE_DIR png.h /usr/local/include /usr/include)
    # 查找库文件位置并存入变量    
    find_library(PNG_LIBRARY png /usr/lib /usr/local/lib)
    if (PNG_LIBRARY AND PNG_PNG_INCLUDE_DIR)
        # 合并ZLIB头文件和库到PNG的
        set(PNG_INCLUDE_DIR ${PNG_PNG_INCLUDE_DIR} ${ZLIB_INCLUDE_DIR})
        set(PNG_LIBRARIES ${PNG_LIBRARY} ${ZLIB_LIBRARY})
        # 设置已找到标记
        set(PNG_FOUND YES)
    endif ()
endif ()

由于某些原因，在版本升级后，CMake可能不提供完全的向后兼容。这意味着使用新版的CMake处理基于旧版本的CMakeLists.txt时会出现问题。CMake引入策略这一特性，帮助用户和开发者处理此向后兼容问题。

策略机制实现以下目标：

1. 既有的工程能够用任何比CMakeLists作者使用的、更新版本的CMake构建。用户不应该需要修改CMakeLists代码，但是可能出现警告信息
2.  新特性的修正，老接口的Bug修复应当被执行，而非因向后兼容性的要求而搁置
3. 任何对CMake的改变，会导致CMakeLists文件必须更改的，应当加以文档说明。每个这样的改变应当具有唯一的标识符以便查阅文档，改变仅在工程提示自己支持的情况下才启用
4. 最终将会移除向后兼容性的代码，不再支持古老版本的CMake。因此而构建失败的工程必须得到有价值的错误提示

CMake中的所有策略被分配一个

CMPNNNN

可以在工程中对每个策略进行配置，设置其值为NEW或者OLD，CMake将遵从测量设置，从而表现出不同的构建行为。

设置策略有几种方式，最简单的是设置策略为特定的CMake版本：

cmake_policy(VERSION 2.6)

注：cmake_minimum_required命令同样会设置策略，因此仅在需要定制子目录的策略时才以VERSION选项调用cmake_policy命令。

以SET选项调用cmake_policy可以明确的设置单个策略。以CMP0002为例，该策略的新行为要求所有逻辑目标具有全局独特的名字。下面的命令可以抑制存在重复目标名时的警告信息：

cmake_policy(SET CMP0002 OLD)

# 设置库的寻找目录
link_directories(/path/to)
add_executable(myexe myexe.c)
target_link_libraries (myexe A B)

# 或者
add_executable(myexe myexe.c)
# 使用绝对路径
target_link_libraries (myexe /path/to/libA.so /path/to/libB.so )

类Unix操作系统的系统库常常位于/usr/lib或者/lib目录。这些目录被链接器作为隐含的库搜索目录，因此

find_library(M_LIB m)

问题是，某些平台会依据体系结构的不同，提供库的不同版本：

# IRIX机器
/usr/lib/libm.so         # ELF o32
/usr/lib32/libm.so       # ELF n32
/usr/lib64/libm.so       # ELF 64
# Solaris
/usr/lib/lim.so          # sparcv8架构
/usr/lib/sparcv9/lim.so  # sparcv9架构

find_library命令不知道各种体系结构特定的系统如何定义上面的目录规则，因此此命令可能找到不匹配的体系结构的库文件。

此问题的一个解决办法是让链接器自动寻找库所在目录（不使用link_directories或者指定绝对路径），不幸的是，此办法无法区分库的动态、静态版本。CMake实际使用的妥协做法是：

1. 存在于隐含库搜索目录中的库，且链接器支持类似-Bstatic的选项来指定使用静态库，使用-l选项传递库名称
2. 其它情况下，传递库绝对路径给链接器

共享库和可加载模块有利于重用：

1. 缩短compile/link/run周期
2. 共享库重新构建时，依赖于它的共享库/可执行文件甚至不需要重新构建
3. 减少磁盘和内存消耗，因为同一共享库只需要一份

相比静态库，共享库更像是可执行文件，大部分系统要求共享库上具有可执行权限。和可执行文件一样，共享库可以链接到其它共享库。

对于静态库来说，一个object文件是最小单元；而共享库（包括其依赖）本身是一个最小单元。链接器可以从静态库中挑出需要的object文件，但是对于共享库及其依赖的其它共享库，都需要存在。

共享库和静态库的另外一个不同是库的声明顺序，指定静态库时顺序很重要，因为大部分链接器仅仅遍历库列表一次来寻找符号，依赖其它静态库的静态库必须放在列表前面。

当决定在工程使用共享库时，开发者必须面对几个问题。

在大部分UNIX系统中，默认所有符号被导出。在Windows系统中，开发者必须明确告知编译器哪些符号被导入（使用符号时）/导出（创建符号时）

当从UNIX移植项目到Windows平台时，你可以：

1. 创建一个额外的.def文件，或者
2. 使用微软的C/C++语言扩展——

   __declspec(dllexport)

    、

   __declspec(dllimport)

    声明的符号分别被导出、导入

如果一个源文件在创建、使用一个库时都需要使用，则必须使用宏来处理。CMake在Windows下构建共享库（DDL）时，会自动定义宏

${LIBNAME}_EXPORTS

#if defined(WIN32)
    #if defined(vtkCommon_EXPORTS)
        #define VTK_COMMON_EXPORT __declspec(dllexport)
    #else
        #define VTK_COMMON_EXPORT __declspec(dllimport)
    #endif
#else
    #define VTK_COMMON_EXPORT
#endif

这样，VTK_COMMON_EXPORT在UNIX中为空白；在Windows下构建共享库时为__declspec(dllexport)。

UNIX和Windows存在一个重要的和符号需求相关的差异：Windows上的DLL需要完全解析，也就是在创建时必须链接所有符号；而UNIX允许共享库在运行时从可执行文件或者其它共享库中获取符号。因而在UNIX中，CMake会给可执行目标一个标记，允许它被共享库调用。

另外一个需要提及的关于C++全局对象的陷阱是，加载或者链接了C++共享库的main函数，必须基于C++的编译器来链接，否则cout之类的全局对象可能在使用时尚未初始化。

由于链接到共享库的可执行文件必须在运行时能找到这些库，特殊的环境变量或者链接器标记必须被使用。

不同系统都提供了工具，用以查看可执行文件实际上使用的是哪个库：

1. UNIX系统的

   ldd

    命令：显示可执行文件使用哪些库。在Mac OS X上使用

   otool -L

    
2. Windows系统的

   depends

    程序，功能类似

在很多UNIX系统中，可以使用环境变量

LD_LIBRARY_PATH

PATH

CMAKE_SKIP_RPATH=false

关于soname的基础知识，参考Linux编程知识集锦。

CMake支持这种基于soname的版本号编码机制，只要底层平台支持soname，可以设置共享库目标的属性：

# VERSION，指定一个版本号，用于创建文件名
# SOVERSION，指定一个版本号，用于生成SONAME头
set_target_properties (x PROPERTIES VERSION 1.2 SOVERSION 4)

设置上述属性后，安装共享库时会产生如下文件和符号链接：

libx.so.1.2
libx.so.4 -> libx.so.1.2
libx.so -> libx.so.4

如果仅指定两个版本号中的一个，那么另外一个自动与之相同。 

软件通常被安装到和源码、构建树无关的位置上。CMake提供一个

install

1. 对于基于Makefile的生成器，用户只需要执行

   make install

    或者

   nmake install

    即可完成安装
2. 对于基于GUI的平台，例如XCode、VS，用户只需要构建INSTALL目标

对install的每一次调用都会指定某些安装规则，这些规则会依据命令调用的顺序被执行。

install命令提供了若干“签名”（类似于子命令），签名作为第一个参数传入，可用的签名包括：

前四个签名都用于创建文件的安装规则，需要安装的目标、目录、文件紧接着签名列出。其余和安装相关的信息，以关键字参数的形式附加，大部分签名支持以下关键字：

CMAKE_INSTALL_PREFIX

以此签名调用install命令，以便构建过程中创建的库、可执行文件。详细调用格式为：

install ( TARGETS
    targets...  # 基于add_executable/add_library创建的目标的列表
    [
        # 通过TARGETS签名安装的文件可以分为三类：
        # ARCHIVE 静态库（UNIX/Cygwin/MinGW的.A、Windows的.LIB）
        #         DLL的可链接（Linkable）导入库（Cygwin/MinGW的.DLL.A、Windows的.LIB）
        # LIBRARY 可加载模块、共享库（.SO）
        # RUNTIME 可执行文件、动态链接库（.DLL）
        # 如果指定下面一行的某个关键字，则后续的关键字仅针对特定类型的文件，否则针对所有文件
        [ARCHIVE|LIBRARY|RUNTIME|FRAMEWORK|BUNDLE|PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE]
        [DESTINATION <dir>]
        [PERMISSIOS permissions...]
        [CONFIGURATIONS [Debug|Release|...]]
        [COMPONENT component]
        [OPTIONAL]
        [EXPORT <export name>]
        # 下面的关键字仅用于LIBRARY类型，仅针对支持namelink、版本化共享库的平台
        # 对于符号链接lib<name>.so -> lib<name>.so.1，后者是soname，前者称为namelink，namelink用于在链接时-l选项找到共享库的位置
        # NAMELINK_ONLY导致仅仅共享库的namelink被安装；NAMELINK_SKIP导致除了namelink之外的文件被安装
        # 如果不指定，那么namelink、共享库的文件都被安装
        [NAMELINK_ONLY|NAMELINK_SKIP]
    ] [
        ... #仅需要针对不同类型（ARCHIVE|LIBRARY|RUNTIME...）分别设置关键字时，才会出现
    ]
)

注意上面代码中关于文件分类的规则，把同属于共享库的.SO、.DLL分别划分到LIBRART、RUNTIME是有意的设计，因为Windows平台下，DLL通常和EXE存放在一个目录，这样才能确保DLL能够被找到并加载。下面的调用确保共享库目标mySharedLib产生的所有文件在所有平台上均安装到期望的位置：

install ( TARGETS myExecutable mySharedLib myStaticLib myPlugin
    RUNTIME DESTINATION bin             COMPONENT Runtime
    LIBRARY DESTINATION lib             COMPONENT Runtime
    ARCHIVE DESTINATION lib/myproject   Component Development    #静态库只有在二次开发时才需要
)

很多工程可能需要安装与目标无关的任何文件，这时可以使用一般目的的FILES签名：

install (FILES files...     #需要被安装的文件的列表，如果是相对路径，相对于当前Source目录
    DESTINATION <dir>       #目标位置，如果是相对路径，相对于安装Prefix
    [PERMISSIOS permissions...] #默认权限644
    [CONFIGURATIONS [Debug|Release|...]]
    [COMPONENT component]
    [RENAME <name>]  #为文件指定新的名称，要求文件列表只有一个元素
    [OPTIONAL]
)

某些工程可能安装额外的助手程序——Shell脚本或者Python脚本。这时可以使用PROGRAMS签名。此签名和FILES一样，只是默认权限为755。

有时候我们需要安装包含了大量资源文件的整个目录，此时使用DIRECTORY签名： 

install (DIRECTORY dirs...   # 需要被安装的目录的列表，如果是相对路径，相对于当前Source目录
    # 目标位置，此目录确保被创建。如果设置为share/myproject，则：
    # data/icons 被安装到/share/myproject/icons，注意输入目录的所有祖先目录被忽略
    # data/ 被安装到/share/myproject，注意结尾的斜杠，会导致此目录下所有内容被安装，因此data/类似于data/*
    DESTINATION <dir>   
    # 默认权限：文件与FILES一样644，目录与PROGRAMS一样755，下面两个关键字用于修改默认行为
    [FILE_PERMISSIOS permissions...]
    [DIRECTORY_PERMISSIOS permissions...]
    # 和文件来源保持一致的权限
    [USE_SOURCE_PERMISSIOS]
    [CONFIGURATIONS [Debug|Release|...]]
    [COMPONENT component]
    [
        # 排除某些文件，或者为某些文件指定特殊的权限
        # PATTERN用于UNIX风格通配符匹配；REGEX用于正则式匹配
        [PATTERN <pattern> | REGEX <regex>]
        # 是否把匹配的文件排除，不安装
        [EXCLUDE]
        # 设置匹配文件的权限
        [PERMISSIOS permissions...]
    ]
    [
    ...  #排除或者chmod其它匹配文件
    ]
)

拷贝文件到安装树下（Installation tree）不是安装过程的唯一内容，有时候需要执行特定的逻辑。这时可以使用SCRIPT或者CODE签名：

install(SCRIPT scr.cmake)   # scr.cmake为某个CMake脚本名称
install(CODE "message(Hello)") #直接跟着脚本内容

注意脚本不是在CMakeLists.txt处理过程中，而是在安装过程中执行，因而在脚本中不能访问CMakeLists.txt定义的变量。尽管如此，

CMAKE_INSTALL_PREFIX

CMAKE_INSTALL_CONFIG_NAME

CMAKE_INSTALL_COMPONENT

OS自带的、第三方提供的或者工程本身生成的共享库，是某些可执行文件能够运行的前提条件。由OS提供的自然不需要额外安装；工程本身产生的库由add_library命令说明，一般通过install命令安装到系统。需要额外考虑的是第三方库。

CMake提供两个模块，用于简化共享库的处理。

使用该模块的

get_prerequisites()

使用该模块的

fixup_bundle()

对于Mac的bundle应用，需要的共享库会被嵌入到bundle中，并调用install_name_tool生成一个自包含bundle。

对于Widnows，需要的共享库会被拷贝到exe所在目录，可执行文件运行时会自动寻找并加载。

要使用fixup_bundle()函数，首先安装某个可执行目标，然后创建一个可以在安装时执行的CMake脚本，在此脚本中调用：

include (BundleUtilities)
# 安装树中的可执行文件的路径
set (bundle "${CMAKE_INSTALL_PREFIX}/myExecutable@CMAKE_EXECUTABLE_SUFFIX@")
# 无法通过依赖分析到达的依赖库的列表
set (other_libs "")
# 可以寻找到前置依赖库的目录的列表
set (dirs "@LIBRARY_OUTPUT_PATH@")

# 调用
fixup_bundle("${bundle}" "${other_libs}" "${dirs}")

CMake 2.6开始，支持在两个CMake工程之间导入导出目标。

导入目标这一机制，用于将项目外部的磁盘文件转换为逻辑的CMake目标。在调用add_executable、add_library命令时，传递

IMPORTED

下面的例子定义了一个导入的可执行文件，仅仅将其作为命令调用：

# 声明一个名为generator的导入目标
add_executable(generator IMPORTED)
# 设置目标的实际位置
set_property(TARGET generator PROPERTY IMPORT_LOCATION "/path/to/generator")
# 调用自定义命令，即添加一条定制的构建规则
# 底层构建系统执行类似这样的命令/path/to/generator /project/binary/dir/generated.c
add_custom_command(OUTPUT generated.c COMMAND generator generated.c)

下面的例子定义了一个导入的库，并与之链接：

add_library(foo IMPORTED)

# Linux
set_property(TARGET foo PROPERTY IMPORTED_LOCATION "/path/to/libfoo.a")
# Windows下需要同时导入.lib和.dll
set_property(TARGET foo PROPERTY IMPORTED_LOCATION "/path/to/libfoo.dll")
set_property(TARGET foo PROPERTY IMPORTED_IMPLIB "/path/to/libfoo.lib")
# 具有多个构建配置的库，可以作为单个目标导入
set_property(TARGET foo PROPERTY IMPORTED_LOCATION_RELEASE "/path/to/libfoo.a")
set_property(TARGET foo PROPERTY IMPORTED_LOCATION_DEBUG   "/path/to/debug/libfoo.a")
add_executable(myexe src1.c)
target_link_libraries(myexe foo)

尽管导入机制很有用，但是作为导入者来说，你必须知道目标在磁盘的位置。

使用导出机制，可以在提供目标文件的同时，提供一个文件，帮助其它工程导入。联合使用

install(TARGETS)

install(EXPORTS)

add_executable(generator generator.c)
# EXPORT选项导致生成一个助手文件，该文件是一个CMake脚本，可以让其它工程方便的导入generator
install(TARGET generator DESTINATION lib/myporj/generators EXPORT myproj-targets)
# 安装助手文件
install(EXPORT myproj-targets DESTINATION lib/myproj)

助手文件的内容可以是：

# get_filename_component命令拥有得到一个全路径的某个部分
# 第一个参数：结果变量；第二个参数：待解析的路径；第三个参数，需要得到的部分，可以是DIRECTORY/NAME/EXT/PATH...
# CMAKE_CURRENT_LIST_FILE当前正在处理文件的路径
get_filename_component(_self "${CMAKE_CURRENT_LIST_FILE}" PATH)
# 解析出安装前缀的绝对路径
get_filename_component(PREFIX "${_self}/../.." ABSOLUTE)
# 添加导入目标
add_executable(generator IMPORTED)
# 通过计算出的路径引用目标
set_property(TARGET generator PROPERTY IMPORTED_LOCATION "${PREFIX}/lib/myproj/generators/generator")

注意上面这个脚本依据自身位置动态计算出目标位置，即使移动安装目录，也不会失效。 

其它工程只需要包含助手文件即可：

include(/lib/myproj/myproj-targets.cmake)
# generator已经导入
add_custom_command(OUTPUT generated.c COMMAND generator generated.c)

注意，单个助手文件可以容纳多个目标，甚至这些目标不在同一个目录中：

# A/CMakeLists.txt
add_executable(generator generator.c)
install(TARGETS generator DESTINATION lib/myproj/generators EXPORT myproj-targets)
# B/CMakeLists.txt
add_library(foo STATIC foo1.c)
install(TARGETS foo DESTINATION lib EXPORT myproj-targets)  #导出为同一个EXPORT

# CMakeLists.txt
add_subdirectory(A)
add_subdirectory(B)
install(EXPORT myproj-targets DESTINATION lib/myproj)

典型情况下，在第三方工程需要导入之前，当前工程已经构建并安装，因此导出一般是基于安装树的。

CMake直接从构建树导出 ，这样第三方工程可以参考构建树来导入，这样就可以避免安装当前工程了。

使用

export

add_executable(generator generator.c)
export (TARGETS generator FILE myproj-exports.cmake)

第三方工程可以include当前工程构建树下的myproj-exprots.cmake文件，其中包含导入generator需要的全部信息。

这种导出方式在交叉编译场景下可以用到。

系统探测，即检测在其上构建的系统的各种环境信息，是构建跨平台库或者应用程序的关键因素。

很多C/C++程序依赖于外部的库，然后在编译和链接一个工程时，如何找到已经存在的头文件和库并不容易。因为开发程序的机器，和构建并安装程序的机器中，库的安装位置可能不一样。CMake提供多种特性，辅助开发者把外部库集成到工程中。 

与集成外部库相关的命令包括：

find_library

find_path

find_program

find_package

# 寻找一个库
find_library(
        TIFF_LIBRARY
        NAMES tiff tiff2  #只需要库的basename，不需要平台特定的前缀、后缀。前面的库优先
        #额外的路径，支持Windows注册表条目，例如[HKEY_CURRENT_USER\\Software\\Path;Build1]
        PATHS /usr/local/lib /usr/lib       #前面的路径优先
)
# 寻找一般性的文件，仅支持一个待查找文件，支持多个路径
find_path(
        TIFF_INCLUDES
        tiff.h
        /usr/local/include /usr/include
)
include_directories(${TIFF_INCLUDES})
add_executable(mytiff mytiff.c)
target_link_libraries(mytiff ${TIFF_LIBRARY})

注意：

1. find_*命令总是会寻找PATH环境变量
2. find_*命令会自动创建对应的缓存条目（文件没找到的情况下值为

   VAR-NOTFOUND

    ），便于用户手工修改。这样即使CMake没有找到文件，用户还可以手工的修复

在跨平台软件中，应当避免使用平台特定的代码，例如：

// 基于系统的判断
#ifdef defined(SUN) && defined(HPUX)
    foobar();
#endif

 这会降低代码的可移植性，每当需要支持新的系统，都要改变代码。即便非要使用宏，也最好使用基于特性，而不是基于系统的判断。可以改造上述代码为：

#ifdef HAS_FOOBAR_FUNC
    forbar();
#endif

通过

try_compile

try_run

try_compile(
        HAS_FOOBAR_FUNC
        ${CMAKE_BINARY_DIR}
        ${PROJECT_SOURCE_DIR}/testFoobar.c  #尝试调用forbar()函数
)

如果编译成功，则CMake变量HAS_FOOBAR_FUNC为真。我们可以通过

add_definitions

如果单纯的编译并不够，还需要获知探测代码的运行结果，可以使用：

int main() {
    union {
        int i;
        char c;
    } u;
    u.i = 65;
    exit( u.c == 'A' );
} 

try_run(
        RUN_RESULT_VAR  #尝试运行的返回结果
        COMPILE_RESULT_VAR  #编译结果
        ${CMAKE_BINARY_DIR}
        ${PROJECT_SOURCE_DIR}/Modules/TestByteOrder.c
        OUTPUTVAR OUTPUT  #运行的任何输出
)

运用上述命令的运行结果，可以根据字节序的不同来定制构建过程或者设置宏定义。对于较小的测试程序，可以不特定编写文件，使用

file

file(WRITE ${CMAKE_BINARY_DIR}/tmp/testc "int main(){return 0;}")

在CMake/Modules中预定义了若干CMake用，可简化日常工作。这些宏常常需要查看当前

CMAKE_REQUIRED_FLAGS

CMAKE_REQUIRED_LIBRARIES

CMake提供

find_package(Package [version])

该命令可以在两个模式下运行：

1. Module模式：此模式下CMake会依次扫描

   CMAKE_MODULE_PATH

   、CMake安装目录。尝试寻找到一个名称为

   Find<Package>.cmake

    的查找模块。如果找到则加载之，并调用其来寻找目标包的全部组件。查找模块针对特定包编写，它了解此包的全部版本，能找到包的库或者其它文件。CMake提供了很多常用的查找模块
2. Config模式：如果Module模式下没有定位到查找模块，命令自动切换到Config模式（你也可以显式的调用该模式）。在该模式下，命令会寻找包配置文件（package configuration file）：目标包提供的、一个名为

   <Package>Config[Version].cmake

    或者

   <package>-config[-version].cmake

    的文件。只要给出包的名称，命令就知道从何处寻找包配置文件，可能的位置是

   <prefix>/lib/<package>/<package>-config.cmake

    

CMake的内置查找模块，在找到包后，一般会定义一系列的变量供当前工程使用：

要传递参数给编译器，可以指定命令行，或者使用一个预先配置好的头文件。

调用

add_definitions

#定义一个布尔的缓存条目
option(DENIG_BUILD "Enable debug messages")
if (DEBUG_BUILD)
    #添加宏定义
    add_definitions(-DDEBUG_MSG)
endif ()

如果要细粒度的控制宏定义，可以设置目录、目标、源文件的

COMPILE_DEFINITIONS

add_library(mylib src1.c src2.c)
# 可以添加APPEND选项，追加值而不是覆盖
set_property(DIRECTORY PROPERTY COMPILE_DEFINITIONS A AV=1)
set_property(TARGET mylib PROPERTY COMPILE_DEFINITIONS B BV=2)
set_property(SOURCE src1.c PROPERTY COMPILE_DEFINITIONS C CV=3)
# 执行上述命令后，编译参数分别为：
# src1.c -DA -DAV=1 -DB -DBV=2 -DC -DCV=3
# src2.c -DA -DAV=1 -DB -DBV=2 
# main.c -DA -DAV=1

这种方式更可维护，大部分工程应当使用该方式。应用程序只需要引入预先配置好的头文件即可，不必编写复杂的CMake规则。

我们可以把头文件看作一种配置文件，而要生成配置文件，可使用

configure_file(input output [@ONLY])

// 第一种方式
#cmakedefine VARIABLE
// 如果VARIABLE为真，则输出：
#define VARIABLE
// 否则输出：
/* #undef VARIABLE */

//第二种方式，直接输出变量的值。如果confgure_file命令传递@ONLY选项，则这种方式不能使用
${VARIABLE}

//第三种方式，直接输出变量的值
@VARIABLE@

配置文件应当输出到二进制树，而不是源码树，避免代码污染。因为单个CMake的源码树可以供多种构建树或平台使用，它们生成的配置文件常常是不一样的。你可能需要用include_directories命令将配置文件所在目录作为头文件目录。

除了头文件以外，

configure_file

很多时候，“构建”一个工程不仅仅是简单的编译、链接、拷贝，额外的工作——例如利用文档工具生成文档—— 需要在构建过程中完成。

通过定制命令和目标，CMake可以被扩展以支持任意的任务（或者说规则）。

定制命令时，面临的一个重要问题是可移植性：

1. 各平台上用于完成一项任务的工具不同，以复制文件为例，UNIX使用cp命令，Windows则使用copy命令
2. 目标在各平台上的名字不同，例如库x在UNIX上可能叫libx.so，Windows上则叫x.dll

CMake提供了两个主要工具，解决上面两个可移植性问题。

使用

cmake -E arguments

CMAKE_COMMAND

支持的操作（arguments）包括：

CMake不限制你仅使用cmake命令，事实上你可以使用任何命令，但是要注意可移植性问题。一个通用的实践是，通过

find_program

CMake提供了一系列预定义的变量，描述系统的特征：

./

$(INTDIR)/

add_custom_command有两个主要的签名：TARGET、OUTPUT，分别用于为目标或者文件添加额外的规则。其中TARGET签名语法如下：

add_custom_command(
    #目标的名称
    TARGET target  
    #执行触发时机：
    #pre_build，在目标任何依赖文件被构建之前执行
    #pre_link，在所有依赖已经构建好，但是尚未链接时执行
    #post_build，在目标已经构建好后执行
    PRE_BUILD | PRE_LINK | POST_BUILD
    # command为可执行文件的名称
    COMMAND command [ARGS arg1 arg2 ... ]
    [COMMAND command [ARGS arg1 arg2 ... ] ...]
    # 注释，在定制命令运行时打印
    [COMMENT comment]
)

下面是一个例子，在目标构建好后立即拷贝之： 

add_executable(myExe my.c)
get_target_property(EXE_LOC myExe LOCATION)
add_custom_command(
    TARGET myExe
    POST_BUILD
    COMMAND ${CMAKE_COMMAND} ARGS -E copy ${EXE_LOC} /QC/files
)

add_custom_command的另外一个用途是指定生成一个文件的规则。这种情况下，已有的用于生成目标文件的规则被替换掉。语法如下：

add_custom_command (
    # 指定命令运行生成的结果文件，最好指定完整路径
    OUTPUT output1 [output2 ...]
    # 需要执行的命令
    COMMAND command [ARGS [args ...]]
    [ COMMAND command [ARGS [args ...]] ...]
    # 主要用于VS
    [MAIN_DEPENDENCY depend]
    # 命令依赖于的文件，最好指定完整路径（依赖是目标则不必），这些文件中的任何一个变化后，命令都需要重新执行
    [DEPENDS [depends ...]]
    [COMMENT comment]
)

在某些库的构建过程中，例如TIFF，会先编译并构建一个可执行文件，再用此可执行文件生成还有系统特定信息的源码，而此源码参与库的最终构建。这种场景下，可以使用add_custom_command来生成源码。

CMake支持除了库、可执行文件之外的，更一般概念上的目标，称为定制目标。生成文档、运行测试、更新Web服务器都可以抽象为目标。

要添加定制目标，需要调用下面的命令：

add_custom_target(
    # name为目标的名称，如果使用Makefile生成器，你可以调用make name来生成此目标
    # ALL，表示该目标包含在ALL_BUILD目标中，自动构建
    name [ALL]
    # 执行的命令
    [command arg arg ...]
    # 此目标依赖的文件的列表，最好指定完整路径（依赖是目标则不必），这些文件可以是add_custom_command(OUTPUT)生成的
    [DEPENDS dep dep ...]
)

所谓交叉编译，就是指软件在一个平台（Build host）上构建，而在另外一个平台（Target Platform）上运行。目标平台往往是另外一个OS甚至没有OS，也常常使用与构建平台不一样的硬件，这导致目标平台根本不能运行开发环境。交叉编译的典型应用是嵌入式开发，程序需要在路由器、传感器之类的特殊硬件上运行。

交叉编译依赖于工具链。工具链是针对目标平台的一整套工具，包括编译器、链接器，以及目标平台的全套头文件、库。

从2.6开始，CMake完整的支持交叉编译，包括Linux-Windows交叉编译，或者PC-嵌入设备交叉编译。在交叉编译场景下，会面临以下问题：

1. CMake无法自动的检测目标平台
2. CMake无法在默认系统目录寻找库、头文件
3. 构建出来的可执行文件无法运行

CMake区分构建平台、运行平台的信息，让给用户可以解决交叉编译相关的问题，避免例如运行虚拟机的额外需求。

通过一个所谓工具链（Toolchain）文件，我们可以告知CMake关于目标平台的任何必要信息。CMakeList.txt必须被调整以适应目标平台和构建平台具有不同属性的情况。下面是一个Linux下基于MinGW交叉编译器，交叉编译Windows程序使用的工具链文件：

#目标平台的名称
set( CMAKE_SYSTEM_NAME Windows )

#指定C/C++编译器为交叉编译器，只有交叉编译器才知道如何构建目标平台上的二进制文件
set( CMAKE_C_COMPILER i586-mingw32msvc-gcc )
set( CMAKE_CXX_COMPILER i586-mingw32msvc-g++ )

#指定目标平台环境的位置，这一位置在构建平台中，但是存放的是目标平台需要的头文件、库
set( CMAKE_FIND_ROOT_PATH /usr/i586-mingw32msvc /home/alex/mingw-install )

#调整find_***命令的行为
#仅在构建平台上寻找程序
set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
#仅在目标平台环境中寻找头文件、库
set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )

通过下面的命令，可以指示CMake使用上述工具链文件：

cd src/build
cmake -DCMAKE_TOOLCHAIN_FILE=~/TC-mingw.cmake ...

CMAKE_TOOLCHAIN_FILE必须在最初运行时设置，后续其值会保存为缓存条目。每个目标平台一般只需要一个工具链文件。

在工具链文件中，可能需要设置以下变量：

CMAKE_CROSSCOMPILING

${CMAKE_SYSTEM_NAME}-COMPILER_ID-${CMAKE_SYSTEM_PROCESSOR}.cmake

注：形如CMAKE_SYSTEM_XXX的变量，总是在描述目标平台。如果要描述当前构建平台，可以使用相应的CMAKE_HOST_SYSTEM_XXX变量。

CMake提供了一些变量，用于粗粒度的测试系统特征：

1. 目标平台类型指示变量：UNIX、WIN32、APPLE
2. 构建平台类型指示变量：CMAKE_HOST_UNIX、 CMAKE_HOST_WIN32、CMAKE_HOST_APPLE

更加细化的测试变量，可以使用上节提到的CMAKE_SYSTEM_XXX、CMAKE_HOST_SYSTEM_XXX变量。

CMake中使用CHECK_INCLUDE_FILES、CHECK_C_SOURCE_RUNS等宏来测试平台属性，这些宏通常使用try_compile、try_run命令。

try_run无法正常运行，因为交叉编译出的可执行文件不能在构建平台上运行。try_run被调用时，它首先尝试编译，如果成功它会检查CMAKE_CROSSCOMPILING变量，该变量为真的话它不会尝试运行，而是设置两个缓存变量，供用户后续修改。考虑下面这个例子：

try_run(
        SHARED_LIBRARY_PATH_TYPE
        SHARED_LIBRARY_PATH_INFO_COMPILED
        ${PROJECT_BINARY_DIR}/CMakeTmp
        ${PROJECT_SOURCE_DIR}/CMake/SharedLPathInfo.cxx
        OUTPUT_VARIABLE OUTPUT
        ARGS "LDPATH"
)

如果SharedLPathInfo.cxx编译成功，SHARED_LIBRARY_PATH_INFO_COMPILED被设置为真。而交叉编译时无法运行可执行文件，因此CMake创建一个缓存条目：

SHARED_LIBRARY_PATH_TYPE=PLEASE_FILL_OUT-FAILED_TO_RUN

SHARED_LIBRARY_PATH_TYPE__TRYRUN_OUTPUT=PLEASE_FILL_OUT-NOTFOUND

要手工运行，可以考虑构建目录下的

cmTryCompileExec-SHARED_LIBRARY_PATH_TYPE

除了设置缓存条目外，还可以把运行结果记录到

${CMAKE_BINARY_DIR}/TryRunResults.cmake

cmake -C ~/TryRunResults-myproj-eldk-ppc.cmake

本节示例一个完整的交叉编译的过程。

交叉编译的第一步是寻找合适的工具链，如果你已经安装好工具链，则可以跳过这一步。

不同工程——包括基于Linux的PDA和嵌入式设备厂商的——在Linux上处理交叉编译的途径不同，它们有自己的构建流程和工具链。CMake可以使用这些工具链，只要它们是基于普通文件系统的。

一个提供较为完整的目标平台环境的工具链套件是Embedded Linux Development Toolkit（ELDK），该套件支持ARM、PowerPC、MIPS等目标平台。ELDK或者其它工具链可以被安装在构建平台的任意位置，例如：

# 工具链
/home/alex/eldk-mips/usr/bin
# 目标平台环境
/home/alex/eldk-mpis/mips_4KC/

下载并安装好工具链后，下一步就是编写工具链文件，注意我们在上面提到过，每个工具链只需要一个这样的文件：

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_C_COMPILER /home/alex/eldk-mips/usr/bin/mips_4KC-gcc)
set(CMAKE_CXX_COMPILER /home/alex/eldk-mips/usr/bin/mips_4KC-g++)
set(CMAKE_FIND_ROOT_PATH /home/alex/eldk-mips/mips-4KC /home/alex/eldk-mips-extra-install)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE  ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY  ONLY)

工具链文件可以存放在任何地方，推荐将其存放在统一的目录，方便其它工程重用。 

int main(){
    exit(0)
}

project(Hello)
add_executable(Hello Hello.c)

mkdir eldk-mips
cd eldk-mips
# 调用cmake，指定工具链文件
cmake -DCMAKE_TOOLCHAIN_FILE=~/CPP/cmake/toolchains/ToolChain-eldk-mips4K.cmake ..
# 生成器已经生成Makefile，可以构建
make VERBOSE=1

不但支持具有OS的目标平台的交叉编译，CMake还可以针对那些没有OS的微控制器进行交叉编译。

本节的例子使用SDCC编译器，该编译器可以运行于主流系统下，支持8/16位微控制器的交叉编译。

首先，还是编写工具链文件：

set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR i8501)
set(CMAKE_C_COMPILER "D:/CPP/sdcc/bin/sdcc.exe")

对于没有OS的目标平台，其系统名称设置为Generic。CMake假设Generic平台不支持共享库。 

很多微控制器工程不需要依赖任何外部库，因此往往不需要设置影响find_**的变量。

CMakeLists文件：

# 明确声明使用C语言，因为SDCC不支持C++
project (Blink C)
add_library(blink blink.c)
add_executable(hello main.c)JSONCPP_INCLUDE_DIRS
target_link_libraries(hello blink)

执行构建：

rem 使用MS NMake生成器驱动构建
cmake -G "NMake Makefiles" -DCMAKE_TOOLCHAIN_FILE=D:/CPP/cmake/toolchains/Toolchain-sdcc.cmake ..
rem 执行构建
namke

此命令是cmake的命令行接口

cmake [options] <path-to-source>
cmake [options] <path-to-existing-build>

cmake 
    -DCMAKE_BUILD_TYPE:STRING=Debug           # 构建配置
    -DCMAKE_INSTALL_PREFIX:STRING=/usr        # 安装位置

其它变量参考这里。 

可以使用CMake 3.1引入的变量：

set(CMAKE_CXX_STANDARD 11) 

如果要对老版本CMake兼容，参考下面的宏：

macro(use_cxx11)
  if (CMAKE_VERSION VERSION_LESS "3.1")
    if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
      set (CMAKE_CXX_FLAGS "-std=gnu++11 ${CMAKE_CXX_FLAGS}")
    endif ()
  else ()
    set (CMAKE_CXX_STANDARD 11)
  endif ()
endmacro(use_cxx11)

全局性宏定义：

# 定义宏MACRO_NAME，注意前面的-D
add_definitions(-DMACRO_NAME)
# 赋值
add_definitions(-DMACRO_NAME=${value})

针对某个目标：

# 仅仅能用于 add_executable() 或 add_library() 添加的目标

# 格式：
target_compile_definitions(<target>
  # PUBLIC、INTERFACE可以将宏定义传递给target的PUBLIC、INTERFACE条目
  <INTERFACE|PUBLIC|PRIVATE> [items1...]
  [<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])

# 示例：
target_compile_definitions(hello PRIVATE A=1 B=0)

# 你也可以直接设置目标属性  COMPILE_DEFINITIONS

使用环境变量：

export CC=/home/alex/CPP/lib/gcc/7.2.0/bin/gcc
export CXX=/home/alex/CPP/lib/gcc/7.2.0/bin/g++

在基于CLion开发时，将上述内容添加到clion.sh脚本中 

The post CMake学习笔记 appeared first on 绿色记忆.