Application.mk 문법 해석

Application.mk는 응용 프로그램이 어떤 모듈을 필요로 하는지, 그리고 이 모듈들이 가지고 있어야 할 특성을 설명하는 데 사용됩니다.상대적인 안드로이드.mk는 특정한 모듈을 컴파일하는 데 필요한 자원으로 컴파일할 원본 코드, 링크할 라이브러리 등을 포함한다.
Application.mk에서 설명하고자 하는 내용은 주로 다음과 같습니다.
1) 프로그램이 정상적으로 실행되고 모듈에 필요한 구체적인 목록;
2) 프로그램은 어떤 기계 지령집으로 컴파일해야 하는가;
3) 모든 모듈을 Release 버전으로 컴파일할 것인지 Debug 버전으로 컴파일할 것인지;
4) C 또는 C++ 컴파일러에 전달되는 컴파일러 매개변수입니다.
Application.mk 파일은 일반적으로 $PROJECT/jni/디렉터리에 놓여 있습니다. ($PROJECT는 당신이 쓴 프로그램의 프로젝트 디렉터리를 대표합니다.) 이렇게 하면 ndk-build 명령이 자동으로 그것을 검색할 수 있습니다.
물론, Application.mk 파일은 사실 선택할 수 있습니다.기본적으로 ndk-build 명령에서 Application을 찾을 수 없습니다.mk 파일은 다음과 같은 규칙을 사용하여 컴파일됩니다.
1) Android에서 모두 컴파일됩니다.mk 파일에 열거된 모듈;
2) 모든 모듈에 대해 NDK 컴파일링 시스템은 "armeabi"ABI에 따라 기계 코드를 생성한다. 즉, 명령 집합은 ARMv5TE이다.
구체적으로 말하면 Application.mk 파일에는 다음 변수에 대한 정의가 포함될 수 있습니다.
APP_PROJECT_PATH
이 변수는 컴파일러 시스템에 프로그램 항목의 루트 디렉터리의 절대 경로를 알려 줍니다.
일반적으로 컴파일된 Native 모듈은 APK 애플리케이션으로 패키지화됩니다.APK 패키지 도구는 프로젝트 루트 디렉터리에 있는 특정한 하위 디렉터리에서 패키지할 것이 있는지 검색합니다.so 파일의 경우 프로젝트 루트 디렉터리의 절대 경로를 지정하면 ndk-build 명령이 컴파일된 후에 컴파일됩니다.so 모듈 파일은 프로젝트의 특정 하위 디렉터리로 복사하여 나중에 포장하기 편리하다.
만약 프로젝트 디렉터리의 조직 형식이 $PROJECT/jni/Application과 유사하다면.mk, 이 변수는 선택할 수 있습니다.
APP_MODULES
이 변수는 선택할 수 있는 것이다.APPMODULES 변수가 정의되지 않으면 NDK는 안드로이드에 컴파일됩니다.mk 파일에 정의된 모든 모듈과 해당 모듈에 포함된 모든 하위 MakeFile 파일.
APPMODULES 변수가 정의되면 NDK는 명시적으로 나열된 모듈만 컴파일합니다.
모든 모듈의 이름은 공백으로 나누어야 하며 NDK는 각 모듈 간의 의존 관계를 자동으로 계산합니다.
또한 NDK r4에서 이 변수의 동작이 변경되었습니다.이 버전 이전에 Application.mk에서 이 변수를 정의해야 하며, 모든 모듈의 이름 목록을 명확하게 열거해야 합니다.이 버전 이후 이 제한을 취소했다.
APP_OPTIM
이 변수는 선택할 수 있습니다. NDK에서 모든 모듈을 Release 버전으로 컴파일하는지 Debug 버전으로 컴파일하는지 알려 주는 데 사용할 수 있습니다.
이 변수가 "release"로 정의되면 NDK는 모든 모듈을 Release 버전으로 컴파일합니다. 즉, 코드를 깊이 있게 최적화하고 모든 디버깅 정보를 제거합니다.이러한 결과는 컴파일된 코드의 실행 효율이 높고 파일이 비교적 작지만 디버깅에 불리하다는 것이다.
이 변수가 "debug"로 정의되면 NDK는 모든 모듈을 Debug 버전으로 컴파일하고 Release 버전과 반대로 코드를 최적화하지 않으며 디버깅 정보를 많이 추가합니다.이러한 결과는 컴파일된 코드의 실행 효율이 비교적 낮고 파일이 상대적으로 크지만 디버깅하기에 매우 편리하다는 것이다.
이 변수를 특별히 지정하지 않으면 NDK는 프로그램이 디버깅 가능한지 자동으로 확인합니다. (프로젝트 디렉터리에 있는 안드로이드 Manifest.xml 파일을 보고 탭에서android: debuggable 속성을 "true"로 설정했는지 확인합니다.) Release 버전을 컴파일할지 Debug 버전을 컴파일할지 결정합니다.
그러나 이 변수를 정의했다면 이 변수가 정의된 상황을 기준으로 한다.응용 프로그램이 디버깅할 수 있든 없든 상관없다.
APP_CFLAGS
모든 모듈의 C나 C++ 원본을 컴파일할 때 특수한 컴파일 옵션을 지정해야 한다면 이 변수를 정의해서 실현할 수 있습니다.
안드로이드에 있습니다.mk 파일에서도 각 모듈에 이 모듈에 특정된 컴파일 옵션을 지정할 수 있습니다.하지만 Application에서mk 파일에서 이 변수를 정의하면 그 작용역은 특정한 모듈이 아니라 모든 모듈입니다.
예를 들어, 당신이 컴파일하고자 하는 몇 개의 모듈이 특정한 디렉터리에서 헤더 파일 정의를 검색해야 한다면, 두 가지 방법이 있을 수 있다.하나는 각 모듈을 수정하는 안드로이드입니다.mk 파일, 각 모듈에 대한 LOCAL 정의CFLAGS 변수, 그 디렉터리 포함;둘째는 응용 프로그램만 수정하는 Application입니다.mk 파일, APP 정의CFLAGS 변수, 그 디렉터리를 포함합니다.
Android NDK 1.5 r1 버전에서는 이 변수가 컴파일된 C++ 소스 파일에만 적용되며 컴파일된 C++ 소스 파일에는 아무런 영향이 없습니다.이 문제는 다음 NDK 릴리즈에서 수정되었습니다.
APP_CPPFLAGS
및 앞서 설명한 APPCFLAGS 변수는 유사하며, 특수한 컴파일 옵션을 지정하는 데도 사용되지만, C++ 원본 파일만 컴파일합니다.
안드로이드 NDK 1.5r1 버전에서는 이 변수가 C 원본 파일을 컴파일할 뿐만 아니라 C++ 원본 파일의 컴파일에도 작용할 수 있음을 주의하십시오.이 문제는 다음 NDK 릴리즈에서 수정되었습니다.
현재 컴파일 C와 C++ 원본 파일에 같은 컴파일 옵션을 지정하려면 앞에서 설명한 APPCFLAGS 변수.
APP_CXXFLAGS
APPCPPFLAGS 변수의 별칭이지만, 그것은 이미 유행이 지났고, 미래의 NDK 버전에서는 더 이상 사용하지 않을 수도 있다.따라서 최대한 사용하지 말고 APP 를 사용하는 것이 좋습니다.CPPFLAGS 변수.
APP_BUILD_SCRIPT
기본적으로 NDK 컴파일 시스템은 $(APP PROJECT PATH)/jni 디렉토리에서 Android라는 이름을 자동으로 찾습니다.모듈 정의 파일로 mk 파일입니다.
당신의 안드로이드라면.mk 파일을 다른 위치에 두거나 모듈 정의 파일을 안드로이드라고 부르지 않습니다.mk, 이 변수의 값을 수정하면 NDK에서 지정한 모듈 정의 파일을 사용할 수 있습니다.
절대 경로가 아닌 경로는 항상 NDK 최상위 디렉토리에 대한 경로로 해석됩니다.
APP_ABI
기본적으로 NDK 컴파일링 시스템은 "armeabi"ABI에 따라 ARMv5TE 명령 집합을 사용하고 소프트웨어 부동 동작을 지원하는 CPU를 생성합니다.
당신은 APP 를 정의할 수 있습니다ABI 변수로 다른 ABI를 선택하십시오.
예를 들어, ARMv7 명령 집합을 사용하고 하드웨어 FPU를 지원하는 장치에서 프로그램을 실행하려면 다음을 사용할 수 있습니다.

APP_ABI := armeabi-v7a

또는 IA-32 명령 집합을 지원하려면 다음과 같이 하십시오.

APP_ABI := x86

또는 프로그램이 MIPS 명령 집합을 지원하려면 다음과 같이 하십시오.

APP_ABI := mips

또는 네 가지 플랫폼을 모두 지원하려면 다음과 같이 하십시오.

APP_ABI := armeabi armeabi-v7a x86 mips

물론, 너도 임의의 몇 개의 ABI를 사용할 수 있다. 각 ABI 사이를 빈칸으로 나누기만 하면 된다.
또는 NDK r7 이상 버전을 사용하면 모든 ABI 플랫폼을 지원한다는 뜻으로 "all"를 사용할 수 있습니다.

APP_ABI := all

APP_STL
기본적으로 NDK 컴파일링 시스템은 최소 C++ 실행 라이브러리 (/system/lib/libstdc++.so) 에만 C++ 헤더 파일을 제공합니다.
그러나 NDK는 다른 선택할 수 있는 C++ 실행 라이브러리를 가지고 있습니다. 응용 프로그램에서 Application을 통해 선택할 수 있습니다.mk에서 정의된 APPSTL 변수 중 하나를 사용하거나 링크합니다.
이 변수는 다음과 같은 값으로 설정할 수 있습니다.
1)system
2)gabi++_static
3)gabi++_shared
4)stlport_static
5)stlport_shared
6)gnustl_static
7)gnustl_shared
특별히 정의하지 않으면 '시스템' 실행 시 라이브러리는 기본값입니다.이외에 뒤에 'static'이 있는 모든 것은 정적 링크가 있는 실행 라이브러리임을 나타낸다(실행 라이브러리의 코드는 컴파일된 프로그램에 포함된다).뒤에 'shared'가 있는 모든 것은 동적 링크가 있는 실행 라이브러리임을 나타낸다(실행 라이브러리는 프로그램이 실행될 때 동적으로 불러온다).동적 또는 정적 링크 요소를 제거하면 기본 '시스템' 실행 라이브러리 외에 이른바'gabi++ '실행 라이브러리,'stlport' 실행 라이브러리와'gunstl '실행 라이브러리도 있습니다.이 네 가지 런타임 라이브러리에서 지원하는 C++ 특성은 다음과 같습니다.
 
C++ 예외
C++ RTTI
C++ 표준 라이브러리
System
지원되지 않음
지원되지 않음
지원되지 않음
gabi++
지원되지 않음
뒷받침
지원되지 않음
stlport
지원되지 않음
뒷받침
뒷받침
gnustl
뒷받침
뒷받침
뒷받침
C++ 이상을 지원하려면gunstl 실행 라이브러리를 사용해야 합니다.
APP_GNUSTL_FORCE_CPP_FEATURES
NDK r7b 이전 버전에서gnustl 런타임 라이브러리를 사용하도록 지정하면 기본적으로 컴파일된 코드에 C++ 이상과 C++ RTTI에 대한 지원 코드가 추가됩니다.
이렇게 하면 일정한 문제를 초래할 수 있다.또한 프로그램이 C++ 이상과 C++ RTTI 같은 기능을 사용하지 않아도 지원하는 코드는 모듈에 추가되어 모듈의 크기를 크게 증가시킬 수 있습니다.
이 문제는 NDK r7b 및 이후 릴리즈에서 해결되었습니다.단, C++ 이상 또는 C++ RTTTI 특성을 사용해야 한다면 NDK 컴파일링 시스템에 명확하게 알려야 한다(Application.mk에서 APP CPPFLAGS 변수를 정의하거나 Android.mk에서 LOCAL CPPFLAGS 또는 LCAL CPPPPP FEATURES 변수를 정의해서 알려줄 수 있다).
그러나 이러한 문제는 호환성 문제이며, 같은 컴파일 스크립트는 서로 다른 NDK 버전에 따라 구분해야 한다.
이런 과도함을 더욱 원활하게 하기 위해서는Application에서mk 파일에 정의된 APPGNUSTL_CPP_FEATURES 변수는 어떤 C++ 특성을 지원할 것인지 지정합니다.
이 변수는 다음 두 값으로 설정할 수 있습니다.
1) exceptions: 컴파일된 코드가 C++ 이상 기능을 지원해야 한다는 것을 나타낸다.
2) rtti: 컴파일된 코드가 C++ RTTI 기능을 지원할 것임을 나타냅니다.
예를 들어, 프로그램에서 C++ 예외 지원과 C++ RTTI 지원을 받으려면 다음과 같이 하십시오.

APP_GNUSTL_FORCE_CPP_FEATURES := exceptions rtti