ติดตั้ง GLUT บน Windows

สร้างไดเรคทอรีสำหรับเก็บไลบรารี

หากผู้อ่านใช้ Linux หรือ Mac OS X ก็ไม่มีความจำเป็นจะต้องติดตั้งไลบรารีสองไลบรารีข้างต้นแต่อย่างใด เนื่องจากมันติดมากับระบบปฏิบัติการแล้ว อย่างไรก็ดีผู้อ่านที่ใช้ Windows จะต้องมีการติดตั้ง GLUT ให้ CMake สามารถค้นหาเจอได้ วิธีการติดตั้งนี้ความจริงแล้วมีหลายวิธี แต่ผู้เขียนจะนำเสนอวิธีการติดตั้งของตัวเองไว้ ณ ที่นี้

ผู้เขียนได้สร้างไดเรคทอรีหนึ่งในฮาร์ดดิสก์ไว้สำหรับเก็บไลบรารีภาษา C/C++ โดยเฉพาะ ในบทความนี้ขอสมมติให้เป็นไดเรคทอรี C:\usr\local เพื่อให้คล้ายๆ กับไดเรคทอรีใน Unix ในไดเรคทอรีนี้จะได้เรคทอรีย่อดังสองไดเรคทอรีที่สำคัญคือ

• C:\usr\local\include สำหรับเก็บ header file
• C:\usr\local\lib สำหรับเก็บไลบรารีที่อยู่ในรูปไฟล์ .lib
• C:\usr\local\bin สำหรับเก็บไลบรารีที่อยู่ในรูปไฟล์ .dll

หลังจากนั้นผู้เขียนจะกำหนด environmental variable ของ Windows สองตัวดังต่อไปนี้ (คุณสามารถดูวิธีกำหนด environmental variable ได้ที่ เวบไซต์นี้)

• เพิ่ม C:\usr\local\bin เข้าในตัวแปร PATH ซึ่งมีอยู่แล้ว
• สร้างตัวแปร CMAKE_PREFIX_PATH ใหม่และให้มันมีค่าเท่ากับ C:\usr\local

CMake จะดูค่าของตัวแปร CMAKE_PREFIX_PATH เวลามันค้นหาไดเรคทอรีของไลบรารีต่างๆ การกำหนด CMAKE_PREFIX_PATH ไม่มีความจำเป็นใน Linux หรือ Mac OS เนื่องจากแพลตฟอร์มเหล่านั้นมีมาตรฐานโครงสร้างไดเรคทอรีกำหนดอยู่ตายตัว ไม่เหมือนกับ Windows

ลง GLUT

คุณสามารถดาวน์โหลด GLUT สำหรับ Windows ได้ที่เวบไซต์ของ Nate Robins เราแนะนำให้คุณดาวน์โหลด glut-3.7.6-bin.zip มาแล้วขยายมันออก แล้วให้คัดลอกไฟล์เหล่านี้ใส่ไดเรคทอรีดังต่อไปนี้

• glut32.dll ลงใน C:\usr\local\bin
• glut32.lib ลงใน C:\usr\local\lib
• glut.h ลงใน C:\usr\local\include\GL โดยที่คุณต้องสร้างไดเรคทอรี C:\usr\local\include\GL ขึ้นมาก่อน

โปรแกรมวาดรูปสี่เหลี่ยมจัตุรัส

เราจะเขียนโปรแกรม square สำหรับวาดรูปสี่เหลี่ยมจัตุรัสโดยใช้ OpenGL และ GLUT อันดับแรกเราจะสร้างไดเรคทอรีของโปรเจคซึ่งมีไฟล์อยู่ดังต่อไปนี้

sample/
    build/
    src/
        CMakeLists.txt
        config.h.in
        square/
            CMakeLists.txt
            square.cpp

ซึ่งเหมือนกับโครงสร้างไดเรคทอรีในบทความเกี่ยวกับการตรวจสอบแพลตฟอร์มก่อนหน้านี้ ไฟล์ config.h.in นั้นมีเนื้อหาเหมือนเดิม ที่เปลี่ยนคือไฟล์ CMakeLists.txt ทั้งสองไฟล์ แต่เราจะพูดถึงมันทีหลัง

ไฟล์ square.cpp มีเนื้อหาดังนี้

#include "../config.h"

#ifdef __WIN_PLATFORM__
#include <windows.h>
#endif

#ifdef __MAC_PLATFORM__
#include <OpenGL/gl.h>
#include <OpenGL/glu.h>
#include <GLUT/glut.h>
#else
#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glut.h>
#endif

void display()
{
    glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
    glClearDepth(1.0f);
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    glColor3f(1.0f, 1.0f, 1.0f);
    glBegin(GL_QUADS);
    glVertex2f(-0.5f, -0.5f);
    glVertex2f( 0.5f, -0.5f);
    glVertex2f( 0.5f,  0.5f);
    glVertex2f(-0.5f,  0.5f);
    glEnd();
    glutSwapBuffers();
}

int main(int argc, char **argv)
{
    glutInit(&argc, argv);
    glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH);
    glutCreateWindow("CMake with OpenGL and GLUT");
    glutInitWindowSize(512, 512);
    glutDisplayFunc(display);
    glutMainLoop();
    return 0;
}

สังเกตว่าในโค้ดข้างบน ก่อนที่ถึงโค้ดที่ทำงานจริง มีโค้ดส่วนหนึ่งที่ใช้ include ไฟล็ที่เหมาะสมซึ่งค่อนข้างยาว (13 บรรทัด) แสดงให้เห็นถึงความยุ่งยากในการเขียนโปรแกรมภาษา C++ ให้ทำงานได้หลายแพลตฟอร์ม ถึงแม้ว่าเราจะมีตัวช่วยอย่าง CMake อยู่ก็ตาม (ดังนั้นจึงไม่แปลกดอกที่คนหันไปใช้ Java หรือ C# มากกว่า)

การใช้ OpenGL และ GLUT มีรายละเอียดพอสรุปได้ดังนี้

• แพลตฟอร์มต่างๆ เก็บ OpenGL อยู่คนละที่กัน ดังนั้นเราจึงต้องมีการใช้ preprocessor macro ใน config.h สำหรับตรวจสอบแพลตฟอร์ม และนี่เป็นเหตุผลที่เราต้อง include ../config.h

• ใน Windows ก่อนที่เราจะ include GL/gl.h เราจะต้องทำการ include windows.h ก่อนเสมอ แต่ในแพลตฟอร์มอื่นเราไม่ต้องทำเช่นนั้น

• หากผู้อ่านติดตั้ง GLUT ตามที่ผู้เขียนบอกไว้แล้ว วิธีการ include ไฟล์ของ OpenGL และ GLUT ใน Windows และใน Linux จะมีลักษณะเหมือนกัน กล่าวคือทั้งสามไฟล์อยู่ในไดเรคทอรี GL ซึ่งอยู่ในไดเรคทอรีที่ CMake ไปหา OpenGL และ GLUT เจออีกที

• ในทางกลับกัน Mac OS เก็บ OpenGL และ GLUT แยกกัน แถมยังเก็บไม่เหมือนของระบบอื่นๆ เลย ทำให้ชื่อไฟล์ header ของ OpenGL ต้องมี OpenGL/ นำหน้า ส่วน header ของ GLUT ต้องมี GLUT/ นำหน้า

คำสั่ง FIND_PACKAGE

CMake เรียกไลบรารีภายนอกว่า “package” และมีคำสั่ง FIND_PACKAGE ไว้สำหรับค้นหาที่อยู่และข้อมูลจำเป็นอื่นๆ ของ package ที่ผู้ใช้กำหนด คำสั่ง FIND_PACKAGE มีรูปแบบการใช้ดังต่อไปนี้

FIND_PACKAGE(<ชื่อ package>)

และถ้าหากการคอมไพล์โปรเจคต้องใช้ package ที่เราต้องการหา เราอาจสั่ง

FIND_PACKAGE(<ชื่อ package>) REQUIRED)

เพื่อบอกให้ CMake พิมพ์ข้อความแสดงความผิดพลาดหากหา package ไม่เจอ

ในกรณีของโปรเจคในบทความนี้ เราจะใช้ package สองตัวคือ OpenGL และ GLUT (คุณสามารถดู package อื่นๆ ที่ CMake ค้นหาเป็นได้จาก documentation ของ CMake) ฉะนั้นเราจะต้องมีการเพิ่มสคริปต์สองบรรทัดข้างล่างนี้

FIND_PACKAGE(OpenGL REQUIRED)
FIND_PACKAGE(GLUT REQUIRED)

ลงในไฟล์ src/CMakeLists.txt ดังต่อไปนี้

CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
PROJECT(sample)

IF(WIN32)
    SET(__WIN_PLATFORM__ "ON")
ELSE(WIN32)
    SET(__WIN_PLATFORM__ "OFF")
ENDIF(WIN32)

IF(UNIX)
    IF(APPLE)
        SET(__MAC_PLATFORM__ "ON")
        SET(__UNIX_PLATFORM__ "OFF")
    ELSE(APPLE)
        SET(__MAC_PLATFORM__ "OFF")
        SET(__UNIX_PLATFORM__ "ON")
    ENDIF(APPLE)
ELSE(UNIX)
    SET(__MAC_PLATFORM__ "OFF")
    SET(__UNIX_PLATFORM__ "OFF")
ENDIF(UNIX)

FIND_PACKAGE(OpenGL REQUIRED)
FIND_PACKAGE(GLUT REQUIRED)

ADD_SUBDIRECTORY(square)

CONFIGURE_FILE( config.h.in ${CMAKE_SOURCE_DIR}/config.h )

สังเกตเราใส่คำสั่ง FIND_PACKAGE ไว้ก่อนการประกาศ target ต่างๆ ทุก target เนื่องจาก target ที่เราประกาศอาจต้องการใช้ package ที่เราหาในภายหลัง

ให้ target เรียกใช้ package

ก่อนที่เราจะคอมไพล์ target หนึ่งที่เรียกใช้ package หนึ่งได้นั้น เราจะต้องให้ข้อมูลสองประการต่อไปนี้กับคอมไพเลอร์

1. ไดเรคทอรีที่ให้คอมไพเลอร์ไปหาไฟล์ header ของ package

2. ไฟล์ไลบรารีที่คอมไพเลอร์จะต้องลิงก์เข้ากับผลลัพธ์ที่ได้จากการคอมไพล์ไฟล์ของ target

หลังจากใช้ FIND_PACKAGE หาที่อยู่ของ package แล้ว โดยมากข้อมูลไดเรคทอรีที่อยู่ของไฟล์ header นั้นจะอยู่ในตัวแปรชื่อ <ชือ่ package ตัวพิมพ์ใหญ่>_INCLUDE_DIR และข้อมูลไลบรารีที่จะต้องลิงก์จะอยู่ตัวแปรชื่อ <ชื่อ package ตัวพิมพ์ใหญ่>_LIBRARIES ฉะนั้นชื่อตัวแปรที่เก็บข้อมูลเหล่านี้ของ OpenGL และ GLUT ได้แก่ OPENGL_INCLUDE_DIR, OPENGL_LIBRARIES, GLUT_INCLUDE_DIR, และ GLUT_LIBRARIES

เราควรจะบอกข้อมูลข้างต้นเป็นราย target ไป เนื่องจาก target แต่ละตัวอาจใช้ package ไม่เหมือนกัน ดังนั้นคำสั่งที่ใช้กำหนดข้อมูลเหล่านี้จึงควรอยู่ใน CMakeLists.txt ของ target แต่ละตัว ในกรณีของโปรแกรม square ไฟล์ CMakeLists.txt ของมันมีเนื้อหาดังต่อไปนี้

INCLUDE_DIRECTORIES(${OPENGL_INCLUDE_DIR} ${GLUT_INCLUDE_DIR})

ADD_EXECUTABLE(square square.cpp)

TARGET_LINK_LIBRARIES(square ${OPENGL_LIBRARIES} ${GLUT_LIBRARIES})

คำสั่ง INCLUDE_DIRECTORIES

มีรูปแบบ

INCLUDE_DIRECTORIES(<ไดเรคทอรี 1> <ไดเรคทอรี 2> ...)

โดยที่เราสามารถใส่ไดเรคทอรีกี่ไดเรคทอรีก็ได้ในวงเล็บ หลังจากสั่งคำสั่งนี้แล้ว คอมไพเลอร์จะคอมไพล์ target ทุก target โดยใช้ไดเรคทอรีที่กำหนดในการค้นหาไฟล์ header (_หมายเหตุ:_ จริงๆ แล้วไม่ใช่ target ทุก target เสียทีเดียว แต่เป็นทุก target ในไฟล์ CMakeLists.txt เดียวกัน หรือไฟล์ CMakeLists.txt อื่นๆ ที่ปรากฏอยู่ในไดเรคทอรีย่อยที่ถูกเพิ่มผ่าน ADD_SUBDIRECTORY กล่าวคือ คำสั่ง INCLUDE_DIRECTORIES ที่ปรากฏใน src/square/CMakeLists.txt จะไม่มีผลต่อ target ที่ประกาศใน src/cube/CMakeLists.txt หรือ src/cube/star/CMakeLists.txt เลย)

คำสั่ง TARGET_LINK_LIBRARIES

มีรูปแบบ

TARGET_LINK_LIBRARIES(<ชื่อ target> <ไลบรารี 1> <ไลบรารี 2> ...)

โดยที่เราสามารถใส่ไลบรารีลงไปกี่ไลบรารีก็ได้หลังชื่อ target คำสั่ง TARGET_LINK_LIBRARIES นี้เนื่องจากมันต้องใช้ชื่อ target มันจึงถูกเรียกอยู่หลังคำสั่ง ADD_EXECUTABLE หรือ ADD_LIBRARY (ที่เรายังไม่ได้พูดถึง) ซึ่งเป็นตัวสร้าง target เสมอ เมื่อสั่ง TARGET_LINK_LIBRARIES แล้ว target ที่กำหนดจะถูกลิงก์เข้ากับไลบรารีที่เรากำหนดให้

สรุป

หากต้องการใช้ไลบรารี (package) ภายนอกให้

1. สั่ง FIND_PACKAGE(<package>) ใน CMakeLists.txt ของโปรเจค

2. สั่ง INCLUDE_DIRECTORIES(<PACKAGE>_INCLUDE_DIR) ใน CMakeLists.txt ของ target ที่จะต้องใช้ package ก่อนการประกาศ target นั้นด้วย ADD_EXECUTABLE หรือ ADD_LIBRARY

3. สั่ง TARGET_LINK_LIBRARIES(<target> <PACKAGE>_LIBRARIES) ใน CMakeLists.txt ของ target หลังประกาศ target แล้ว

ตัวอย่างหนึ่งคือฟังก์ชันสำหรับคืนชื่อไดเรคทอรีที่โปรแกรมทำงานอยู่ปัจจุบัน (current working directory) ซึ่งในระบบปฏิบัติการที่สืบเชื้อสายมาจาก Unix จะมีชื่อว่า getcwd และต้อง include ไฟล์ unistd.h เพื่อใช้งาน แต่ใน Windows ฟังก์ชันนี้กลับมีชื่อว่า _getcwd และต้อง include ไฟล์ direct.h แทน

ดังนั้น หากเราจะเขียนโปรแกรม print_cwd ที่พิมพ์ current working directory ออกทางหน้าจอ เราจะต้องรู้ว่าโปรแกรมของถูกคอมไพล์อยู่ในแพลตฟอร์มใด ซึ่งในบทความ CMake เบื้องต้น ผู้เขียนได้เสนอให้ใช้มาโคร _WIN32 เป็นตัวเช็คว่าโปรแกรมถูกคอมไพล์ใน Windows หรือไม่ อย่างไรก็ดีผู้เขียนคิดว่าการใช้ _WIN32 ไม่น่าจะเป็นความคิดที่ดี เนื่องจากเราไม่ทราบว่าคอมไพเลอร์ตัวอื่นนอกจาก cl ของไมโครซอฟต์จะนิยาม _WIN32 เอาไว้หรือไม่

สิ่งที่เราต้องการคือมาโครซึ่งจะถูกนิยามตามแพลตฟอร์มที่โปรแกรมถูกคอมไพล์ เนื่องจากผู้เขียนเขียนโปรแกรมอยู่ในสามแพลตฟอร์มใหญ่ๆ คือ Windows, Mac, และ Linux (ซึ่งเป็น Unix แบบหนึ่ง)​ผู้เขียนจึงอยากให้มีมาโครต่อไปนี้

• __WIN_PLATFORM__ ถูกนิยามก็ต่อเมื่อโปรแกรมถูกคอมไพล์ใน Windows
• __MAC_PLATFORM__ ถูกนิยามก็ต่อเมื่อโปรแกรมถูกคอมไพล์ใน Mac OS
• __UNIX_PLATFORM__ ถูกนิยามก็ต่อเมื่อโปรแกรมถูกคอมไพล์ด้วยระบบปฏิบัติการที่สืบเชื้อสายมาจาก Unix อื่นๆ เช่น Linux แต่ไม่ใช่ Mac OS

ตามมาตรฐานการเขียนโค้ดของ GNU แล้ว มาโครที่ใช้สำหรับบอกแพลตฟอร์มเหล่านี้จะถูกบรรจุอยู่ในไฟล์ชื่อ config.h ซึ่งอยู่ในชั้นบนสุดของ source directory ของโปรเจค ไฟล์ config.h นี้จะถูกสร้างขึ้นโดยอัตโนมัติด้วยเครื่องมือชื่อ autoconf ในบทความนี้เราจะเลียนแบบมาตรฐานของ GNU แต่เราจะใช้ CMake สร้าง config.h แทน

หากมี config.h แล้วซอร์สโค้ดของโปรแกรม print_cwd อาจมีเนื้อหาดังต่อไปนี้

/* print_cwd.cpp */

#include "../config.h"

#ifdef __WIN_PLATFORM__
#include <direct.h>
#else
#include <unistd.h>
#endif

#include <stdio.h>
#include <stdlib.h>

int main()
{
    char *buffer;
    
    #ifdef __WIN_PLATFORM__
    buffer = _getcwd(NULL, 0);
    #else
    buffer = getcwd(NULL, 0);
    #endif

    printf("%s\n", buffer);
    free(buffer);

    return 0;
}

หมายเหตุ: ที่เรา include ../config.h แทนที่จะ include config.h เฉยๆ เป็นเพราะว่าจากบทความที่แล้ว เราได้เรียนรู้ว่าควรจัดให้ print_cwd.cpp อยู่ในไดเรคทอรี src/print_cwd เพื่อไม่ให้ไปปนกับไฟล์ของ target อื่นๆ แต่ config.h ควรอยู่ในไดเรคทอรี src เนื่องจากเป็นไฟล์ที่ทุกๆ target จะต้องใช้ร่วมกัน

การสร้างไฟล์ config.h โดยใช้ CMake มีขั้นตอนอยู่สามขั้นตอน

1. เขียนไฟล์ config.h.in เพื่อใช้เป็นต้นแบบของ config.h

2. เขียน CMakeLists.txt เพื่อกำหนดตัวตัวแปรต่างๆ ในการนำไปสร้าง config.h

3. เรียกคำสั่ง CONFIGURE_FILE ใน CMakeLists.txt เพื่อสร้าง config.h

config.h.in

config.h.in ควรอยู่ในไดเรคทอรี src เหมือนกับ config.h ดังนั้นโปรเจคของเราจึงมีโครงสร้างไดเรคทอรีดังต่อไปนี้

sample/
    build/
    src/
        CMakeLists.txt
        config.h.in
        print_cwd/
            CMakeLists.txt
            print_cwd.cpp

ที่ไม่มี config.h เนื่องจากมันยังไม่ถูกสร้างขึ้นจริง

เนื้อหาของไฟล์ config.h.in นั้นเหมือนกับเนื้อหาของ header file ของภาษา C/C++ ธรรมดา แต่มาโครใดที่เราต้องกให้ CMake นิยามตามเงื่อนไขต่างๆ ของแพลตฟอร์ม เราจะใช้คำสั่ง #cmakedefine แทน #define ในกรณีของการนิยามมาโครบอกแพลตฟอร์มสามมาโครข้างต้น เราสามารถเขียน config.h.in ได้ดังต่อไปนี้

/* config.h.in */

#ifndef __CONFIG_H__
#define __CONFIG_H__

#cmakedefine __WIN_PLATFORM__
#cmakedefine __MAC_PLATFORM__
#cmakedefine __UNIX_PLATFORM__

#endif

เวลา CMake สร้างไฟล์ config.h มันจะเอา config.h.in เป็นต้นฉบับและเปลี่ยนแปลงเฉพาะบรรทัดที่มี #cmakedefine เท่านั้น บรรทัดอื่นๆ จะมีเนื้อหาเหมือนเดิม

CMakeLists.txt

ในที่นี้เราจะสนใจเฉพาะไฟล์ CMakeLists.txt ที่อยู่ในไดเรคทอรี src เท่านั้น ไฟล์ CMakeLists.txt ที่อยู่ใน src/print_cwd นั้นมีหน้าที่สร้าง executable ชื่อ print_cwd ซึ่งเนื้อหาของมันจะคล้ายกับไฟล์ CMakeLists.txt ทำนองเดียวกันซึ่งปรากฏอยู่ในบทความที่แล้ว

ไฟล์ CMakeLists.txt ที่เราสนใจอาจมีเนื้อหาดังต่อไปนี้

PROJECT(sample)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)

IF(WIN32)
    SET(__WIN_PLATFORM__ ON)
ELSE(WIN32)
    SET(__WIN_PLATFORM__ OFF)
ENDIF(WIN32)

IF(UNIX)
    IF(APPLE)
        SET(__MAC_PLATFORM__ ON)
        SET(__UNIX_PLATFORM__ OFF)
    ELSE(APPLE)
        SET(__MAC_PLATFORM__ OFF)
        SET(__UNIX_PLATFORM__ ON)
    ENDIF(APPLE)
ELSE(UNIX)
    SET(__MAC_PLATFORM__ OFF)
    SET(__UNIX_PLATFORM__ OFF)
ENDIF(UNIX)

ADD_SUBDIRECTORY(print_cwd)

CONFIGURE_FILE( config.h.in config.h )

สังเกตว่าเนื้อหามีส่วนเพิ่มเติมเข้ามาสองส่วนจากเนื้อหาไฟล์ CMakeListst.txt ที่เราพบในบทความก่อนหน้านี้ ได้แก่

• ส่วนที่เริ่มจาก IF(WIN32) จงถึง ENDIF(UNIX)
• คำสั่ง CONFIGURE_FILE ในบรรทัดสุดท้าย

กำหนดค่าให้ตัวแปร

ส่วนซึ่งเริ่มตั้งแต่ IF(WIN32) ถึง ENDIF(UNIX) ทำหน้าที่นิยามตัวแปร __MAC_PLATFORM__, __WIN_PLATFORM__, และ __UNIX_PLATFORM__ ให้มีค่าเป็น “จริง” หรือ “เท็จ” ที่ถูกต้องตรงตามแพลตฟอร์มที่โปรแกรมถูกคอมไพล์ ส่วนนี้มีหลักษณะคล้ายๆ กับโปรแกรมคอมพิวเตอร์เล็กๆ โปรแกรมหนึ่ง

CMake มีภาษาสคริปต์ที่ทรงพลังพอสมควร ภาษาของ CMake อนุญาตให้เราและกำหนดค่าให้ตัวแปร นอกจานี้ยังมีคำสั่ง if และลูป while ให้ใช้ คุณสามารถดูรายละเอียดของโครงสร้างของภาษาเหล่านี้จาก documentation ของ CMake หรือจากวิกิของ Kernigh

คำสั่ง SET

คำสั่งที่เราใช้มีอยู่สองคำสั่งได้แก่คำสั่ง SET ซึ่งใช้กำหนดค่าให้ตัวแปร ซึ่งคำสั่งนี้มีรูปแบบ

SET(<ชื่อตัวแปร> <ค่าของตัวแปร>)

ตัวแปรใน CMake มีค่าเป็นสตริง (string) เท่านั้น ดังนั้นค่า ON และ OFF ที่เรากำหนดให้จริงแล้วจึงเป็นค่าสายอักษร “ON” และ “OFF”

ค่าความจริง

CMake ถือว่าสตริง “ON”, “YES”, และ “TRUE” มีค่าเป็น “จริง” และถือว่าสตริง “OFF”, “NO”, และ “FALSE” มีค่าเป็นเท็จ ดังั้นเราอาจจะเปลี่ยน ON เป็น TRUE หรือ ​OFF เป็น NO ก็ได้

(จริงๆ แล้วสตริงที่ไม่ใช่สตริงข้างบนที่อาจมีค่าเป็นจริงหรือเท็จได้อีก กรุณาอ่านวิกิของ Kernigh หากต้องการหาข้อมูลเพิ่มเติม)

คำสั่ง IF

คำสั่ง IF ใน CMake มีรูปแบบดังต่อไปนี้

IF(<เงื่อนไข>)
    <กลุ่มคำสั่งที่จะทำเมื่อเงื่อนไขเป็นจริง>
ENDIF(<เงื่อนไข>)

หรือ

IF(<เงื่อนไข>)
    <กลุ่มคำสั่งที่จะทำเมื่อเงื่อนไขเป็นจริง>
ELSE(<เงื่อนไข>)
    <กลุ่มคำสั่งที่จะทำเมื่อเงื่อนไขเป็นเท็จ>
ENDIF(<เงื่อนไข>)

ซึ่งคำสั่งทั้งสองรูปแบบมีความหมายเหมือนกับคำสั่ง if ในภาษาโปรแกรมอื่นๆ

สังเกตว่าเวลาเขียนคำสั่งเหล่านี้ เงื่อนไขที่อยู่ในวงเล็บหลัง IF, ELSE, และ ENDIF จะต้องเป็นเงื่อนไขเดียวกันเสมอ ไม่งั้น CMake จะจับคู่ IF กับ ELSE หรือ ENDIF ไม่ถูก พึงระวังว่า CMake ไม่มีคำสั่ง ELSEIF ให้ใช้ภาษาโปรแกรมทั่วๆ ไป

WIN32, APPLE, และ UNIX

WIN32, APLLE, และ UNIX เป็นตัวแปรสามตัวที่ CMake กำหนดค่าให้อัตโนมัติก่อนการประมวลผล CMakeLists.txt โดยที่

• WIN32 จะมีค่าเป็นจริงก็ต่อเมื่อระบบปฏิบัติการที่ใช้อยู่ในตระกูล Windows
• APPLE จะมีค่าเป็นจริงก็ต่อเมื่อระบบปฏิบัติการที่ใช้อยู่ในตระกูล Mac OS
• UNIX จะมีค่าเป็นจริงก็ต่อเมื่อระบบปฏิบัติการที่ใช้สืบเชื้อสายมาจาก Unix

หมายเหตุ: ผู้เขียนสร้างตัวแปรใหม่สามตัวแทนที่จะใช้ WIN32, APPLE, และ UNIX ไปเลยเนื่องจาก (1) ความหมายของ __UNIX_PLATFORM__ ไม่ตรงกับความหมายของ UNIX (UNIX จะเป็นจริงในระบบปฏิบัติการตระกูล MAC OS ด้วย) และ (2) ผู้เขียนเห็นว่าชื่อมาโครที่ไม่มี underscore นำหน้าควรจะถูกเปิดไว้ให้ผู้เขียนโปรแกรมนำไปใช้

คำสั่ง CONFIGURE_FILE

คำสั่ง CONFIGURE_FILE มีรูปแบบดังต่อไปนี้

CONFIGURE_FILE(<ชื่อไฟล์ต้นฉบับ> <ชื่อไฟล์ที่ต้องการสร้าง>)

สังเกตว่าเราเขียนคำสั่ง CONFIG_FILE ไว้เป็นคำสั่งสุดท้ายหลังจากการตั้งแต่ตัวแปรและการกำหนด target ต่างๆ (เรากำหนด target ผ่านการสั่ง ADD_DIRECTORY) เนื่องจากคำสั่ง CONFIGURE_FILE จะนำค่าของตัวแปรต่างๆ ณ ตำแหน่งที่ CONFIGURE_FILE ถูกเรียกมาใช้ในการสร้าง config.h ดังนั้นเราจึงเอาคำสั่งนี้ไว้เป็นคำสั่งสุดท้าย เพื่อให้แน่ใจได้ว่าตัวแปรทุกตัวถูกกำหนดไว้เรียบร้อยแล้ว

แต่สังเกตว่าเราไม่ได้ใส่ชื่อ config.h ไว้เฉยๆ แต่เราเติม ${CMAKE_SOURCE_DIR}/ ไปข้างหน้ามัน ที่เป็นเช่นนี้ก็เพราะว่าไฟล์ที่ CMake สร้างจะอยู่ใน binary directory เสมอ เว้นแต่จะกำหนดเป็นอย่างอื่น แต่เราต้องการให้ config.h อยู่ในไดเรคทอรี src ดังนั้นเราจึงใช้ตัวแปร CMAKE_SOURCE_DIR ซึ่งเป็นไดเรคทอรีที่มีไฟล์ CMakeLists.txt ของโปรเจคอยู่ (ในที่นี้แค่ src) สังเกตอีกอย่างว่าเวลาเราใช้ตัวแปรของ CMake เราจะล้อมชื่อตัวแปรด้วย ${ และ } เหมือนกับการใช้ตัวแปรใน unix shell ต่างๆ

หากเราอยู่ในระบบปฏิบัติการ Mac OS เราจะได้ src/config.h ที่มีเนื้อหาดังต่อไปนี้

#ifndef __CONFIG_H__
#define __CONFIG_H__

/* #undef __WIN_PLATFORM__ */
#define __MAC_PLATFORM__
/* #undef __UNIX_PLATFORM__ */

#endif

ในทางกลับกันหากเราอยู่ใน Windows แล้ว src/config.h จะมีเนื้อหาดังต่อไปนี้

#ifndef __CONFIG_H__
#define __CONFIG_H__

#define __WIN_PLATFORM__
/* #undef __MAC_PLATFORM__ */
/* #undef __UNIX_PLATFORM__ */

#endif

ซึ่งนิยามมาโครตรงตามความต้องการของเราเป๊ะ

วิธีการเขียน CMakeLists.txt ให้บรรลุวัตถุประสงค์ข้างบนมีหลายวิธี เราจะนำเสนอวิธีการต่างๆ จากง่ายไปยาก โดยวิธีการที่ง่ายๆ นี้หมายความถึงวิธีการที่เขียนไฟล์ง่ายๆ สั้นๆ ไม่ต้องเสียแรงมาก แต่ไม่เหมาะสมกับโปรเจคที่มีขนาดไหน ส่วนวิธีการที่ยากนั้นเขียนไฟล์ยาวกว่าและอาจจะต้องมีการสร้างไฟล์ CMakeLists.txt เพิ่มเติม เพื่อให้จัดการโปรเจคที่ซับซ้อนได้ดียิ่งขึ้น

Hello World ปะทะ Good Morning

สมมติว่าเราจะสร้างโปรเจค sample1 ซึ่งมี target สอง target ดังต่อไปนี้

• helloworld เป็นโปรแกรมพิมพ์ข้อความ “hello, world” ออกทางหน้าจอ
• goodmorning เป็นโปรแกรมพิมพ์ข้อความ “good morning” ออกทางหน้าจอ

ซึ่งมีซอร์สโค้ดเป็นดังต่อไปนี้

/* helloworld.cpp */
#include <stdio.h>

int main()
{
    printf("hello, world\n");
    return 0;
}

/* goodmorning.cpp %/
#include <stdio.h>

int main()
{
    printf("good morning\n");
    return 0;
}

เนื่องจากไฟล์มีอยู่แค่สองไฟล์ เราอาจจะให้ไฟล์ทั้งสองอยู่ในไดเรคทอรีเดียวกันไปเลยดังโครงสร้างไดเรคทอรีข้างล่างนี้

sample1/
    src/
        CMakeLists.txt
        helloworld.cpp
        goodmorning.cpp

และในไฟล์ CMakeLists.txt เราสามารถสั่งให้ CMake สร้าง executable สอง executable ได้ด้วยการสั่ง ADD_EXECUTABLE สองครั้ง

PROJECT(sample2)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)

ADD_EXECUTABLE(helloworld helloworld.cpp)
ADD_EXECUTABLE(goodmorning goodmorning.cpp)

หนึ่ง target หนึ่งไดเรคทอรี

ในการเขียนซอฟต์แวร์ขนาดใหย่ เราอาจพบว่า target สอง target อาจมีการใช้ไฟล์ชื่อเดียวกัน ฉะนั้นเราจึงไม่สามารถใส่ไฟล์ของทุก target ไว้ในไดเรคทอรีเดียวกันได้ ฉะนั้นเพื่อให้ไฟล์จัดการง่าย เราควรจะแยกไฟล์ของ target แต่ละ target ไว้ในไดเรคทอรีของมันเอง

เราอาจจะจำลองสถานการณ์นั้นโดยแยก helloworld.cpp และ goodmorning.cpp เป็นสองส่วน คือ text.h และ main.cpp ดังนี้ (ขออภัยที่การจำลองสถานการ์นี้อาจจะไม่เหมือนจริงไปสักหน่อย)

/* text.h ของ helloworld */
#include <stdio.h>

const char *helloworld_text = "hello, world\n";

/* main.cpp ของ helloworld */
#include "text.h"

int main()
{
    printf("%s", helloworld_text);
    return 0;
}

/* text.h ของ goodmorning */
#include <stdio.h>

const char *goodmorning_text = "good morning\n";

/* main.cpp ของ goodmorning */
#include "text.h"

int main()
{
    printf("%s", goodmorning_text);
    return 0;
}

เราสามารถจัดไฟล์ตามโครงสร้างไดเรคทอรีต่อไปนี้ได้

sample2/
    src/
        CMakeLists.txt
        helloworld/
            text.h
            main.cpp
        goodmorning/
            text.h
            main.cpp

และเขียนไฟล์ CMakeLists.txt ใหม่ว่า

PROJECT(sample2)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)

ADD_EXECUTABLE(helloworld helloworld/text.h helloworld/main.cpp)
ADD_EXECUTABLE(goodmorning goodmorning/text.h goodmorning.cpp)

หนึ่งไดเรคทอรี หนึ่ง CMakeLists.txt

สังเกตว่าในตัวอย่างที่แล้ว เวลาเราจะใส่ไฟล์เข้าใน executable หนึ่งๆ เราจะต้องใส่ไดเรคทอรีของไฟล์นั้นเข้าไปด้วย เนื่องจากชื่อไฟล์ที่กำหนดใน CMakeLists.txt ใดๆ จะเป็นชื่อไฟล์สัมพัทธ์กับไดเรคทอรีที่ CMakeLists.txt อยู่เสมอ ซึ่งทำให้เกิดความไม่สะดวกอย่างมาก

นอกจากนี้ หาก target ของเราเป็น target ที่มีไฟล์อยู่หลายไฟล์ CMakeLists.txt จะต้องมีชื่อไฟล์เหล่านี้ทั้งหมด ทำให้ CMakeLists.txt มีขนาดใหญ่มาก ทำให้แก้ไขและจัดการยาก

CMake อนุญาตให้เราเขียน CMakeLists.txt ได้หลายๆ ไฟล์​(แต่ในไดเรคทอรีหนึ่งๆ จะมี CMakeLists.txt ได้เพียงไฟล์เดียวเท่านั้น เนื่องจากชื่อไฟล์ซ้ำกันไม่ได้) แล้วให้ไฟล์ CMakeLists.txt ของไดเรคทอรีแม่ไปเอาเนื้อหาของ CMakeLists.txt ในไดเรคทอรีลูกมาประมวลผลได้ ความสามารถนี้ช่วยให้เราสามารถเขียน CMakeLists.txt ของแต่ละ target แยกกันได้หากเราแยกไฟล์ของ target แต่ละตัวอยู่ในไดเรคทอรีของมันแล้ว

เราจะนำตัวอย่างที่แล้วมาดัดแปลงให้ใช้ความสามารถใหม่นี้ อันดับแรกเราจะสร้างไฟล์ CMakeLists.txt ไว้ในไดเรคทอรี helloworld และ goodmorning อย่างละไฟล์ ตามโครงสร้างไดเรคทอรีข้างล่าง

sample3/
    src/
        CMakeLists.txt
        helloworld/
            CMakeLists.txt
            text.h
            main.cpp
        goodmorning/
            CMakeLists.txt
            text.h
            main.cpp

ในไฟล์ CMakeLists.txt ของไดเรคทอรี src เราเปลี่ยนคำสั่ง ADD_EXECUTABLE เป็นคำสั่ง ADD_SUBDIRECTORY เพื่อบอกให้ CMake ไปอ่านและประมวลไฟล์ CMakeLists.txt ในไดเรคทอรีย่อยที่กำหนดให้

### sample3/src/CMakeLists.txt

PROJECT(sample3)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)

ADD_SUBDIRECTORY(helloworld)
ADD_SUBDIRECTORY(goodmorning)

ส่วนในไฟล์ CMakeLists.txt ของ helloworld และ goodmorning เราก็ใช้คำสั่ง ADD_EXECUTABLE เหมือนเดิม แต่เราไม่ต้องใส่ชื่อไดเรคทอรีนำหน้าไฟล์ต่างๆ แล้ว เนื่องจาก CMakeLists.txt อยู่ในไดเรคทอรีเดียวกับไฟล์พวกนั้นแล้ว

### sample3/src/helloworld/CMakeLists.txt

ADD_EXECUTABLE(helloworld text.h main.cpp)

### sample3/src/goodmorning/CMakeLists.txt

ADD_EXECUTABLE(goodmorning text.h main.cpp)

การใช้ CMake ช่วยให้เรากำหนดซอฟต์แวร์ที่เราต้องการสร้างเพียงครั้งเดียว หลังจากนั้นเราสามารถพัฒนามันโดยใช้เครื่องมือที่เราชอบบนแพลตฟอร์มใดๆ ก็ได้ CMake จึงอำนวยช่วยความสะดวกให้กับโปรแกรมเมอร์ภาษา C++ ที่ต้องการสร้างซอฟต์แวร์ที่รันบนหลายๆ แพลตฟอร์มอย่างมาก ในบทความนี้เราจะกล่าวถึงวิธีการใช้งาน CMake จัดการซอฟต์แวร์โปรเจคง่ายๆ เป็นการปูพื้นฐานก่อนจะกล่าวถึงการใช้งานที่สลับซับซ้อนขึ้นต่อไป

ปัญหาของการเขียนโปรแกรมสำหรับหลายแพลตฟอร์ม

การเขียนโปรแกรมภาษา C++ ให้คอมไพล์และรันบนหลายๆ แพลตฟอร์ม (เขียนครั้งเดียวแต่รันได้ทั้งบน Windows, Unix, Mac, ฯลฯ) นั่นเป็นเรื่องที่ทำให้โปรแกรมเมอร์ปวดเศียรเวียนเกล้าอย่างหนักมาหลายคนแล้ว เหตุก็เพราะว่า แพลตฟอร์มต่างๆ กันนั้นมี “สภาพแวดล้อม” สำหรับพัฒนาโปรแกรมภาษา C++ ที่ไม่เหมือนกันเอาเสียเลย เราอาจสามารถสรุปปัญหาที่โปรแกรมเมอร์เจอไว้เป็นข้อๆ ได้ดังต่อไปนี้

1. ไลบรารีภาษา C/C++ บนแพลตฟอร์มต่างๆ ไม่เหมือนกัน เช่น ใน Linux และ Mac จะมีไฟล์ unistd.h แต่ใน Windows ไม่มี หรือใน Mac มีระบบไลบรารีที่เรียกว่า bundle และ framework ซึ่งไม่ปรากฏอยู่ในแพลตฟอร์มอื่นๆ

2. คอมไพเลอร์ที่ใช้เป็นคนละตัวกัน กล่าวคือ โปรแกรมเมอร์ C++ ใน Windows จะใช้ cl ของ Microsoft ส่วนโปรแกรมเมอร์บน Linux และ Mac จะใช้ gcc หรือ g++ ของ GNU Project นี่หมายความว่าภาษา C++ ใน Windows จะไม่เหมือนกับภาษา C++ ใน Unix และ Mac เป๊ะ และมีข้อแตกต่างยิบย่อยที่ทำให้ซอร์สโค้ดที่เขียนสำหรับแพลตฟอร์มหนึ่งไม่สามารถคอมไพล์บนอีกแพลตฟอร์มหนึ่งได้

3. เครื่องมือที่ใช้ในการ build โปรแกรมไม่เหมือนกัน โปรแกรมเมอร์บน Windows จะใช้ Visual Studio พวกที่ใช้ Linux ก็จะเขียน Makefile แล้วรัน make ส่วนขา Mac ก็จะใช้ Xcode

Preprocessor Macro

เราสามารถหลีกเลี่ยงสองปัญหาแรกบางส่วนได้ด้วยการเขียน preprocessor macro เพื่อให้คอมไพเลอร์เลือกใช้โค้ดส่วนที่ถูกต้อง ยกตัวอย่าง เช่น หากเราต้องการชื่อของไดเรคทอรีที่โปรแกรมทำงานอยู่ในปัจจุบัน (current working directory ย่อว่า cwd) แล้ว

• ใน Linux และ Mac เราจะต้องใช้คำสั่ง getcwd ซึ่งอยู่ใน unistd.h
• แต่ใน Windows เราจะต้องใช้คำสั่ง _getcwd ซึ่งอยู่ใน direct.h

เนื่องจาก cl จะนิยามมาโคร _WIN32 ก่อนคอมไพล์ไฟล์ทุกไฟล์ ดังนั้นเราสามารถเช็คได้ว่า ตอนนี้โปรแกรมถูกคอมไพล์บน Windows หรือแพลตฟอร์มอื่นได้โดยการเช็คว่า _WIN32 ถูกนิยามหรือไม่ ฉะนั้นเราสามารถเลือก include ไฟล์ที่ถูกต้องได้ดังนี้

 #ifdef _WIN32
 #include <direct.h>
 #else
 #include <unistd.h>
 #endif

ส่วนเวลาเรียกใช้คำสั่ง เราสามารถเขียนโค้ดต่อไปนี้ได้

 char *buffer;
 #ifdef _WIN32
 buffer = _getcwd(NULL, 0);
 #else
 buffer = getcwd(NULL, 0);
 #endif

เครื่องมือและสภาพแวดล้อมที่แตกต่าง

อย่างไรก็ดีการเขียน preprocessor macro ก็ยังไม่สามารถแก้ปัญหาได้ทั้งหมด เนื่องจากคอมไพเลอร์ของแต่ละแพลตฟอร์มมีวิธีการเรียกใช้และการกำหนดออปชันที่แตกต่างกัน นอกจากนี้ การคอมไพล์โปรแกรมภาษา C++ เป็นกระบวนการที่ซับซ้อน ดังนั้นแพลตฟอร์มต่างๆ จึงมีเครื่องมือสำหรับกำหนดกระบวนการนี้เป็นของตัวเอง

ถึงแม้ว่าในปัจจุบัน make จะเป็นเครื่องมือมาตรฐานสำหรับการสร้างซอฟต์แวร์ภาษา C++ ในแพลตฟอร์มที่สืบเชื้อสายมาจาก Unix ทั้งหลาย นอกจากนี้ใน Windows มี nmake ให้ใช้ด้วย อย่างไรก็ดีการใช้ make ทำให้โปรแกรมเมอร์ต้องสละความสะดวกสบายของ IDE ที่ตนถนัด (เนื่องจากผู้เขียนใช้งาน Visual C++ จนติด การต้องไปเขียน Makefile เองจึงเป็นเรื่องที่ทรมานยิ่ง)

แต่ปัญหาที่ใหญ่ที่สุดเกิดขึ้นเมื่อซอฟต์แวร์ที่เราสร้างใช้ไลบรารีภายนอกที่เราไม่ได้เขียนเอง เนื่องจากแพลตฟอร์มต่างๆ มีที่เก็บไลบรารีที่แตกต่างกัน เช่น ใน Mac จะเก็บอยู่ในไดเรคทอรี /Library ส่วนใน Unix อาจเก็บอยู่ที่ /usr หรือ /usr/local ส่วนใน Windows นั้นไม่มีที่เก็บที่แน่นอน เป็นเรื่องของโปรแกรมเมอร์ที่จะต้องรู้ที่เก็บไลบรารีเอง

ในแพลตฟอร์ม Unix มีชุดของเครื่องมือที่เรียกว่า Autotools ซึ่งสามารถตรวจว่าระบบที่จะทำการคอมไพล์ไฟล์มีไลบรารีที่ต้องการให้ใช้หรือไม่ รวมทั้งสร้างไฟล์ชื่อ config.h ซึ่งมี preprocessor macro ซึ่งช่วยให้เรา include ไฟล์และเลือกใช้คำสั่งที่ถูกต้องได้ดังที่กล่าวไว้ข้างบน แต่การใช้ Autotools บังคับให้เราต้องใช้ make ไปโดยปริยาย

ดังนั้นจึงการดีอย่างยิ่งหากเรามีเครื่องมือที่ช่วยให้เรากำหนดซอฟต์แวร์ที่เราต้องการสร้างเพียงครั้งเดียว (ขั้นนี้เรียกว่าการทำ software project configuration และเพื่อความง่ายเราจะแทน “ซอฟต์แวร์ที่จะสร้าง” ด้วยคำว่า “โปรเจค” แทน) แล้วอนุญาตให้เราสามารถคอมไพล์ซอฟต์แวร์นี้ด้วยเครื่องมืออะไรก็ได้ที่เราถนัดบนแพลตฟอร์มที่เราถนัด แต่ในขณะเดียวกันเราก็ยังสามารถพัฒนาซอฟต์แวร์เดียวกันนี้บนแพลตฟอร์มอื่นได้ด้วย

CMake

CMake เป็นเครื่องมือที่ช่วยตอบสนองความต้องการข้างต้นได้ จากมุมมองของผู้ใช้ CMake แล้วกระบวนการคอมไพล์โปรแกรมสามารถแยกออกเป็นสามขั้นตอนดังต่อไปนี้

1. เขียนไฟล์ชื่อ CMakeLists.txt เพื่อกำหนดโปรเจค

2. รัน CMake เพื่อสร้าง build script ที่เฉพาะเจาะจงกับแพลตฟอร์มและเครื่องมือที่เราใชัพัฒนาโปรแกรม

3. build โปรแกรมด้วยเครื่องมือดังกล่าว

สังเกตว่าหน้าที่ของ CMake คือการอ่านพิมพ์เขียวของโปรเจคจากไฟล์ CMakeLists.txt แล้วสร้าง build script แต่มันไม่ได้ทำการ build โปรแกรมด้วยตัวเองเหมือนกับเครื่องมือลักษณะคล้ายๆ กันตัวอื่น นี่เป็นสาเหตุที่ทำให้เราสามารถใช้เครื่องมืออะไรก็ได้ที่ CMake สนับสนุนในการพัฒนาโปรแกรมตามความถนัดของเรา

การติดตั้ง CMake

คุณสามารถดาวน์โหลด CMake จากหน้าดาวน์โหลดของเวบไซต์อย่างเป็นทางการ โดยเลือก installer ที่เหมาะสมกับแพลตฟอร์มที่คุณใช้

ผู้ใช้ Debian หรือ Ubuntu สามารถติดตั้ง CMake ผ่าน apt-get ได้ด้วยการสั่ง

> sudo apt-get cmake

ส่วนผู้ใช้ Mac ที่ใช้ MacPorts สามารถติดตั้งได้โดยการสั่ง

> sudo port install cmake

หลังจากติดตั้งแล้วเราสามารถทดสอบว่า CMake ถูกติดตั้งเรียบร้อยดีหรือไม่ด้วยการสั่ง

> cmake

ใน command prompt ซึ่งหลังจากสั่งแล้วคุณควรจะพบว่า CMake พิมพ์วิธีการใช้มันอย่างคร่าวๆ รวมทั้งออปชันต่างๆ ที่คุณสามารถกำหนดได้ออกมาทางหน้าจอ โดยตอนท้ายของข้อความที่ CMake พิมพ์ออกมาจะมีส่วนที่กล่าวถึง “Generators” ซึ่งบอกว่าขณะนี้ CMake สามารถสร้าง build script ที่ใช้กับเครื่องมือใดได้บ้าง

เมื่อผู้เขียนรันคำสั่ง cmake บนภายใต้ระบบปฏิบัติการ Mac OSX แล้วได้ผลลัพธ์ดังต่อไปนี้

cmake version 2.6-patch 4
Usage

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

Options
  <<< ข้อความแสดงออปชันต่างๆ ที่ผู้ใช้สามารถกำหนดได้ >>>

Generators

The following generators are available on this platform:
  Unix Makefiles              = Generates standard UNIX makefiles.
  Xcode                       = Generate XCode project files.
  CodeBlocks - Unix Makefiles = Generates CodeBlocks project files.
  Eclipse CDT4 - Unix Makefiles
                              = Generates Eclipse CDT 4.0 project files.
  KDevelop3                   = Generates KDevelop 3 project files.
  KDevelop3 - Unix Makefiles  = Generates KDevelop 3 project files.

แต่ถ้ารันมันภายใต้ Windows XP แล้วจะได้ผลลัพธ์ดังต่อไปนี้

cmake version 2.8.1
Usage

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

Options
  <<< ข้อความแสดงออปชันต่างๆ ที่ผู้ใช้สามารถกำหนดได้ >>>

Generators

The following generators are available on this platform:
  Borland Makefiles           = Generates Borland makefiles.
  MSYS Makefiles              = Generates MSYS makefiles.
  MinGW Makefiles             = Generates a make file for use with
                                mingw32-make.
  NMake Makefiles             = Generates NMake makefiles.
  NMake Makefiles JOM         = Generates JOM makefiles.
  Unix Makefiles              = Generates standard UNIX makefiles.
  Visual Studio 10            = Generates Visual Studio 10 project files.
  Visual Studio 10 Win64      = Generates Visual Studio 10 Win64 project
                                files.
  Visual Studio 6             = Generates Visual Studio 6 project files.
  Visual Studio 7             = Generates Visual Studio .NET 2002 project
                                files.
  Visual Studio 7 .NET 2003   = Generates Visual Studio .NET 2003 project
                                files.
  Visual Studio 8 2005        = Generates Visual Studio .NET 2005 project
                                files.
  Visual Studio 8 2005 Win64  = Generates Visual Studio .NET 2005 Win64
                                project files.
  Visual Studio 9 2008        = Generates Visual Studio 9 2008 project files.
  Visual Studio 9 2008 Win64  = Generates Visual Studio 9 2008 Win64 project
                                files.
  Watcom WMake                = Generates Watcom WMake makefiles.
  CodeBlocks - MinGW Makefiles= Generates CodeBlocks project files.
  CodeBlocks - NMake Makefiles= Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles = Generates CodeBlocks project files.
  Eclipse CDT4 - MinGW Makefiles
                              = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - NMake Makefiles
                              = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles
                              = Generates Eclipse CDT 4.0 project files.

ผลลัพธ์ทั้งสองแสดงให้เห็นว่าเราสามารถสร้าง build script สำหรับเครื่องมือที่แตกต่างกันได้หลายชนิด และ CMake ยังรู้ด้วยว่าในแพลตฟอร์มต่างๆ กันมีเครื่องมือที่แตกต่างกัน

Hello World ด้วย CMake

ในส่วนนี้เราจะทำการสร้างโปรแกรมที่ง่ายที่สุดด้วย CMake ก่อนอื่นให้คุณสร้างไดเรคทอรีชื่อ helloworld ซึ่งมีโครงสร้างดังต่อไปนี้

helloworld/
    CMakeLists.txt
    main.cpp

โดยที่ main.cpp มีเนื้อหาตามธรรมเนียมดังนี้

 #include <stdio.h>

 int main()
 {
   printf("hello, world\n");
   return 0;
 }

ไฟล์ CMakeLists.txt เป็นพิมพ์เขียวของโปรเจค ซึ่งในกรณีนี้มันมีเนื้อหาดังต่อไปนี้

PROJECT(sample)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)

ADD_EXECUTABLE(helloworld main.cpp)

บรรทัดแรกของไฟล์บอกว่าโปรเจคของเรามีชื่อว่า sample ส่วนบรรทัดที่สองเป็นการเช็คว่า CMake ที่เราใช้นั้นใหม่กว่าเวอร์ชัน 2.6 บรรทัดที่สามเป็นบรรทัดบอกว่าเราจะทำการสร้างไฟล์ executable เพียงไฟล์เดียวชื่อ helloworld ด้วยการคอมไพล์ main.cpp

ตอนนี้เราพร้อมที่จะสร้าง build script ด้วย CMake แล้ว อันดับแรกให้ทำการเปลี่ยนไดเรคทอรีไปยังไดเรคทอรี helloworld ที่เราเพิ่งจะสร้างขึ้น

> cd helloworld

แล้วจึงสั่ง

> cmake .

เพื่อบอกให้ CMake สร้าง build script โดยอ่าน CMakeLists.txt จากไดเรคทอรีปัจจุบัน การสั่งแบบนี้สอดคล้องกับการใช้ CMake โดยสั่ง

cmake [options] <path-to-source>

ที่เราเคยเห็นแล้วจากการสั่ง cmake เปล่าๆ ข้างบน

ผลลัพธ์

เนื่องจากเราไม่ได้กำหนดว่าจะให้ CMake ใช้ generator ตัวใด CMake จึงเลือกใช้ generator ตัวที่ถูกเลือกเป็นตัวเลือกอัตโนมัติสำหรับแพลตฟอร์มที่เรารันมัน

เวลาที่ผู้เขียนใช้ Mac ผู้เขียนพบว่า CMake จะสร้าง “Unix Makefiles” ดังนั้นหากเราดูไฟล์ในไดเรคทอรี helloworld หล้งรัน CMake จะมีไฟล์ดังต่อไปนี้

> ls
CMakeCache.txt     Makefile                main.cpp
CMakeFiles         cmake_install.cmake
CMakeLists.txt

โดยไฟล์ที่เป็นผลลัพธ์ที่สำคัญที่สุดคือ Makefile ซึ่งทำให้เราสามารถสั่ง

> make

แล้วจะได้ไฟล์ executable ชื่อ helloworld ตามที่เราต้องการ

ในทางกลับกัน ถ้าผู้เขียนใช้ Windows แล้ว CMake จะใช้ generator ชื่อ “Visual Studio 9 2008” เพื่อสร้างไฟล์โปรเจคสำหรับ Visual C++ 2008 เมื่อผู้เขียนสำรวจดูไดเรคทอรี helloworld ก็พบว่ามีไฟล์ดังต่อไปนี้

C:\***\helloworld>dir
 Volume in drive C is ********
 Volume Serial Number is ****-****

 Directory of C:\***\helloworld

05/08/2010  08:00 PM    <DIR>          .
05/08/2010  08:00 PM    <DIR>          ..
05/08/2010  08:00 PM            23,520 ALL_BUILD.vcproj
05/08/2010  08:00 PM            12,587 CMakeCache.txt
05/08/2010  08:00 PM    <DIR>          CMakeFiles
05/08/2010  07:57 PM                91 CMakeLists.txt
05/08/2010  08:00 PM             1,473 cmake_install.cmake
05/08/2010  08:00 PM            26,038 helloworld.vcproj
05/08/2010  07:56 PM                92 main.cpp
05/08/2010  08:00 PM             3,151 sample.sln
05/08/2010  08:00 PM            20,415 ZERO_CHECK.vcproj
               8 File(s)         87,367 bytes
               3 Dir(s)   5,633,990,656 bytes free

ซึ่งผู้เขียนสามารถใช้ Microsoft Visual Studio 2009 เปิดไฟล์ sample.sln เพื่อคอมไพล์ main.cpp ให้กลายเป็น helloworld.exe ได้

เลือก Generator เอง

เราสามารถกำหนดให้ CMake ใช้ generator ตัวอื่นๆ ที่ไม่ใช้ตัวที่มันเลือกให้อัตโนมัติได้ ด้วยการใช้ออปชัน -G "ชื่อ generator" ยกตัวอย่างเช่น หากเราต้องการใช้ Xcode ในการพัฒนาซอฟต์แวร์บนเครื่อง Mac แทนที่จะใช้ Unix Makefiles เราสามารถสั่ง

> cmake -G "Xcode" .

แทนการสั่ง cmake . ที่กล่าวไปในส่วนที่แล้ว ในกรณีของโปรเจค sample ข้างบน เราได้จะได้ไดเรคทอรีชื่อ sample.xcodeproj ซึ่งสามารถใช้ Xcode เปิดได้

คุณสามารถชื่อของ generator ที่ใช้ได้ในแต่ละแพลตฟอร์มได้จากส่วน “Generators” ของข้อความที่ CMake พิมพ์ออกมาเมื่อเราสั่ง cmake เฉยๆ ใน command prompt

อย่างไรก็ดี หากคุณใช้สั่ง cmake . สร้าง build script ลงในไดเรคทอรี helloworld เสร็จแล้วพยายามจะเปลี่ยน generator ที่ใช้ด้วยการสั่ง cmake -G "Xcode" . แล้ว CMake จะบ่นว่า

CMake Error: Error: generator : Xcode
Does not match the generator used previously: Unix Makefiles
Either remove the CMakeCache.txt file or choose a different binary directory

ปัญหานี้เกิดขึ้นจากข้อจำกัดของ CMake ที่ว่า ในไดเรคทอรีหนึ่งๆ มันสามารถสร้าง build script ของเครื่องมือได้เพียงเครื่องมือเดียวเท่านั้น หากเราต้องการเปลี่ยนเครื่องมือใหม่ เราจะต้องทำให้ CMake “ลืม” build script ของเครื่องมือเดิมด้วยการลบไฟล์ CMakeCache.txt แล้วจึงสั่ง cmake -G "Xcode" . ใหม่อีกรอบ หรือไม่ก็ไปสร้าง build script ในไดเรคทอรีใหม่เลย

In-Source Build และ Out-of-Source Build

สังเกตว่าในการ build โปรเจค sample ในส่วนที่แล้วนั้น ได้เรคทอรี helloworld บรรจุดทั้งซอร์สโค้ด (มีสองไฟล์คือ main.cpp และ CMakeLists.txt) และไฟล์อื่นๆ ที่ CMake สร้างขึ้นไว้ทั้งคู่ การทำเช่นนี้เรียกว่าการทำ in-source build และมันมีข้อเสียดังต่อไปนี้

1. ไดเรคทอรีที่เก็บซอร์สโค้ดสามารถเก็บ build script ของเครื่องมือได้เครื่องมือเดียวเท่านั้น จึงเกิดความไม่สะดวกอย่างยิ่งเวลาต้องการสร้าง build script สำหรับเครื่องมือหลายๆ เครื่องมือ

2. ไฟล์ของ CMake ปะปนกับไฟล์ซอร์สโค้ด ทำให้การจัดการซอร์สโค้ดทำได้ยากขึ้น โดยเฉพาะเวลาที่เราเก็บซอร์สโค้ดโดยใช้ซอฟต์แวร์ version control ซึ่งเราจะต้องคอยมาบอกระบุว่าไฟล์ไหนเป็นซอร์สโค้ด (ซึ่งต้องถูกเก็บใน version control) และไฟล์ไหนเป็นไฟล์ที่ CMake สร้างขึ้น (ซึ่งไม่ควรถูกเก็บใน version control)

ในทางกลับกัน out-of-source build คือการแยกไดเรคทอรีที่เก็บซอร์สโค้ด (CMake เรียกไดเรคทอรีนี้ว่า source directory) และไดเรคทอรีที่เก็บ build script และข้อมูลอื่นๆ (CMake เรียกไดเรคทอรีนี้ว่า binary directory) ให้เป็นคนละไดเรคทอรีกัน การทำ out-of-source build ช่วยให้เราหลีกเลี่ยงปัญหาข้างต้นทั้งสองข้อได้โดยสิ้นเชิง โดยแลกมากับการจัดระเบียบวิธีการเก็บไฟล์ใหม่ และการพิมพ์ค่ำสั่งเพิ่มอีกเล็กน้อยตอนเรียก CMake เท่านั้น

จัดระเบียบไฟล์ใหม่

เราอาจจัดระเบียบไฟล์เพื่อทำ out-of-source build โดยเอาซอร์สโค้ดทั้งหมดไปใส่ไว้ในไดเรคทอรีชื่อ src ซึ่งทำหน้าที่เป็น source directory และสร้างไดเรคทอรีว่างชื่อ build เพื่อทำหน้าที่เป็น build directory ดังนั้นสำหรับโปรเจค sample เราอาจจัดระเบียบไฟล์ใหม่ดังต่อไปนี้

helloworld/
    build/
    src/
        CMakeLists.txt
        main.cpp

เรียก CMake จาก build directory

หลังจากนั้น เวลาเราจะสร้าง build script ก็ให้เปลี่ยนไดเรคทอรีไปยัง build:

> cd helloworld/build

แล้วจึงสั่ง cmake แล้วให้ source directory เป็น argument:

> cmake ../src

เมื่อสั่งแล้วไฟล์ build script ทุกอย่างจะถูกบรรจุอยุ่ใน build และเมื่อเราเรียก make (สมมติว่าเราเขียนโปรแกรมอยู่บนเครื่อง Mac) แล้วเราจะได้ไฟล์ helloworld อยู่ในไดเรคทอรี build ด้วย

หลังจากที่เราสั่ง cmake โดยให้ source directory เป็น argument ไปเป็นครั้งแรกแล้ว หากเราเข้าไปใน build directory อีกครั้งแล้วสั่ง cmake . อีกครั้ง CMake จะ update ไฟล์ใน build directory ใหม่โดยใช้ generator ตัวเดิม ทำให้เราไม่ต้องพิมพ์ตำแหน่งของ source directory อีกต่อไปเลย ทำให้เกิดความสะดวกขึ้นมาก

สร้าง build script สำหรับเครื่องมือหลายๆ เครื่องมือ

เราสามารถมี build directory ได้หลาย build directory ยกตัวอย่างเช่นหากเราต้องการใช้ Xcode ควบคู่ไปกับ Makefile เราอาจสร้างไดเรคทอรี helloworld/build_xcode และ helloworld/build_make สำหรับเป็น build directory ของเครื่องมือทั้งสอง ตามลำดับ

• The first is described to in the paper Compressive Light Transport Sensing by Peers et al. (Link)
• The second is a recent technical report(?) titled Adaptive compressed image sensing based on wavelet modeling and direct sampling by Deutsch, Averbuch, and Dekel. (Link)

What these two approaches have in common is their use of hierarchical basis, wavelets in particular. Computation in both papers proceeds from one involving coarse wavelet coefficients to one involving finer coefficients, and the result of the coarser level is used to “bootstrap” the computation of the finer level.

Computing Coherent Transfer Functions

Recall the light transport equation:

Each column of corresponds the colors of a pixel under different lighting configuration. Thus, we have independent equations of the form:

Each equation can be solved with a decoding algorithm to yield transfer vector for each pixel. However, solving these equations independently leads to noisy transfer functions.

To solve the above problem, the paper makes use of the Haar scaling functions. (The paper said they used the Haar wavelet basis. This is misleading. What they actually use are the scaling functions.)

Haar Scaling Functions

Let us define the Haar scaling functions. Suppose we have a image. We can view this image as a matrix . A Haar scaling function is a function from the matrix indices set to a real number (i.e., a color), which basically means that it’s actually an image.

The Haar scaling functions are split into levels from Level to Level . At a particular level , there are scaling functions, and each is denoted by where . At level , each scaling function is the sampling of Pixel . That is,

,

making its inner product with the picture equal the value of Pixel :

.

Scaling functions at level are defined recursively from those at level as follows:

.

We can deduce from this definition that

.

That is, it is a picture of a rectangle where the pixel values are . The inner product between and the image is:

,

which is the sum of all pixels in the support of divided by Thus, is a picture of a rectangle whose color is the average of the pixels in the support of . The projection of into the space spanned by scaling functions at level , denoted by

,

can be thought of the original image partitioned into equally-sized grid. Each grid square’s color is the average of the color of the pixels covered by the square.

The image are approximations of from coarse to fine, with being the image itself.

Hierarchical Compressive Sensing

From this point forward, we will index a pixel in a picture with two indices instead of one. For example, the vector is an -vector whose elements are the color of Pixel under the lighting condition.

Note that, if we project the collection of images to the space spanned by the scaling functions at level , we would get a collection of coarse approximation images . Since each image in has at most different colors, so if we were to solve for the transfer functions in:

There will be at most different transfer functions. Let us denote them by for .

Since Level has functions, a function at Level can be thought of as a parent of 4 functions at . In particular, we can say that is the parent of , , , and

Let be the parent of . Because these two functions are correlated, we expect that there difference should be sparse. Thus, we can find the difference by:

minimize subjected to

Note that and are already available because we have taken all the photographs at the highest resolution, so computing them reduces to computing a wavelet transform and doing some additional work. So, if we have computed , then can be recovered easily.

The paper suggests that we compute the transfer functions level-by-level from Level 0 to Level . Going from Level to , we compute the difference of the transfer functions and add them of the the functions at Level . The advantage of this approach is that, since transfer functions of nearby pixels share ancestors, these functions should be correlated as well. Hence, the functions appear to be less noisy.

Adaptive Sampling

Although the second paper mentions compressive sensing, it is not a compressive sensing paper. It is actually about acquiring wavelet coefficients with fewer direct measurements, no non-linear optimization involved.

Let us suppose that there’s a camera that can capture a user-specified coefficient of the wavelet transform of an image at a time. If only coefficients are not zero, we would only take snapshots if we have an oracle that locates them for us. Of course, we don’t have such an oracle, but can we reduce the number of measurements anyway?

The second paper describes a heuristic based on Lipschitz smoothness of the image. A wavelet coefficient represents the function well if the function is smooth in its support. One popular notion of smoothness is the Lipschitz continuity defined below:

Definition: A function is uniformly Lipschitz continuous of order at point if there exists constant such that, for all and , we have

Let be a 2D wavelet basis function. The paper states that, if is uniformly Lipschitz continuous to order at all points in the support of , then

for some constant . Taking the logarithm base 2, we have that

.

Hence, if we plot from (coarsest level) to some , we can estimate (this number is called the Lipschitz exponent) by examining the slope of the graph.

The Lipschitz exponent can be though of as a measure of smoothness: a lower exponent means the function is smoother. The paper suggests that we acquire all wavelet coefficients to some fixed scale. Then, we estimate the Lipschitz exponent of each region and choose to acquire more coefficients in areas where the Lipschitz exponents are higher than a certain threshold.

The Shortest Numpy Tutorial Ever

First, to use numpy, we import it.

>>> import numpy

>>> A = numpy.zeros((3,2,5,4))

>>> A[1,1,3,2] = 5.0
>>> print A[1,1,3,2]
5.0

>>> print A[0,0,0,0]
0.0
>>> print A[1,2,3,2]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: index (2) out of range (0<=index<2) in dimension 1

>>> print A.__getitem__((1,1,3,2))
5.0

>>> A.ndim
4
>>> A.shape
(3, 2, 5, 4)
>>>

Tensor Unfolding

To compute , we have to know the order of modes from the one whose index varies the slowest to the one whose index varies the fastest. If we unfold along mode , then the list of modes in the aforementioned order is: . (Remember, is the number of modes, and indices start at 0 now that we’re in the programming world.) Let write a function to create this list. The function can simply concatenate with to get the result.

def __get_unfolding_mode_order(A, n):
    return [i for i in xrange(n+1, A.ndim)] + [i for i in xrange(n)]

The next problem is to figure which element of does the element in Row and Column correspond to. Suppose that it corresponds to . We have that , and we can write in terms of and with the formula at the end of this blog post. However, now that indices start at 0, we have that

To simplify the notation, let ( stands for “stride”) be equal to the number that gets multiplied to so that we have

Let ( stands for “mode order”) be the list of modes ordered from the slowest varying to the fastest varying, which we got from __get_unfolding_mode_order. Recall that , , …, . Then, we have that

Then, we can write a function to compute the strides, given the mode order, as follow:

def __get_unfolding_stride(A, mode_order):
    stride = [0 for i in xrange(A.ndim)]
    stride[mode_order[A.ndim-2]] = 1
    for i in xrange(A.ndim-3, -1, -1):
        stride[mode_order[i]] = (
            A.shape[mode_order[i+1]] * stride[mode_order[i+1]])
    return stride

And we have that

So, we can write a function to compute the indices as follows:

def __get_tensor_indices(r, c, A, n, mode_order, stride):
    i = [0 for j in xrange(A.ndim)]
    i[n] = r
    i[mode_order[0]] = c / stride[mode_order[0]]
    for k in xrange(1, A.ndim-1):
        i[mode_order[k]] = (
            (c % stride[mode_order[k-1]]) / stride[mode_order[k]])
    return i

We need to create the result matrix. Thus, we need to now its size, which can be computed easily like below:

def get_unfolding_matrix_size(A, n):
    row_count = A.shape[n]    
    col_count = 1    
    for i in xrange(A.ndim):
        if i != n: col_count *= A.shape[i]        
    return (row_count, col_count)

We are now ready to unfold:

def unfold(A, n):
    """
    Unfold tensor A along Mode n
    """
    (row_count, col_count) = get_unfolding_matrix_size(A, n)
    result = numpy.zeros((row_count, col_count))
    
    mode_order = __get_unfolding_mode_order(A, n)
    stride = __get_unfolding_stride(A, mode_order)
        
    for r in xrange(row_count):        
        for c in xrange(col_count):
            i = __get_tensor_indices(r, c, A, n, mode_order, stride)            
            result[r, c] = A.__getitem__(i)

    return result

>>> A = numpy.zeros((2,2,2))
>>> A[0,0,0] = 0
>>> A[0,0,1] = 1
>>> A[0,1,0] = 2
>>> A[0,1,1] = 3
>>> A[1,0,0] = 4
>>> A[1,0,1] = 5
>>> A[1,1,0] = 6
>>> A[1,1,1] = 7
>>> print unfold(A,0)
[[ 0.  1.  2.  3.]
 [ 4.  5.  6.  7.]]
>>> print unfold(A,1)
[[ 0.  4.  1.  5.]
 [ 2.  6.  3.  7.]]
>>> print unfold(A,2)
[[ 0.  2.  4.  6.]
 [ 1.  3.  5.  7.]]

Suppose again that the responses of the pixels to each light source are coherent. That is, we may hope that there is a basis such that the columns of are sparse. Then, we have that

or

That is, as long as ‘s columns are sparse, we can infer it’s columns by working instead with the new measurements , which is basically projected into . One certainly hope that the columns of are even sparser than the columns of . If so, the number of measurements can be reduced greatly. However, I’m not so sure about this myself when it comes to wavelets, which is the basis I’m most likely to use.

Again, one can see that a big bottleneck in the above equation: to compute , we have to measure the color of every pixel of under every lighting condition used for measurement. And we know that measure the color of a pixel accurately takes a large number of rays. Actually, might be sparse in its rows. Can we acquire them with compressive sensing as well?

where

• is a -dimensional vector, where is the number of pixels in the final image, and each component of is the color of a pixel,
• is an -dimensional vector, where is the number of light sources, and each component of is the intensity of a light source, and
• is a transfer matrix of size .

The -th column of , which we shall denode by , allows us to write the color of Pixel as .

Each is a signal the paper wishes to learn from real measurements. A measurement consists of shining a predetermined pattern of light to the scene and take a photograph. So let’s say we make measurements. Now, the light vector becomes a matrix of size , the color vector of size , and the equation changes to:

or, if you prefer to write the signal we want to reconstruct at the end,

.

Notice that the above equation gives rise to indepedent signal reconstruction problems for each column where acts like a measurement ensemble.

Suppose that each is sparse in some basis , having at most non-zero terms. We have that

.

where is projected into .

The theory of compressive sensing states that, if satisfies the restricted isometry property (read more about this property here) and

.

some constant , then we construct each exactly or with minimal error.

Application to Precomputed Radiance Transfer?

Can we apply the above compressive sensing framework to PRT? After all, the core tasks of image relighting and PRT are the same: learning the transfer function of each pixel. The difference is that measurements in PRT are done in computer by tracing rays.

It’s possible. In the scenario that you would like to relight a scene by a high resolution environmental map, say (as done in this paper). The transfer vector for each pixel would also be that high in dimension. To enable real time relighting, we wavelet-transform these transfer functions and keep only about 200 largest coefficients. Here, is about 20. So, we can render about 4000 images and use it to reconstruct the functions.

However, all of the above is not so impressive. First, it might take a very long time to render that 4000 images accurately. Second, we only assume that each pixel has one color, which either mean that the view is fixed or all the material is diffuse. Again, I don’t know how to handle variable views yet, but surveying more literature might help.

n-mode Vectors

Let be an tensor. An -mode vector of is an -vector obtained from by fixing indices but let vary.

Example 1: Let be a tensor with , , , , , , , and .

Fixing , , and letting vary, we get the 3-mode vector .

Fixing , , and letting vary, we get the 1-mode vector .

Fixing , , and letting vary, we get the 2-mode vector .

Matrix Unfolding

Matrix unfolding is a way to represent a tensor as a matrix. The concept is easy to grasp, but tedious to describe mathematically. So let us start with some examples on 3-mode tensors.

Let be an tensor. It has three different matrix unfoldings and , corresponding to its three modes. has rows and columns where the columns are the 1-mode vectors of . The columns are ordered so that the index varies faster than . So, the first column corresponds to the 1-mode vector where . The second column corresponds to and . The -st column corresponds to and . In general, the 1-mode vector with and appears as the -th column.

Analogously, has rows and columns. Here, the 2-mode vector with and appears as the -th column. Notice that varies faster than . In general, when we say that (or any other unfolded matrices) is of size , we mean that (the number to the right) varies faster than (the number of the left).

A similar situation goes for . It has row and columns with index varies more slowly than .

Example 2: Let be the tensor in Example 1. The three matrix unfoldings of are given below:

In general, a matrix unfolding of an tensor along the -mode is an matrix whose columns are the -mode vectors, and the columns are arranged such that the index varies the fastest and the slowest. To be pedantic, we can specify exactly where the element appears in . It appears on Row and on Column

ในกรณีที่เรามีตัวเลขหลายตัวที่สามารถเรียงกันได้เป็นปริซึมในสามมิติ หรือเป็นปริซึมในปริภูมิที่มีมิติมากกว่าสาม เราจะแทนตัวเลขเหล่านั้นด้วยวัตถุทางคณิตศาสตร์ที่เรียกว่าเทนเซอร์

เราพบเห็นเทนเซอร์อยู่มากมายในชีวิตประจำวัน ตัวอย่างที่ดีที่สุดคือ วิดีโอ เนื่องจากวิดีโอถูกแบ่งออกเป็นหลายเฟรม แต่ละเฟรมคือรูปสองมิติหนึ่งรูป ซึ่งรูปสองมิตินี้จริงๆ แล้วเป็นตารางสี่เหลี่ยมจัตุรัสที่มีสีอยู่หนึ่งสี (จริงๆ แล้วสีหนึ่งสีต้องแทนด้วยเลขสามตัว แต่เพื่อความง่ายเราจะคิดว่าวิดีโอเป็นวิดีโอขาวดำ ซึ่งสีแต่ละสีแทนด้วยเลขเพียงตัวเดียวได้) ฉะนั้นเราจึงสามารถมองวิดีโอเป็นเทนเซอร์หรือปริซึมในปริภูมิสามมิติ ที่แกนหนึ่งคือความกว้างของภาพ อีกแกนหนึ่งคือความสูงของภาพ และอีกเกินหนึ่งคือเวลาได้

การมองวิดีโอและข้อมูลอื่นๆ เป็นเทนเซอร์นั้น ช่วยให้เรานำเทคนิตทางพีชคณิตเชิงเส้นมาวิเคราะห์้ข้อมูลพวกนี้ได้ และการวิเคราะห์เหล่านี้สามารถทำให้เราสามารถบีบอัดข้อมูลให้มีขนาดเล็กลงได้มาก แต่ก่อนที่เราจะสามารถพูดถึงเทคนิคเหล่านั้น เราจำเป็นจะต้องสร้างระบบสัญลักษณ์สำหรับเทนเซอร์เสียก่อน นี่เป็นเป้าหมายของบทความนี้

ระบบสัญลักษณ์ที่เราจะสร้างในที่นี้ส่วนใหญ่แล้วลอกมาจากเปเปอร์ A Multilinear Singular Value Decomposition ของ de Lathauwer, de Moor, และ Vandewalle (ดาวน์โหลด) แต่จะมีการปรับปรุงให้อ่านง่ายขึ้นตามรสนิยมของผู้เขียน

ธรรมเนียมปฏิบัติในการเขียนสัญลักษณ์ของเราเป็นตัวต่อไปนี้

• เราจะแทนปริมาณสเกลาร์ด้วยตัวพิมพ์เล็ก เช๋น เป็นต้น
• เราจะแทนปริมาณเวกเตอร์ด้วยตัวพิมพ์เล็กหนา เช่น เป็นต้น
• สเกลาร์ที่เป็นส่วนประกอบ (component) ของเวกเตอร์จะใช้ตัวอักษรเดียวกันกับเวกเตอร์นั้น เช่น เป็นส่วนประกอบส่วนที่สองของเวกเตอร์ เป็นต้น
• เราแทนเมตริกซ์ด้วยตัวอักษรตัวพิืมพ์ใหญ่ เช่น เป็นต้น และเช่นเดียวกับเวกเตอร์ สเกลาร์ที่เป็นสมาชิกของเมตริกซ์จะใช้ตัวอักษรตัวภาษาอังกฤษเดียวกัน เช่น คือสมาชิก ณ แถวที่ 1 คอลัมน์ที่ 2 ของเมตริกซ์ เป็นต้น นอกจากนี้ เวกเตอร์ที่ใช้ตัวอักษรเดียวกับเมตริกซ์จะแทนคอลัมน์ (ไม่ใช่แถว) ของเมตริกซ์นั้น เช่น คือคอลัมน์ที่ 5 ของเมตริกซ์ เป็นต้น

เทนเซอร์

เทนเซอร์ คือ กลุ่มของตัวเลขที่สามารถนำมาเรียงกันเป็นปริซึมในปริภูมิหลายมิติได้ หากปริซึมนั้นมี มิติ เราจะเรียกว่าเทนเซอร์นั้นมี”’โหมด (mode)”’ อยู่ โหมด

เราจะแทนเทนเซอร์ด้วยตัวอักษรภาษาอังกฤษที่ใช้ฟอนต์แบบ calligraphy (\mathcal ใน latex) เช่น เป็นต้น

สมมติให้ เป็นเทนเซอร์ที่มีโหมดอยู่ โหมด แล้วสมาชิกแต่ละตัวของ จะต้องถูกอ้างอิงถึงด้วยตัวเลข ตัว เช่นเีดียวกับธรรมเนียมการเขียนสมาชิกของเวกเตอร์และเมตริกซ์ข้างต้น เราจะใช้ตัวอักษรภาษาอังกฤษตัวเดียวกับชื่อเทนเซอร์ในการระบุถึงสมาชิกของเทนเซอร์ตัวนั้น กล่าวคือ คือสมาชิกของเทนเซอร์ ณ ตำแหน่งที่ ในโหมดที่ 1, ในใหมดที่ 2 … และ ในโหมดที่

หากเราใช้ตัวแปร ในการบ่งตำแหน่งของสมาชิกของเทนเซอร์ เราจะใช้ตัวแปร ในการบ่งถึงจำนวนสมาชิกในโหมดแต่ละโหมด กล่าวคือ จะมีค่าเท่ากับจำนวนสมาชิกในโหมด และเราจะกล่าวว่า เป็นเทนเซอร์ขนาด

โดยปกติแล้วสมาชิกของเทนเซอร์แต่ละตัวจะเป็นจำนวนจริง เราใช้สัญลักษณ์ แทนเซตของเทนเซอร์ขนาด ที่สมาชิกแต่ละตัวของมันเป็นจำนวนจริง

ตัวอย่าง 1: ให้ เป็นเทนเซอร์ขนาด เราจะได้ว่า ประกอบด้วยสมาชิก 8 ตัวคือ และ