Project portability

Goal

짧게 얘기해서 portable project는 어떤 플랫폼의 어떤 Workspace 에서던 수정이나 변경없이 사용가능한 프로젝트를 말합니다.

Toolchain path

툴체인 경로는 프로젝트 이동성을 망칠 수 있는 전통적인 원인입니다.

버전 2.x부터 GNU ARM Eclipse cross build plug-in은 더 이상 툴체인 패스를 .cproject에 저장하지 않으며, 이러한 경로를 사용하지 않습니다.

툴체인 패스와 관련된 사항들은 모두 workspace 안에 저장됩니다.

각각의 툴체인은 하나의 패스로 결합되고, 결국, 특별한 설정을 각 프로젝트에 대해 하나의 경로를 통해 연결할 수 있습니다.

자세한 사항은 Toolchain path management page를 참조하세요

Include paths

프로젝트 이식성을 손상시킬 수 있는 두 번째 일반적인 실수는 Include 파일을 검색할 폴더에 절대 참조를 추가하는 것입니다.

권장되는 방법은 로컬 프로젝트 폴더에 대한 참조를 include path에 입력할 때, 상대 경로를 사용하는 것입니다.

Define relative include paths.

가장 일반적인 경우 CDT는 이러한 path를 적절히 처리하기 위해 빌드 과정이 어디에서 실행되어야 하는지 알만큼 충분히 똑똑합니다.

예를들어, 디폴트 Debug 또는 Release 폴더에서 빌드가 시작될 때, include 폴더에 대한 실제 path는

한단계 위이며, 자동적으로 접두사 “../“이 붙게 됩니다.

Use of relative include paths.

다른 해결책은 현재 프로젝트에 대한 상대 경로를 생성하기 위해 CDT predefined macros를 사용하는 것입니다. 이를 위해 ${ProjDirPath}를 이용합니다.

Use ProjDirPath for include paths.

또는 “${workspace_loc:/other_proj/libs/misc/include}””처럼 workspace안에 있는 어떤 프로젝트에 상대경로를 지정할 수 있습니다.

Linker script files

링커스크립트로 진입하기 위해 비슷한 솔루션을 고려할 수 있습니다. 권장되는 방법은 경로(path)를 사용하지 않고, 스크립트 이름을 사용하는 것입니다.

Add script files by simple names.

그리고, 그것들이 위치해 있는 폴더를 경로로 설정합니다. (usually named ldscripts).

Enter location for linker scripts.

include path와 마찬가지로, CDT는 이 definition을 빌드 폴더와 연관시킬 수 있을 만큼 똑똑합니다.

Relative linker scripts folder.

대체할만한 솔루션은 ${ProjDirPath} 또는 ${workspace_loc} 와 같은 상대경로를 사용하는 것입니다.

Library paths

또다른 중대한 실수 중 하나는 라이브러리를 검색하는데 사용될 링커 설정에서 절대 경로를 path로 사용하는 것입니다.

링커스크립트의 위치에 대한 정의는 위에서 설명한 것과 비슷합니다.

Definitions are similar to the ones explained above for the location of the linker scripts.

Debug launch configuration

이클립스 디버깅 시스템은 디버그 설정을 workspace 또는 각 프로젝트 안에 저장하도록 설정 될 수 있습니다.

각 프로젝트 안에 저장할 경우에는 GDB Server name이나 command line options 등과 같은 non-portable definitions를 사용하는 것을 피하도록 구성되어야 합니다.