소스 구조 및 컴파일 이슈

아래 그림은 권장 소스 구조를 나타냅니다.

Support 폴더는 API Development Kit의 Inc, Lib, Modules and Tools 폴더를 포함하고 있습니다. (문서 없음) Attribute_Test 폴더는 애드온과 관련된 모든 파일들을 포함하고 있습니다. (DevKit Examples에 포함되어 있음) RFIX 폴더들은 언어-독립적인 리소스들을 포함하고 있습니다. (보통 GBMP, GICN, MDID, VERS) 그리고 적절한 RFIX/Images 폴더 안에 관련 이미지 파일들이 들어 있습니다. Src 폴더는 모든 소스 및 헤더 파일들과 기타 외부 공유 라이브러리/DLL들이 포함되어 있습니다.

Localizable 리소스들(다이얼로그, 문자열, 도움말 메시지 등)은 Rlang_code 폴더 안으로 가야 합니다. lang_code는 해당 언어에 대한 3 글자 약어입니다; Includes 폴더 안의 GSLocalization.h 헤더 파일에서 허용되는 변형 버전들을 찾을 수 있습니다. 선택적으로, 애드온이 필요로 하는 라이브러리 파트들 역시 .xml 파일 형태로 Rlang_code/Library 폴더 안으로 가야 합니다.

Make 폴더 (Make.win, Make.mac) 또는 애드온 폴더의 최상위 레벨 폴더는 적절한 IDE(통합 개발 환경, 예. Xcode, VS .NET)로부터 컴파일 할 수 있게 해주는 파일들을 포함하고 있어야 합니다. 만약 당신이 Graphisoft에 당신의 소스 코드를 공급할 경우, 개발자 지원 팀의 도움으로 .jam make file도 만들도록 하십시오. 이 제네릭 Make 폴더는 애드온을 필드하는 데 필요한 스크립트들도 포함할 수 있습니다.

DevKit은 이 구조를 만들도록 Support/Tools 폴더 안에 플랫폼 관련 폴더 안에 Windows 용으로는 Add-on Wizard를, Macintosh 용으로는 Xcode를 위한 프로젝트 템플릿을 넣어 두었습니다.

MergeNum.dat 파일은 개발 키트의 빌드 넘버를 포함하고 있습니다; 이것은 또한 'VERS' 리소스에도 들어갑니다. 이것은 Development Kit의 특정 버전의 문제들을 추적하는 데 도움을 줍니다.

비-표준 DLL 또는 공유 라이브러리들 역시 포함되어야 합니다. 보통 Src 안에 있거나 선택적으로 Lib 폴더 안에 있습니다.

애드온은 Specificator와 프로그래머 간의 긴밀한 작업의 결과이므로, Word 또는 일반 텍스트 포맷의 specification도 소스와 함께 제공되어야 합니다; 그것을 Doc 폴더에 넣습니다. 애드온의 기능과 일치해야 합니다; 따라서 애드온이 사양보다 더 많은 기능이 포함되어 있다면, 기능과 버그를 구별하기 위해 사양에 문서화되어야 합니다. 버전 내역을 저장하는 것은 항상 권장됩니다.

또한 애드온의 메인 파일의 이름은 Attribute_Test.c(pp), 메인 grc 파일은 Attribute_Test.grc, RFIX.win 및 RFIX.mac 폴더의 메인 파일은 각각 Attribute_Test.rc2 and Attribute_Test.r라고 하십시오. 'Attribute Test'라는 이름은 메인 메뉴 제목(도구 타입 애드온들의 경우)이나 내보내기/가져오기 애드온(I/O 타입 애드온들의 경우)의 이름과 같아야 합니다. 폴더 및 파일의 이름 안에는 공백 대신 밑줄(_) 문자를 넣어야 합니다. 예를 들면:

• API 이름/메뉴 문자열: Attribute Test
• 폴더 이름: Attribute_Test
• 메인 파일: Attribute_Test.cpp, Attribute_Test.grc, 등.

소스 코드는 사양에서 주어진 플랫폼에서 오류나 경고 없이 컴파일해야 합니다. 애드온을 컴파일하는 데 사용되는 컴파일러 및 헤더 버전도 설명하십시오. 컴파일러와 링커 경고를 하나씩 끄는 것이 좋습니다. 그렇게 하면 소스는 여전히 컴파일되고 링크될 수 있습니다.

플랫폼에 의존하는 부분은 소스에서 명확하게 분리되어야 합니다. (되도록이면 별도의 파일로, 또는 'Bridge' 디자인 패턴을 사용할 수 있음); 코드가 특정 플랫폼에 특화된 것이 아니라면 다른 플랫폼에 대한 비어 있는 함수 선언 및 정의도 제공되어야 합니다.

다른 사람이 코드를 디버깅해야 하는 경우처럼 소스 코드에 의미 있는 comments 넣는 것을 두려워하지 마십시오. C++를 그 정도까지 사용한다면 특히 그렇습니다. 외부 문서 생성 도구(doxygen 등)도 사용하여 comments 밖에서 소스 코드에 대한 설명을 작성할 수 있습니다.

프로그래머를 책임지는 사람은 또한 프로그래머가 이러한 가이드라인을 따르도록 유지해야 합니다. 만약 여기에 쓰여진 것과 다른 것이 있어야 한다면, 별도의 ReadMe 파일에 그것을 메모해 두십시오. 책임자는 프로그래머를 이용할 수 없거나 시간이 매우 짧을 경우, 코드의 버그를 수정해야 하는 수준으로 소스 코드에 익숙해져야 합니다.

모든 문서, comments, 변수, 함수 이름은 English로 작성되어야 합니다.

Specificator 또는 프로그래머는 애드온과 함께 사용할 ReadMe를 위한 작업 자료를 작성해야 합니다.