그냥 그런 블로그

생성자 선언 연습

생성자 안에는 필드에 값을 대입하는 대입문뿐만 아니라 모든 종류의 명령문을 다 쓸 수 있습니다. [ 예제 5-4 ] 의 생성자 안에 if 문을 써서 num 파라미터의 값이 0 보다 작을 때 stockNum 필드에 무조건 0 을 대입하도록 수정하십시오. 그리고 나서 다음과 같은 방법으로 개체를 생성한 후 그 개체의 필드값을 출력하는 프로그램을 작성하십시오.

메서드 호출 연습( 2 )

[ 예제 5-3 ] 의 main 메서드 마지막에 재고수량을 1 만큼 빼는 subtractStock 메서드 호출문과 필드값을 출력하는 명령문을 추가한 다음에 프로그램을 다시 컴파일해서 실행해 보십시오.

메서드 호출 연습

StringBuffer 클래스에는 문자열의 일부를 다른 문자열로 치환하는 기능의 replace 라는 메서드가 있습니다. [예제 5-1]에서 사용한 deleteCharAt, insert 메서드 대신 이 메서드를 사용하여 똑같은 일을 하는 프로그램을 작성하십시오. replace 메서드의 정확한 사용 방법은 JDK API 규격서를 찾아서 참고하십시오.

이 메소드는 어떤 범위의 문자열을 다른 문자열로 치환하는 것이다. 이 것의 명세는 다음과 같다. 그런데 두 번째 인자가 마지막으로 대체할 문자의 offset 이 아니라 마지막으로 대체할 문자의 offset 다음의 offset 이라는 것에 주의해야 한다. 명세에는 아래와 같이 언급한다.

다음과 같이 작성하면 된다.

1. 다음의 프로그램은 잘못된 프로그램입니다. 어떤 부분이 잘못되었는지 찾고, 잘못된 이유를 설명하십시오.

byte 에다가 int 를 할당하고 있어서 컴파일 에러가 난다. 강제로 형변환할 수 있지만, 상황에 따라서 값이 잘릴 수도 있는 위험이 있기 때문에, 처음부터 total 을 int 로 선언하는 것이 좋다.

2. 다음의 식이 각각 어떤 값을 산출할지 괄호 안에 쓰십시오.

a) 10 % 7 (   )

b) --100 (    )

c) "10*20=" + 10 * 20 (    )

d) 12e2 < 1234 (    )

e) true & false | true (    )

f) 100 == 100.0 (    )

g) true && false || true (    )

h) 3 & 4 (    )

i) 4 == ( 3 + 1 ) ? 0 : 1 (    )

j) 1 << 3 (    )

a) 10 % 7 (  3  )

b) --100 (  99  )

c) "10*20=" + 10 * 20 (  "10*20=200"  )

d) 12e2 < 1234 (  true  )

e) true & false | true (  true  )

f) 100 == 100.0 (  true  )

g) true && false || true (  true  )

h) 3 & 4 (  0  )

i) 4 == ( 3 + 1 ) ? 0 : 1 (  0  )

j) 1 << 3 (  8  )

프로그램으로 검증해 보았다. 그런데 같은 리터럴에 증감 연산자를 적용하거나 같은 리터럴을 비교하는 것은 컴파일 에러가 나서 따로 변수에 넣었다.

다음과 같은 결과를 얻을 수 있었다.

3. 다음 중 잘못된 식을 고르고 어디가 잘못되었는지 설명하십시오.

++num++ : 증감 연산자는 하나만 붙일 수 있다.

true + 3 : boolean 은 정수로 변환될 수 없다.

true > false : boolean 은 대소비교를 할 수 없다.

0xFF00 || 0x00FF : 정수는 boolean 으로 변환될 수 없다.

--100 : 리터럴에는 증감 연산자를 붙일 수 없다.

120e3 << 2 : 실수에는 shift 연산자를 붙일 수 없다.

넓은 범위로의 캐스트 연산은 안전할까?

넓은 범위의 수치 타입을 좁은 범위의 수치 타입으로 캐스트 연산하면 본래 값이 손상될 수도 있다고 했습니다. 그러면 좁은 범위의 수치 타입을 넓은 범위의 수치 타입으로 바꿀 때는 그런 일이 전혀 안 생길까요? 있다면 어떤 타입으로 바꿀 때 그런 일이 생길 수 있는지 생각해 보십시오.

float 값에서 double 값으로 자동으로 변환될 때 값이 바뀔 수 있다.

다음과 같은 결과가 나온다.

조건 연산자와 증가 연산자

다음 프로그램을 실행하면 max, a, b 의 값은 어떻게 출력될까요?

|| 과 | 의 연산자 차이

[ 예제 4-14 ] 의 || 연산자를 | 연산자로 바꾸어서 컴파일한 후 프로그램을 실행해 보십시오.

다음과 같은 컴파일 에러가 발생한다.

1. 다음의 프로그램은 잘못된 프로그램입니다. 어떤 부분이 잘못되었는지 찾고, 잘못된 이유를 설명하십시오.

byte 는 1 바이트 짜리 타입이라 [ -128, 127 ] 의 범위를 표현한다. 그런데 for 문 안에서 cnt 가 127 이 넘어 가게 된다. byte 가 아니라 int 를 사용해야만 한다.

2. 다음의 리터럴들이 각각 어떤 타입인지 괄호 안에 쓰십시오.

a) "도" (    )

b) 100 (    )

c) 0x01ABf (    )

d) 12e2 (    )

e) false (    )

f) '\123' (    )

a) "도" ( string )

b) 100 ( int )

c) 0x01ABf ( float )

d) 12e2 ( int )

e) false ( boolean )

f) '\123' ( char )

3. 다음 중 잘못된 리터럴을 고르고 어디가 잘못되었는지 설명하십시오.

'\r\n' : 2 개의 문자가 들어 있는 문자열이므로 "\r\n" 이라고 해야 한다.

.5e100f : float 범위를 넘어 선다. f 를 빼야 한다.

0xABCDEFABCDEF : 4 바이트가 넘어가므로 int 에 넣을 수 없다. 만약 long 에 넣고자 한다면 0xABCDEFABCDEFL 이라고 해야 한다.

0x12.5e2 : 16 진수이므로 e 를 쓰면 안 된다. 0x12.5p2 라고 해야 한다.

"단가:\10000" : \ 를 문자열 안에 쓰면 escape sequence 가 된다. 그러므로 "단가:\\10000" 이라고 해야 한다.

TRUE : true 라고 해야 한다.

1e-100f : float 범위를 넘어 선다. f 를 빼야 한다.

Unicode 문자 출력하기

char 타입도 정수 타입이기 때문에 char 타입의 변수에 Unicode 코드갑승ㄹ 정수로 직접 대입할 수도 있고, char 타입의 변수를 for 문의 카운트 변수로 사용할 수도 있습니다. 이 성질을 잘 이용하면 다음과 같은 for 문을 만들어서 a 부터 z 까지의 영문 알파벳을 출력할 수 있습니다.

위의 for 문을 고쳐서 12593 ~ 12686 에 해당하는 코드값을 갖는 Unicode 문자들을 출력하는 프로그램을 작성해 보십시오. 어떤 문자들이 출력됩니까? 출력된 문자들이 Unicode 의 해당 문자들과 일치하는지 Unicode 홈페이지를 방문하여 확인해 보십시오.

http://www.unicode.org/charts/ 에 가면 "hangul compatibility jamo" 라는 pdf 를 찾을 수 있다. 그 pdf 에 보면 각 문자 아래에 숫자가 적혀 있는데 16진수 값이다. 즉 'ㄱ' 밑에 3131 은 0x3131 을 의미한다. 그리고 그것은 10 진값으로는 12593 이다. 아래 결과는 제대로 출력된 것이라 볼 수 있다.

부동소수점수 내부 표현의 확인

JDK 라이브러리에 있는 Double.doubleToRawLongBits 라는 메서드는 dobule 타입의 값을 그와 똑같은 비트 패턴을 갖는 long 타입의 값으로 만드는 메서드입니다. 이 메서드의 사용 방법은 다음과 같습니다.

그리고 JDK 라이브러리의 Long.toBinaryString 이라는 메서드는 long 타입의 정수 내부 표현을 문자열로 만들어서 리턴하는 메서드입니다. 이 메서드의 사용법은 다음과 같습니다.

이 두 메서드를 이용하여 12.735 와 -12.735 의 내부 표현을 문자열로 출력하는 프로그램을 작성하십시오. 그리고 그 결과를 [ 그림 3-17 ]의 비트 패턴과 비교해 보십시오.

다음과 같은 결과가 나왔다.

12.375 는 앞에 0 이 빠진 표현을 보여 주고 있기 때문에 사실은 다음과 같은 결과가 나왔다고 봐야 한다.

결과를 보면 -128 의 경우 MSB( most significant bit, 부호 비트 )가 1 인 것을 알 수 있다. 그리고 정수 표현과는 다르게 소수 표현은 보수 표현을 사용하지 않고 있음을 알 수 있다.

2진 소수

3.14 를 위 그림에서와 같은 방법으로 2진 소수로 바꾸어 보십시오. 이 문제는 컴퓨터로 푸는 것이 아니라 종이에 직접 써서 풀어야 합니다.

다음과 같이 종이에 풀었다.

값은 다음과 같다.

그런데 사실 프로그램으로도 이를 재현하는 것이 가능하다. 다음과 같이 코드를 작성해서 답을 검증해 보았다.

결과는 다음과 같이 나왔다. 위의 계산과 동일함을 알 수 있다.

정수 내부 표현의 확인

JDK 라이브러리에 있는 Integer.toBinaryString 이라는 메서드는 int 타입의 내부 표현을 문자열로 만들어서 리턴하는 메서드인데, 다음과 같은 방법으로 사용할 수 있습니다.

이 메서드를 이용해서 -37 의 내부 표현을 출력하는 프로그램을 작성해 보십시오. 그리고 -5 의 내부 표현을 출력하는 프로그램도 작성해 보십시오. 37 과 5 의 2의 보수에 해당하는 비트 패턴이 출력되는 것을 확인할 수 있습니까?

결과는 다음과 같다.

1. 다음의 프로그램에는 잘못된 부분이 있습니다. 어떤 부분이 잘못되었는지 찾고, 잘못된 이유를 설명하십시오.

이 프로그램에서는 max 라는 지역변수를 if 블락 바깥쪽에서 접근하고 있다. max 를 if 블락 바깥으로 빼든가 System.out.println 을 블락 안 쪽에서 호출해야만 한다.

2. 다음의 프로그램을 실행하면 어떤 결과가 출력될까요?

이 프로그램의 switch 문이 "키위"라고 출력하도록 만들려면 어떻게 해야 할까요?

프로그램은 'K' 를 출력한다. "키위"를 출력하게 하려면 'K' 를 비교하는 case 문을 추가해야 한다.

3. 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 순으로 정수를 출력하는 프로그램으로 만들려고 합니다. a, b, c 위치에 알맞은 식을 채워 넣으십시오.

4. JDK 5.0 의 향상된 for 문을 이용하여 arr 배열 항목들의 총합을 계산하여 출력하려고 합니다. a, b 의 위치에 뭐라고 써야 할까요?

5. "Hello, Java" 의 Java 대신에 명령형 파라미터로 입력받은 값을 출력하는 프로그램을 만들려고 합니다. 예를 들어 Tom 이라는 값을 입력하면 "Hello, Tom" 이라고 출력애야 합니다.

1) 다음 프로그램의 a 위치에 뭐라고 써야 할까요?

2) 이 프로그램이 "Hello, World" 라고 출력하게 하려면 명령행에 뭐라고 입력해야 할까요?

익셉션 처리 문제

Section05 의 Excercise 2-5 에서 작성했던 프로그램은 명령행 파라미터로 정수가 아닌 값을 넘겨주면 익셉션을 발생합니다. 그 익셉션을 잡아서 한글로 된 에러 메시지를 출력하는 프로그램을 작성하십시오.

다음과 같이 코드를 작성한다.

이를 컴파일하고 명령줄에서 다음과 같이 실행한다.

그러면 아래와 같은 결과가 나온다.

여기에서 java.lang.NumberFormatException 을 사용한 이유는 Integer.parseInt 메서드가 그 예외를 발생시키기 때문이다. Eclipse 같은 도구에서 parseInt 메서드에 커서를 위치시킨 다음에 Javadoc 라는 탭을 보면 다음과 같이 설명이 되어 있는 것을 볼 수 있다.

Throws:

    NumberFormatException - if the string does not contain a parsable integer.

메서드 호출문의 연습

1장에서 설치한 JDK 안에는 JDK 라이브러리라는 자바 모듈이 포함되어 있는데, 그 안에는 여러 가지 유용한 기능의 클래스와 메서드들이 있습니다. 그 중에 있는 Integer.parseInt 라는 메서드는 문자열을 정수로 바꾸는 메서드입니다. 이 메서드의 사용법은 다음과 같습니다.

이렇게 메서드를 호출하면 이 메서드는 "12" 라는 문자열을 12 라는 정수로 만들어서 리턴합니다. 이 메서드를 이용해서 명령행 파라미터로 받은 정수를 모두 더하여 합을 출력하는 프로그램을 작성하십시오.

다음과 같이 코드를 작성한다.

이를 컴파일하고 명령줄에서 다음과 같이 실행한다.

그러면 아래와 같은 결과가 나온다.

break 문의 연습

다음과 같은 배열이 있습니다.

이 배열에서 -1 이 나오기 전까지의 항목 값들을 순서대로 출력하십시오.

향상된 for 문

다음의 프로그램에 있는 두 개의 for 문을 모두 향상된 for 문으로 고칠 수 있을까요?

고칠 수 없는 for 문이 있다면 왜 그런지 이유를 설명해 보십시오.

두 번째 for 문만 향상된 for 문으로 고칠 수 있다. 왜냐하면 향상된 for 문에서의 변수는 배열 내의 "값"을 의미하고 있기 때문이다. 배열 요소의 값에 10 을 곱하고 싶으면 그것의 인덱스를 얻어 올 수 있어야 하는데, 그것의 인덱스를 받아 올 수 있는 방법이 없다.

결과는 다음과 같다.

만약 아래와 같이 코드를 작성해 버린다면, 컴파일에는 문제가 없지만 결과가 틀리게 나온다. 첫 번째 향상된 for 문에서의 value 는 단지 복사본이며 원본 배열의 내용에 영향을 미치지 못한다.

Ecplise 같은 데서 빌드하면 다음과 같은 warning 을 볼 수 있다.

The value of the local variable value is not used UpdateArrayExample.java /UpdateArrayExample/src line 7 Java Problem

결과는 다음과 같다.

for 문의 연습

다음과 같은 배열이 있습니다.

이 배열의 3 번째 항목부터 7 번째 항목까지의 값을 모두 더해서 출력하는 프로그램을 for 문을 이용해서 작성하십시오.

결과는 다음과 같다.

while 문과 do-while 문의 비교

앞에서 작성한 [예제 2-30]과 [예제2-32]는 똑같은 결과를 출력합니다. 그러면 다음 두 프로그램도 똑같은 결과를 출력할까요?

다른 결과를 출력한다. 첫 번째는 조건을 만족하지 못해서 "Done." 만 출력한다.

그런데 두 번째는 조건을 만족하지는 못하지만 일단 do 블락을 실행하므로 "10" 과 "Done." 이 출력된다.

앞에서 작성했던 [ 예제 2-26 ]은 else if 절을 사용해서 정수의 범위를 알아 내는 프로그램이었습니다. 그와 똑같은 기능을 하는 프로그램을 switch 문을 이용해서 작성할 수 있을까요? 이 경우에 switch 문과 else if 절을 갖는 if 문 중에서 어느 것을 사용하는 게 더 적절한지 생각해 보십시오.

switch 문을 사용하려면 비교가 가능한 정수 형태의 카테고리 값이어야만 한다. 비교하고자 하는 값을 카테고리로 나눌 수만 있다면 어떻게든 switch 문으로 표현할 수 있을 것이다.

코드를 보면 알겠지만, 좀 삽질이다. 범위를 가지고 있는 값에 대해서는 if 문을 사용하는 것이 좋다.

switch 문을 if 문으로

[ 예제 2-27 ] 과 똑같은 기능을 하는 프로그램을 switch 문을 대신 "else if" 절을 갖는 if 문을 이용해서 작성하십시오.

default 는 else 와 같다. 그러므로 다음과 같이 변경할 수 있다.

2차원 배열의 항목 수

위 코드의 2 차원 배열은 3 X 4 의 크기를 가진다. 그러므로 table 자체에다가 length 를 적용하면 3 이 나오고, table[ 0 ] 에다가 length 를 적용하면 4 가 나온다. 아래와 같이 출력된다.

좀 더 진보된 예제를 들어 보겠다. 배열 선언을 [] 로 했다는 것은 배열의 요소 개수가 가변적인 크기를 가질 수 있음을 의미한다. 아래와 같이 코드를 작성한다면 모든 행의 열 개수를 다르게 만들 수 있다.

이 경우 출력은 다음과 같다.

유별난 final 변수

final 변수에는 복합 대입 연산자, 증가 연산자, 감소 연산자를 사용할 수 없습니다. 왜 그럴까요?

복합 대입 연산자, 증가 연산자, 감소 연산자는 어떤 변수의 값을 변경하는 것이다. final 이라는 키워드가 붙게 되면 그 변수는 변경해서는 안 되기 때문에  그러한 연산자를 사용할 수 없다.

변수 선언의 위치

다음의 프로그램은 잘못된 프로그램입니다. 하지만 명령문 하나만 위치를 바꾸면 올바르게 작동할 수 있습니다. 그 명령문을 찾아서 위치를 바꾸십시오.

if 문 안에 abs 지역변수가 선언되어 있는데 이는 if 로 묶인 블락 안에서만 유효하다. 그러므로 11 라인에서 abs 를 접근하려고 할 때 식별자를 찾을 수가 없다. 그래서 해당 지역변수 선언을 if 문 바깥으로 옮겨야 한다.

1. 이 장에서 배운 내용을 생각하면서 다음의 괄호를 채워 봅시다.

a) 명령문만 가지고는 온전한 자바 프로그램이 될 수 없습니다. 자바 프로그램의 되기 위해서는 먼저 ( 클래스^class )를 만들고, 그 안에 ( main 메서드^method )를 만들고, 그 안에 ( 명령문^statement )을 써 넣어야 합니다.

b) java.exe 명령을 실행할 때 클래스 이름을 지정하면 그 클래스의 ( main ) 메서드로부터 자바 프로그램의 실행이 시작됩니다.

2. 자바 프로그램을 실행하려면 반드시 <이것>이 필요합니다. <이것>은 자바 클래스 파일을 다른 종류의 플랫폼에서도 실행할 수 있도록 만들어 줍니다. 자바의 가상 기계어를 하드웨어와 운영체제에 맞는 진짜 기계어로 바꾸어 주는 역할을 하는 <이것>은 무엇일까요?

자바 가상 기계^{Java Virtual Machine}.

3. 메모장으로 HelloJava.java 프로그램을 입력해서 저장하고 컴팡리했는데 다음과 같은 에러가 발생했습니다. 에러 메시지를 보고 다음 그림의 프로그램 어느 부분이 잘 못 되었는지 찾아 보십시오.

HelloJava 클래스에 닫는 괄호가 없음.

ndk-build tool

android 명령을 사용해서 project 를 생성하고 나면, 그것을 컴파일해 줄 필요가 있다. 이 컴파일 작업은 ndk-build 를 통해서 이루어 진다. 그런데 책에서는 ndk-build 에 대해서 자세하게 다루고 있지 않다. 그런데 안타깝게도 안드로이드 개발자 사이트에서도 자세한 내용을 다루고 있지 않다. 하지만 $ANDROID_NDK/docs/NDK-BUILD.html 을 열어 보면 해당 도구에 대한 설명을 볼 수 있다.

이 문서는 "ndk-build 란?" 장을 제외하고는 NDK-BUILD.html 의 내용을 번역한 것이다.

ndk-build 란?

일단 ndk-build 라는 것의 개념부터 살펴 보도록 하자. ndk-build 에 대해서 --version 이라는 매개변수를 주고 실행하면 다음과 같은 결과를 볼 수 있다.

위의 결과를 보면 알 수 있겠지만, ndk-build 라는 것은 GNU Make 에 대한 wrapper 이다. 여기에서 이제 또 다른 의문이 생길 것이다. 그럼 make 란 무엇인가?

make 라는 것은 Visual Studio 같은 IDE 가 가지고 있는 빌드 시스템과 유사하다고 생각하면 된다. 예를 들어 우리는 Visual Studio 를 사용해서 솔루션과 프로젝트를 만들고 거기에 소스 파일, 헤더 파일, 리소스 파일 등을 추가한다. 그 다음에 솔루션이나 프로젝트의 속성창을 열어 필요한 옵션들을 설정한다. 그리고 나서 빌드 버튼을 누르게 된다. 그러면 지정된 옵션에 따라서 컴파일과 링크가 수행된다. 이 때 "최소 다시 빌드" 옵션을 설정하게 되면, 변경된 파일을 검색해서 관련 object 파일만을 컴파일하고 링크하게 된다. make 가 바로 이러한 작업을 해 주는 도구이다. 

물론 make 가 하는 일이 단순하게 그런 것만 있는 것은 아니다. 의존성을 설정한다던가 batch 명령과 유사한 작업을 한다던가 여러 가지 작업을 하게 된다. make 는 여러 가지 구현이 존재한다. 그 중에서 가장 많이 사용하는 것이 GNU Make 이다. 자세한 내용은 "GNU Make 강좌" 를 참조하기 바란다.  GNU Make 의 매뉴얼은 "GNU Make Manual" 에서 찾아 볼 수 있다.

어쨌든 ndk-build 는 GNU Make 의 wrapper 이며, 우리는 이것을 프로젝트를 설정하고 빌드하는 것을 도와 주는 도구 정도로 생각하면 되겠다.

용례.

안드로이드 NDK r4 는 새로운 작은 쉡 스크립트인 'ndk-build' 를 소개했는데, 이는 머신 코드를 빌드하는 것을 단순화하기 위한 것이다.

이 스크립트는 NDK 의 최상위 디렉토리에 존재하며, 응용프로그램 프로젝트 디렉토리나 그것의 모든 하위 디렉토리들에서 명령줄에서 실행된다. 예를 들어 :

여기에서 $NDK 는 NDK 설치 경로이다. 당신은 그것을 매번 입력하는 것을 피하기 위해서 PATH 에다가 $NDK 를 추가하거나 alias 를 만들 수 있다.

옵션.

'ndk-build' 에 대한 모든 매개 변수는 NDK 빌드 스크립트를 실행하는 기저에 깔린 GNU Make 명령에 직접적으로 전달된다. 자주 쓰는 용례는 다음과 같다 :

• ndk-build : 머신 코드를 다시 빌드한다.
• ndk-build clean : 생성된 바이너리를 모두 지운다.
• ndk-build NDK_DEBUG=1 : 디버깅할 수 있는 네이티브 코드를 생성한다.
• ndk-build V=1 : 빌드를 시작하고, 빌드 명령들을 보여 준다.
• ndk-build -B : 완전한 다시 빌드를 강제한다.
• ndk-build -B V=1 : 완전한 다시 빌드를 강제하고, 빌드 명령들을 보여 준다.
• ndk-build NDK_LOG=1 : 내부 NDK 로그 메시지들을 보여 준다( NDK 자체를 디버깅하는데 사용된다 ).
• ndk-build NDK_DEBUG=1 : 디버깅 가능한 빌드를 강제한다( 아래 참조 ).
• ndk-build NDK_DEBUG=0 : 릴리스 빌드를 강제한다( 아래 참조 ).
• ndk-build NDK_HOST_32BIT=1 : 항상 32 비트 툴체인을 사용한다( 아래 참조 ).
• ndk-build NDK_APPLICATION_MK=<file> : 다시 빌드하는데, NDK_APPLICATION_MK 명령줄 변수에 의해 지정된 특정 Application.mk 를 사용한다.
• ndk-build -C <project> : <project> 에 위치한 프로젝트 경로를 위해 네이티브 코드를 빌드한다. 터미널에서 'cd' 를 입력하고 싶지 않을 때 유용하다.

디버그 빌드 대 릴리스 빌드.

NDK r5 에서 ndk-build 는 릴리스 빌드와 디버그 빌드 사이를 더 쉽게 전환할 수 있도록 변경되었다. 이는 NDK_DEBUG 변수를 사용해서 수행된다.

예를 들어 :

NDK_DEBUG 를 지정하면, ndk-build 는 그것의 기본 동작을 유지하는데, 그것은 AndroidMenifest.xml 에 <application> 엘리먼트가 존재하면  android:debuggable="true" 로 설정되어 있는지를 확인한다.

그리고 편리하게도 NDK 에 의해 생성된 릴리스 오브젝트 파일과 디버그 오브젝트 파일은 서로 다른 디렉토리에 저장된다( 예를 들어 obj/local/<abi>/objs 와 obj/local/<abi>obj-debug ). 이는 두 모드를 전환할 때 ( 심지어 당신이 한 두개의 소스 파일들만을 수정했을 때 ), 모든 소스들이 다시 빌드되는 것을 막아 준다.

64 비트 툴체인과 32 비트 툴체인.

일부 툴체인들은 64 비트 버전과 32 비트 버전을 둘 다 가지고 있다. 예를 들어 $NDK/toolchain/<name>/prebuilt 와 $NDK/prebuilt 는 "linux-x86" 과 "linux-x86-64" 폴더를, 만약 OS 가 그것을 지원한다면 32 비트 모드 리눅스 툴과 64 비트 모드 리눅스 툴을 위해 모두 포함하고 있다.당신은 환경 변수나 ndk-build 명령줄에서  NDK_HOST_32BIT=1 을 사용하여 32 비트 툴체인을 사용하는 것을 강제할 수 있다.

Note that 64-bit tools utilize host resources better( faster, handle larger programs, etc ) and they should function identically to their 32-bit counterparts. le. 64-bit toolchains still generate 32-bit binaries for Android.

요구 사항.

'ndk-build' 나 NDK 를 범용적으로 사용하기 위해서는 GNU Make 3.81 을 필요로 한다. 빌드 스크립트들은 적절하지 못한 Make 톨을 사용하고 있는지를 확인할 것이며 에러 메시지를 출력하며 불평할 것이다.

만약 GNU Make 3.81 이 설치되어 있지만 기본 'make' 명령에 의해 실행될 수 없는 상태라면, GNUMAKE 를 환경 변수에 정의해서 'ndk-build' 를 실행하기 전에 그것을 가리키도록 하라. 예를 들어 :

혹은 그 변경을 더 영구적으로 만들라 :

당신의 쉘과 GNU Make 3.81 설치 위치를 맞춰라.

당신은 다음과 같은 환경 변수들을 사용해서 $NDK/prebuilt/<OS>/bin 의 다른 호스트 prebuilt 툴들을 덮어 쓸 수도 있다.

내부 구현.

'ndk-build' 자체는 GNU Make 에 대한 작은 wrapper 이며, 그것의 목적은 올바른 NDK 빌드 스크립트를 쉽게 실행하는 것이다. 이는 다음과 동일하다 :

여기에서 '$GNUMAKE' 는 GNU Make 3.81 이상을 가리키며, '$NDK' 는 당신의 NDK 설치 디렉토리를 가리킨다.

다른 쉘 스크립트들( 혹은 당신만의 Makefile 들 )로부터 NDK 빌드 스크립트를 실행하고자 한다면 이에 대한 지식을 사용하라.

책에 보면 android 툴을 사용해서 프로젝트를 생성하는 것을 볼 수 있다. 예를 들면 다음과 같은 명령을 사용한다.

책에서는 그냥 저렇게 하면 프로젝트가 생성된다고만 말하고 실제 그것이 어떤 의미를 가지고 있는지 혹은 어떤 동작을 하는지에 대해서 설명하지 않는다. 그래서 "그런가 보다"하고 넘어 갔었는데, 역시 근원을 파고들고자 하는 욕구가 사라지지 않아서 정리해 본다. 다행히도 Android Developer 사이트에 관련 문서가 있어서 번역해 본다.

원문 : Manaing Projects from the Command Line

주의 : 번역이 개판이므로 이상하면 원문을 참조하십시오.

주의 : 허락받고 번역한 것이 아니므로 언제든 내려갈 수 있습니다.

주의 : 가독성을 높이기 위해서 잘 알려진 용어나 발음이 비슷한 용어는 한글로 표기합니다.

명령줄에서 프로젝트 관리하기

android 툴은 세 종류의 프로젝트들을 모두 생성하기 위한 명령들을 제공한다. 안드로이드 프로젝트는 프로젝트를 설치를 위한 .apk 파일로 빌드하는데 필요한 파일들과 리소스들을 포함한다.

• 안드로이드 프로젝트는 프로젝트를 설치를 위한 .apk 파일로 빌드하는데 필요한 파일들과 리소스들을 포함한다. 당신은 최종적으로 장치에 설치하고자 하는 모든 응용프로그램을 위해 안드로이드 프로젝트를 생성할 필요가 있다.
• 당신은 안드로이드 프로젝트를 라이브러리 프로젝트로서 설계할 수도 있는데, 이는 그것에 의졶하는 다른 프로젝트들과 공유되는 것을 허용한다. 안드로이드 프로젝트가 라이브러리 프로젝트로 설계되면, 그것은 장치에 설치될 수 없다.
• 테스트 프로젝트들은 JUnit 기능을 확장해 안드로이드에 특화된 기능들을 포함한다. 테스트 프로젝트를 생성하는 것과 관련한 더 많은 정보를 원한다면, Testing from other IDEs 를 참조하라.

안드로이드 프로젝트 생성하기기

안드로이드 프로젝트를 생성하려면, 당신은 android 툴을 사용해야만 한다. 당신이 android 로 새로운 프로젝트를 생성할 때, 그것은 일부 기본 파일들, stub 파일들, 설정 파일들, 빌드 파일을 가진 프로젝트 디렉토리를 생성할 것이다.

새로운 안드로이드 프로젝트를 생성하려면, 명령줄을 열고, SDK 의 tools/ 디렉토리로 가서, 다음을 실행하라 :

• target 은 응용프로그램을 위한 "빌드 타겟" 이다. 그것은 당신이 응용프로그램을 빌드하려고 하는 ( Google APIs 와 같은 모든 애드온을 포함하는 ) 안드로이드 플래폼 라이브러리와 관련이 있다. 이용 가능한 타겟들과 그것들의 관련 아이디들을 보려면, 다음을 실행하라 : android list targets.
• name 은 프로젝트의 이름이다. 이것은 선택 사항이다. 만약 이름이 제공되면, 이 이름은 응용프로그램을 빌드할 때 .apk 파일 이름으로 사용될 것이다.
• path 는 프로젝트 디렉토리의 위치이다. 만약 디렉토리가 존재하지 않으면, 자동으로 생성될 것이다.
• activity 는 기본 Activity 클래스의 이름이다. 이 클래스 파일은 <path_to_your_project>/src/<your_package_namespace_path>/ 내부에 생성될 것이다. 당신이 name 을 지정하지 않으면 그것은 .apk 파일 이름으로 사용될 것이다.
• package 는 프로젝트를 위한 패키지 이름인데, 자바 프로그래밍 언어에서의 패키지를 위한 규칙과 동일하다.

여기 예제가 있다 :

프로젝트를 생성하고 나면, 당신은 개발을 시작할 준비가 된 것이다. 원하는 곳에 프로젝트 폴더를 옮길 수는 있지만, 응용프로그램을 에뮬레이터에 보내기 위해서는  Android Debug Bridge ( adb ) - SDK 의 platform-tools/ 디렉토리에 있음 - 를 사용해야만 한다는 것을 염두에 두기 바란다( 이에 대해서는 나중에 언급한다 ). 그래서 당신은 프로젝트 솔루션과 paltform-tools/ 폴더에 접근할 필요가 있다.

Tip : platform-tools/ 와 tools/ 를 PATH 환경 변수에 추가하라.

Caution : 당신은 SDK 디렉토리의 위치를 움직여서는 안 된다. 왜냐하면 이는 local.properties 에 위치한 SDK 위치 속성을 깨 버리기 때문이다. 만약 당신이 SDK 위치를 옮기고자 한다면, android update project  명령을 사용하라. 더 많은 정보를 원한다면 "프로젝트 갱신하기" 를 참조하라.

프로젝트 갱신하기

만약 이전 버전의 안드로이드 SDK 에서 만든 프로젝트를 업그레이드하고 싶거나 현존하는 코드로부터 새로운 프로젝트를 생성하고 싶다면, android update project 명령을 사용해 프로젝트를 새로운 개발 환경으로 갱신하라. 당신은 이 명령을 ( --target 옵션과 함께 ) 사용해서 현존하는 프로젝트의 빌드 타겟을 변경하거나 ( --name 옵션과 함께 ) 프로젝트 이름을 변경할 수 있다. android 툴은 분실되거나 갱신될 필요가 있는 ( 이전 섹션에서 열거되었던 ) 모든 파일들과 폴더들을 안드로이드 프로젝트가 필요한 만큼 생성하게 될 것이다.

현존하는 안드로이드 프로젝트를 갱신하려면, 명령줄을 열고 SDK 의 tools/ 디렉토리로 이동하라. 그리고 다음을 실행하라 :

• target 은 응용프로그램을 위한 "빌드 타겟" 이다. 그것은 당신이 응용프로그램을 빌드하려고 하는 ( Google APIs 와 같은 모든 애드온을 포함하는 ) 안드로이드 플래폼 라이브러리와 관련이 있다. 이용 가능한 타겟들과 그것들의 관련 아이디들을 보려면, 다음을 실행하라 : android list targets.
• path 는 프로젝트 디렉토리의 위치이다. 만약 디렉토리가 존재하지 않으면, 자동으로 생성될 것이다.
• name 은 프로젝트의 이름이다. 이것은 선택 사항이다. 만약 이름이 제공되면, 이 이름은 응용프로그램을 빌드할 때 .apk 파일 이름으로 사용될 것이다.

여기 예제가 있다 :

라이브러리 프로젝트 설정하기

라이브러리 프로젝트는 표준 안드로이드 프로젝트이다. 그래서 당신은 새로운 응용프로그램 프로젝트를 생성하는 것과 같은 방식으로 새로운 라이브러리 프로젝트를 생성할 수 있다. 특히, 당신은 필요한 파일들과 폴더들을 가진 새로운 라이브러리를 생성하기 위해 android 툴을 사용할 수 있다.

새로운 라이브러리 프로젝트를 생성하려면, <sdk>/tools/ 디렉토리로 이동하고 다음 명령을 사용하라 :

create lib-project 명령은 그 프로젝트가 라이브러리임을 빌드 시스템에 알려주는 프리셋 속성을 포함하는 표준 프로젝트 구조를 생성한다. 그것은 프로젝트의 project.properties 파일에다가 다음 라인을 추가함으로써 수행된다 :

명령이 종료되면, 라이브러리 프로젝트가 생성되고 당신은 아래 섹션들에서 설명하는 것처럼 소스 코드와 리소스들을 그 프로젝트 안으로 옮기기 시작할 수 있다.

만약 당신이 현존하는 응용프로그램 프로젝트를 라이브러리 프로젝트로 변환해서 다른 응용프로그램들이 그것을 사용할 수 있도록 하고 싶다면, 당신은 adnroid-library=true 속성을 응용프로그램의 project.properties 파일에 추가함으로써 그 작업을 수행할 수 있다.

매니페스트 파일 생성하기

라이브러리 프로젝트의 매니페스트 파일은 표준 안드로이드 응용프로그램처럼 반드시 그것이 포함하고 있는 공유 요소들을 모두 선언해야만 한다. 더 많은 정보를 원한다면, AndroidManifest.xml 을 위한 문서를 참조하라.

예를 들어, TicTacToeLib 예제 라이브러리 프로젝트는 GameActivity 라는 Activity 를 선언한다 :

라이브러리 프로젝트 갱신하기

만약 당신이 라이브러리 프로젝트의 빌드 속성들( 빌드 타겟, 위치 )을 갱신하고자 한다면, 다음 명령을 사용하라 :

라이브러리 프로젝트 참조하기

만약 당신이 응용프로그램을 개발하고 있고 공유 코드와 공유 리소스들을 라이브러리 프로젝트로부터 가져 오기를 원한다면, 당신은 응용프로그램 프로젝트의 빌드 속성들에 라이브러리 프로젝트에 대한 참조를 추가함으로써 이를 쉽게 수행할 수 있다.

라이브러리 프로젝트에 대한 참조를 추가하려면, <sdk>/tools/ 디렉토리로 가서 다음 명령을 사용하라 :

이 명령은 응용프로그램의 빌드 속성들을 갱신해서 라이브러리 프로젝트에 대한 참조를 포함하도록 한다. 특히, 그것은 android.library.reference.n 속성을 프로젝트의 project.properties 파일에 추가한다. 예를 들면 :

여러 개의 라이브러리들에 대한 참조를 추가하고 있다면, 당신은 그것의 상대적인 우선순위를 ( 그리고 merge 순서를 ) 설정할 수 있는데, 이는 project.properties 파일을 수작업으로 편집하고 각 참조들의 .n 인덱스를 적절하게 변경함으로써 이루어 진다. 예를 들어, 이러한 참조들을 가정해 보자 :

당신은 library_projectC 에 가장 높은 우선순위를 부여하기 위해 다음과 같이 참조들을 재정렬할 수 있다 :

레퍼런스들에서 .n 인덱스는 "1" 로 시작하며 "구멍" 없이 하나씩 증가한다는 것에 주의하라. 빠진 부분이 생긴 다음의 인덱스에서 나타나는 참조들은 무시된다.

빌드시에, 그 라이브러리들은 응용프로그램에 동시에 merge 되는데, 가장 낮은 우선순위에서 시작해 가장 높은 우선순위로 merge 된다. 라이브러리는 스스로는 다른 라이브러리를 참조할 수 없으며, 빌드시에 라이브러리들은 응용프로그램과 merge 되기 전에 다른 것들과 merge 되지 않는다는 것에 주의하라.

매니페스트 파일에서 라이브러리 요소 선언하기

응용프로그램 프로젝트의 매니페스트 파일에서, 당신은 응용프로그램이 라이브러리 프로젝트로부터 들여 오게 되는 응용프로그램이 사용하게 될 모든 요소들에 대한 선언을 추가해야만 한다. 예를 들어, 당신은 모든 <activity>, <service>, <receiver>, <provider> 등을 선언해야만 한다. 그리고 <permission>, <uses-library> 및 그와 유사한 요소들도 선언해야만 한다.

선언들은 라이브러리 요소들의 fully-qualified 이름들을 사용해 적절한 위치의 라이브러리 요소들을 참조한다.

예를 들어, TicTacToeMain 예제 응용프로그램은 다음과 같이 GameActivity 라는 라이브러리 Activity 를 선언한다 :

매니페스트 파일에 대한 더 많은 정보를 원한다면, AndroidManifest.xml 을 위한 문서를 참조하라.

의존성 있는 응용프로그램 빌드하기

하나 이상의 라이브러리 프로젝트에 의존하는 응용프로그램 프로젝트를 빌드하기 위해, 당신은 Build and Running 에 기술된 것처럼 표준 Ant 빌드 명령들과 컴파일 모드들을 사용할 수 있다. 그 툴들은 의존성 있는 응용프로그램 프로젝트를 컴파일하는 작업의 일부로서 응용프로그램에 의해 참조되는 모든 라이브러리들을 컴파일하고 merge 한다. 다른 명령들이나 단계들이 필요하지 않다.

Ubuntu 12.10 에서 NDK 를 설치할 때, 압축 관리자로 그냥 압축을 푸는 경우에 ndk-build 를 실행하면 다음과 같은 에러를 만날 수 있다.

이 문제 때문에 한참 고생을 했는데, 압축이 잘 못 풀려서 arm-linux-androideabi-gcc 가 생성되지 않기 때문에 발생하는 문제이다. 파일탐색기에서 "여기에 풀기"를 통해 압축을 풀면 이상하게 압축이 제대로 풀리지 않는 문제가 있다.

그래서 다음과 같이 직접 압축을 풀었더니 arm-linux-androideabi-gcc 가 제대로 생성되었다.

파일탐색기에서 푸는 것이 왜 제대로 안 풀리는 지는 모르겠다. 한 번 알아 볼 필요가 있을 것 같다.

AskUbuntu 에다가 질문을 올려 두었다. 어떤 답이 나올지 궁금하다. 리눅스 초보자라 이것 저것 모르는게 많아 골치 아프다; Why does a "Extract Here" context menu work incorrectly?

주의 : 공부하면서 정리한 내용이라 오류가 있을 수 있습니다.

주의 : 가독성을 높이기 위해서 잘 알려진 용어나 발음이 비슷한 용어는 한글로 표기합니다.

Android NDK 개발 환경 : Cygwin

왜 Cygwin 이 필요한가?

개발자라면 자신이 개발하고 있는 환경에 대해서 제대로 이해해야 할 필요가 있다고 생각한다. NDK 를 사용해서 안드로이드 앱을 개발하기 전에 개발환경에 대해서 대강이라도 이해해 보고자 공부하면서 정리해 본다.

안드로이드는 기본적으로 리눅스 커널을 기반으로 올라 가 있는 가상머신이기 때문에 NDK 는 리눅스 개발환경과 관련이 있다. 그러므로 윈도우즈 환경에서 안드로이드 NDK 프로그래밍을 하기 위해서는 시그윈이 필수이다. 아래 그림은 안드로이드의 시스템 아키텍처를 설명하는 것으로서, 인터넷에 가장 많이 퍼져 있는 것을 주워 왔다.

NDK 로 개발을 한다는 것이 의미하는 바가 무엇인지 생각해 볼 필요가 있다. 많이들 알고 있는 사실이겠지만, 어떤 프로그램이 어떤 머신에서 실행되기 위해서는 해당 머신에 맞는 실행가능한 파일( executable )을 만들어야만 한다. 그것이 소위 우리가 알고 있는 '컴파일'과 '링크'라는 작업이다. 이 컴파일 작업과 링크 작업을 합쳐서 '빌드'라고 표현한다.

우리가 열심히 코딩한 라인들은 어셈블리어로 변환되고, 이 어셈블리어들은 다시 기계어로 변환된다. 그리고 CPU 는 이 기계어를 마이크로 명령어로 나누어서 프로그램을 실행하게 된다. 그런데 이 CPU 가 어떠한 명령어 집합 구조( Instruction Set Architecture, ISA )를 제공하느냐에 따라서 다른 기계어를 만들어야 하기 때문에, 프로그램을 빌드할 때는 해당 CPU 에 맞는 구성을 만들어야 한다. 예를 들어 CPU 가 x86 ISA 를 제공한다면 x86 에 맞는 빌드 구성을 해야 하고, CPU 가 x86/64 를 제공한다면 거기에 맞는 빌드 구성을 만들어야 한다.

자 우리가 NDK 를 통해 만든 바이너리를 실행할 플래폼의 환경은 어떠한가? 일반적으로 현재 안드로이드 OS 가 돌아 가는 환경은 ARM 코어를 사용하는 리눅스 환경이다. 이는 어떠한 사실을 내포할까?

• 우리가 C/C++ 응용프로그램을 개발할 때 CreateFile() 과 같은 Win32 API 를 사용할 수 없다.

• Visual Studio 를 이용할 수 없다. --> VC++ 컴파일러를 사용할 수 없다.

사실 Visual Studio 의 컴파일러를 GCC( GNU Compiler Collection ) C++ 컴파일러로 연결해 놓고 개발할 수는 있을 것이다. 하지만 기본 환경 자체가 Win32 서브시스템과 x86 혹은 x86-64 아키텍처를 위한 개발에 최적화되어 있으므로 참 어려운 일이 될 것이다. 구글링을 해 보면 여러 가지 자료들이 나오기는 하는데 얼마나 편한 지는 잘 모르겠다. 어쨌든 우리는 리눅스 OS 를 기반으로 ARM ISA 에 맞춰서 빌드해야만 하는 상황이고, 윈도우즈 환경에서 이를 가능하게 만들 수 있는 방법을 찾아야만 한다. 

이때 우리에게 한 줄기 빛을 비춰주는 존재가 있으니, 그것이 바로 시그윈이다.

Cygwin 이란 무엇인가?

일단 시그윈 공식 사이트의 설명을 인용해 보도록 하겠다. 출처 : http://cygwin.com/index.html

시그윈은 :

• 윈도우즈를 위해 리눅스처럼 느껴지는 환경을 제공하는 도구들의 집합이다.

• 많은 리눅스 API 기능을 제공하는 리눅스 API 레이어로서 동작하는 DLL( cygwin1.dll )이다.

그리고 다음과 같이 착각하지 말라고 경고하고 있다.

시그윈은  :

• 윈도우즈 상에서 네이티브 리눅스 앱들을 실행하는 방법이 아니다. 당신이 윈도우즈 상에서 프로그램을 실행하기 원한다면, 소스로부터 앱들을 리빌드해야만 한다.
• signal, pty 등과 같은 유닉스 기능들을 인지하는 네이티브 윈도우즈 앱들을 마술처럼 만들어 주는 방법이 아니다. 다시 말하지만, 당신이 시그윈 기능의 이점을 취하기 원한다면, 소스로부터 앱들을 리빌드할 필요가 있다.

앞에서도 언급했지만 특정 CPU 아키텍처에 대해 리눅스용으로 빌드된 프로그램은 윈도우즈에서 실행될 수 없다. 당연히 윈도우즈 환경에 맞는 구성으로 다시 빌드해야만 한다. 시그윈은 크로스 플래폼 개발을 가능하게 해주는 환경일 뿐이지, 에뮬레이터가 아니라는 것을 명심해야만 한다.

Cygwin 의 작동 원리.

그렇다면 시그윈은 어떻게 해서 리눅스와 같은 개발 환경을 지원하게 되는 것일까?

여러분은 Visual Sutdio 를 통해 프로젝트 설정을 하다가 '서브시스템' 이라는 항목을 본 적이 있을 것이다. 윈도우즈는 여러 개의 서브시스템을 가지고 있는데, 우리가 주로 사용하는 것이 Win32 서브시스템이다. 아래 그림은 Windows NT 의 시스템 아키텍처에서의 POSIX 서브시스템을 보여 주고 있다.

윈도우즈 NT 시스템 아키텍처( 출처 : 위키피디아 )

이 POSIX 라는 것은 Portable Operating System Interface 의 약자로 IEEE 가 운영체제 간의 호환성을 유지하기 위해서 제정한 표준이다.

POSIX( 대충 '파직스'라고 발음됨 )는 "Portable Operating System Interface" 의 머리글자들이며, 운영체제 간의 호환성을 유지하기 위해서 IEEE 에 의해 제정된 표준 패밀리이다. POSIX 는 다양한 유닉스 및 다른 운영 체제들 간의 소프트웨어 호환성을 위해 응용프로그램 인터페이스( API )와 명령줄 쉘, 그리고 유틸리티 인터페이스들을 정의한다.

중략...

유닉스 같은 운영 체제 환경을 위한 POSIX 명세는 원래 코어 프로그래밍 인터페이스를 위한 단일 문서로 구성되어 있었지만, 결국에는 19 개의 분리된 문서로 늘어 났다( 예를 들면 POSIX1, POSIX2, 등 ). 표준화된 사용자 명령 줄과 스크립팅 인터페이스들은 Korn Shell 에 기반했다. awk, echo, ed 등을 포함하는 많은 사용자 수준 프로그램, 서비스, 유틸리티들도 표준화되었으며, 기본적인 I/O( 파일, 터미널, 네트웤 )을 포함하는 프로그램 수준 서비스들도 포함한다. POSIX 는 표준 스레딩 라이브러리 API 도 정의하는데, 이는 현대의 거의 대부분의 OS 에 의해서 지원된다. 요새는 대부분의 POSIX 파트들이 하나의 IEEE Std 1003. 1-2008 표준에 포하모디었으며, 이는 POSIX 1-2008 로 알려져 있다.

하략...

- 출처 : 위키피디아, POSIX

OS/2 라는 것은 MS 와 IBM 이 초기에 제작한 운영체제로 요새는 별로 의미가 없으므로 관심있는 분들은 위키피디아의 OS/2 라는 글을 따로 읽어 보기 바란다.

POSIX 를 지원하는 OS 리스트는 다음 링크의 'POSIX-oriented operating systems' 절에서 찾아 볼 수 있다 : 위키피디아, POSIX. GNU/Linux 같은 경우에는 POSIX 에 대해 '거의 대부분의 호환성' 을 가지고 있다. 시그윈은 POSIX 에 대해 '많은 호환성' 을 가지고 있다고 표현되고 있다. 즉 안드로이드 시스템의 기반이 되는 리눅스가 POSIX 를 거의 완벽하게 지원하고 있기 때문에, 우리는 윈도우즈 상에서 시그윈을 통해 거기에 맞는 환경을 구성할 수 있는 것이다.

위에서 윈도우즈의 POSIX 서브시스템에서 언급을 했는데 여기에서 윈도우즈의 POSIX 를 언급한 것은 그냥 예를 든 것 뿐이다. 시그윈이 윈도우즈의 POSIX 서브시스템의 레이어라는 이야기는 아니다. 왜 그럴까? 윈도우즈의 POSIX 서브시스템은 POSIX 표준을 제대로 지키고 있지 않기 때문이다. 

시그윈은 윈도우즈의 POSIX 와는 개별적으로 동작하는 개발환경이다. 시그윈 환경, 시그윈 서브시스템, 시그윈 플래폼 등의 용어를 사용해도 무방하지 않을까 싶다. 시그윈이 윈도우즈의 POSIX 서브시스템의 레이어로서 동작하지 않는 이유는 다음 글을 보면 좀 더 이해가 가지 않을까 싶다 : The Sad History of the Microsoft POSIX Subsystem. 아래에 일부만 인용해 보았다. 요약하면 윈도우즈 POSIX 가 허접(?)이란 것과 XP 부터는 POSIX 서브시스템을 지원하지 않는다는 것이다. 그 뒤의 이야기가 쭉 나오는데 다 읽어 보지는 못했다.

윈도우즈 NT 가 처음 개발되고 있었을 때, 목표 중의 하나는 커널을 프로그래밍 인터페이스와 분리하는 것이었다. NT 는 원래 OS/2 를 성공시키기 위한 것이었지만, 마이크로소프트는 윈도우즈 3.x 응용프로그램들을 실행하기 위한 호환성을 포함시키고, 방위산업 시장에 판매하기 위한 1980 년대 DoD( 국방성 ) Orange Book 과 FIPS 명세들을 만족시키기 원했다. 결과적으로 윈도우즈 NT 는 복잡한 자유재량에 의한 접근 제어 기능을 가진 멀티유저 플래폼으로서 개발되었으며, 하이브리드 마이크로커널 3 유저랜드^[각주:1] 환경들로서 구현되었다 :

• Windows( Win32 )
• OS/2
• POSIX

마이크로소프트는 Win32 문제를 가지고 IBM 과 다퉜으며, NT 프로젝트는 OS/2 와 갈라섰다. 팀의 초점은 Win32 로 이동했다. 그래서 Win32 API 를 호스트하는 Client Server Runtime Subsystem( CSRSS ) 은 의무적이 되었으며, OS/2 와 POSIX 서브시스템이 실제로 완료되지 않았음에도 불구하고 그것들은 윈도우즈 NT 부터 윈도우즈 2000 까지 5 개의 버전에 포함되었다. OS/2 서브시스템은 단지 OS/2 1.0 명령줄 프로그램들만을 실행할 수 있으며, presentation manager 에 대한 지원이 존재하지 않았다. POSIX 서브시스템은 POSIX.1 명세를 지원했지만, 모든 종류의 쉘이나 유닉스 같은 환경을 제공하지 않았다. Win32 가 윈도우즈 95 의 형태에서 성공하면서, OS/2 와 POSIX 서브시스템의 개발은 중단되었다. 그것들은 윈도우즈 XP 와 윈도우즈 서버 2003 에서 완전히 죽고 사라졌다.

반면에 Softway Systems 는 1996 년 쯤에 OpenNT 라고 불리는 유닉스-윈도우즈 NT 간 포팅 시스템을 개발했다. OpenNT 는 NT POSIX 서브시스템 상에서 빌드되었지만, 그것에 살을 붙여 이용할 수 있는 유닉스 환경을 제공했다. 이는 유닉스 시스템이 매우 비싸진 시점이었다. Softway 는 OpenNT 를 사용해서 US Federal agency 들을 위한 여러 유닉스 응용프로그램들을 윈도우즈 NT 로 변경했다. 1998 년에 OpenNT 는 Interix 라고 이름을 바꿨다. Softway Systems 는, 마이크로소프트 POSIX 서브시스템이 지원하지 않았던 시스템 호출을 구현하고, 풍부한 libc,  파일 시스템에 대한 single-rooted view, 그리고 실용적인 gcc 를 개발하기 위해, 최종적으로 NT POSIX 서브시스템에 대한 완전한 대체물을 만들었다.

하략...

위키피디아에 의하면 Windows Server 2003 R2 부터는 사실은 Interix 의 변형인 SUA( Subsystem for UNIX-based Applications )를 통해서 POSIX 를 지원하고 있다고 한다. 이것은 SFU( Windows Services for UNIX )라고 불리기도 한다. Windows Vista 및 Windows 7 의 Enterprise 에디션과 Ultimate 에디션도 SUA 를 포함하고 있다고 한다. 자세한 내용은 Windows Services for UNIX 를 참조하라.

결론.

우리가 윈도우즈 환경에서 리눅스 ARM 용 프로그램을 빌드하기 위해서는, 그에 맞는 바이너리를 생성해 줄 수 있는 환경( 컴파일러, API 등 )을 구성할 필요가 있다. 윈도우즈에서 이를 가능하게 해 주는 것이 POSIX 기반의 시그윈 개발 환경이다. 

우리는  시그윈 환경을 이용해 리눅스 ARM 용 프로그램을 빌드하고, 그것을 안드로이드 장치로 복사하고 설치하게 된다. 이것이 윈도우즈와 리눅스 간의  크로스 플래폼 개발이다. 안드로이드 SDK 를 사용하게 되면 자바 바이트 코드( 플래폼에 독립적인 중간 코드 )를 생성하기 때문에 빌드 환경이 중요하지 않지만, 안드로이드 NDK 는 실제 리눅스 API 를 이용하고 기계어로 컴파일하기 때문에 반드시 올바른 환경에서 개발해야만 한다.

이제 시그윈이라는 것의 정체에 대해 어느 정도 이해할 수 있게 되었을 것이라 생각한다. 그리고 시그윈을 통해 뭔가를 빌드한다는 것의 의미에 대해서 이해할 수 있게 되었을 것이라 생각한다.

다음에 시간이 나면 POSIX 에 대해서 좀 더 구체적으로 다뤄 보도록 하겠다.