Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

12.1 안에 있는 새 Clang 도구 체인을 가지고 일반적인 작업을 수행하는 방법


Recommended Posts

David Millington"How to achieve common tasks with the new Clang toolchain in 12.1" 을 번역했습니다. (원문 작성: 2024년 4월, 최종 번역: 2024년 4월)

새 Clang 도구 체인이 출시되었다! RAD 스튜디오 12.1과 C++빌더 12.1에는 완전히 새로 만들어지고 완전히 업데이트된 C++ 컴파일러, 링커, STL, 런타임 등이 제공된다. 또한 여러분은 예전 Win64 도구 체인도 병렬로 사용할 수 있기 때문에 쉽게 업그레이드할 수 있다. 이는 우리가 향후에 예전 레거시 도구 체인을 제거하기 전까지 그렇다. 

우리는 이것이 '버전 1' 릴리스이고 예전 도구 체인과 몇 가지 면에서 다르다는 것을 알고 있다. 그래서 특정 작업을 수행할 때 새 도구 체인을 사용하는 방법을 이 글에 정리해 두었다. 아직 존재하지 않지만 향후 릴리스에 제공될 기능들 그리고 현재 달성할 수 있지만 그 방법이 명확하지는 않은 것들이 이 글에 모두 포함된다. 추가 정보가 있으면 이 글을 업데이트하겠다.

차례


출시와 현황!

우리는 우리가 하고 있는 일들과 그 상태에 대해 공개해오고 있다. 그건 정말 좋았고 계속해서 그렇게 하길 바라고 있다! 주요 소통 내용들은 아래와 같다. 가장 최근부터 나열했다:

  • 2024년 2월: 웹 세미나, 12.1에 대한 Behind the Build – 가장 최근의 기술 개요이며 매우 주목할 가치가 있다.
    12.1 출시 웨비나에서는 12.1에 존재하는 것과 존재하지 않는 것에 대해 가볍게 요약한다. Behind the Build에서 이미 많은 세부 사항을 다루었기 때문이다. 이 블로그 글도 명확하게 설명한다.
  • 2023년 11월: Clang 프리뷰와 함께 12.0 출시
  • 2023년 9월: 12.0에 대한 Behind the Build
  • 2023년 3월: 블로그, 'C++빌더가 선보일 새로운 기능: 멋진 프리뷰를 확인해보세요!' – 이 글이 게시된 이후 일부 기술적 세부 사항들이 변경되었음을 참고하기 바란다. 하지만 우리의 목표들을 분명하게 볼 수 있을 것이다. 12.1에 담긴 것들의 최신 상태 정보를 파악하려면, 12.1 Behind the Build 시청을 권한다. 

12.1에서 출시된 것들에 대한 기술 정보를 파악하려면, 2024년 2월 Behind the Build를 시청하고 업그레이드 도움말 문서도 읽어 보기 바란다. 기술이 다르기 때문에 그리고 최초 출시이기 때문에, 기능들에 차이가 있다.
 

일반적인 작업들

빠른 컴파일

Bcc64x에는 아직 –jobs 파라미터가 없다. 이것은 여러 CPU들을 최대한 활용하기 위해 사용되는 파라미터다. 향후 제공 예정이다. TwineCompile을 사용할 것을 권한다. GetIt 구독 시 무료로 제공되고 있다. 우리는 베타 기간 동안 TwineCompile 개발자와 협력했으며, TwineCompile은 새 도구 체인을 지원한다.

새 Clang과 기존 Clang은 컴파일 성능이 매우 비슷하다. (주요 차이점은 링커인데, 새 Clang에서 훨씬 더 빠르다.) Clang 15는 Clang 5보다 더 많은 기능을 수행하지만 그럼에도 불구하고 성능은 매우 비슷하다. Xerces 라이브러리를 컴파일한 결과는 다음과 같다. 릴리스 모드에 컴파일 했으며 링크 시간을 포함한 결과다. 4코어 VM에 있는 파일 300개이다.

Xerces 릴리스 빌드(링크 시간 포함) – 파일 300개, 4코어 VM. 빌드 시간은 분:초 단위임.
구 Clang Win64컴파일(Twine 사용 안함) 2:13
새 Clang 64-bit Modern 컴파일(Twine 사용 안함) 2:18
구 Clang Win64, 컴파일(Twine 사용함) 00:38
새 Clang 64-bit Modern 컴파일(Twine 사용함) 00:41

대략 CPU 코어 수에 따라 컴파일 시간이 선형적으로 감소한다. 이 테스트에서는 코어가 4개이며 약 3.5배 더 빨랐다. 16 코어에서는 10~12배 더 빠르다고 볼 수 있다.
 

패키지

12.1에서, 새 Clang은 패키지 연결(linking)을 정적으로만 지원한다. 이것이 중요하다는 것을 우리는 알고 있다. 그리고 동적 연결은 다가오고 있다!

델파이 패키지들 대부분이 제공된다(Behind the Build의 22:16 지점 참조). 그것들은 .libs로 제공되며 여러분의 EXE 또는 DLL 안에 연결할 수 있다. (즉, 프로젝트를 빌드하기만 하면 된다. 자동으로 링크된다. C++빌더의 헤더들은 자동-링크를 사용하기 때문이다.)

일반적으로, 패키지는 아키텍처적으로 유용하다. 또한 기술적으로 유용한데, VCL의 복사본이 여러 개이면 문제가 발생할 수 있다는 점을 고려하면 그렇다 (예: DLL이 VCL을 사용하는 경우) 그 사실 역시 우리는 알고 있다. 그리고 동적 패키지를 소비할 수 있는 순간이 다가오고 있다. 우리가 집중한 것은 이번 릴리스에 담은 것들의 품질이다. 즉, 우리가 제공하는 것들의 상태가 최고가 되도록 했다. 그래서 정적 패키지가 제대로 작동하는지 확인하는 데 집중했다.

C++ 소스 패키지는 현재 정적 라이브러리로만 빌드가 가능하다. 그리고 이제  C++ 패키지용 BPL 파일 구축도 계획되어 있다.

 

CMake

새 도구 체인을 위한 CMake 지원은 12.1에 포함되지 않다. 주된 이유는 범위를 줄여서 타사 도구가 아닌 도구 체인 자체에 집중하기 위해서였다.

패키지와 마찬가지로, 이것 역시 다가오고 있다.

대규모 CMake 전용 소스 빌드를 테스트하기 위해 내부적으로 사용한 몇 가지 해킹이 있다. 하지만 안타깝게도 공유하기에 적합하지 않다. 공식적으로 CMake가 나올 때까지 기다려 주기 바란다.

 

임포트(Imports)

import64.lib에서 임포트 누락과 관련된 몇 가지 버그 리포트가 있었다. 우리는 이것을 조사하고 있다.

 

부스트(Boost)

12.1용 Boost를 GetIt에 출시했다. 이것은 클래식, Clang Win32, 예전 Clang Win64용이다. 새 도구 체인용 Boost는 현재 작업 중이다. 계속 지켜봐 주기 바란다.

 

소스 전처리하기 및 어셈블리로 컴파일하기

현재 IDE 안에서 어셈블리로 사전 처리하거나 컴파일하면 실패한다. 하지만, Build Outup 안에 보이는 명령 줄은 잘 작동한다. 그 이유는 이 명령들을 실행하는 msbuild의 타겟이 예전 도구 체인의 DLL 컴파일러를 실행하려고 하기 때문이다. 우회 해결책은 두 가지가 있다.

  1. (예를 들어) IDE 안에서 전처리를 시도한다. 그 명령줄을 복사한다. 임시 출력 파일 이름을 여러분이-선호하는-이름.i로 변경한다. 그리고 RAD 스튜디오 명령 프롬프트 안에서 실행한다. 이와 동일한 절차가 어셈블리로 컴파일하는 데에 적용된다.
  2. Codegear.Cpp.Targets 파일을 편집한다(참고: 먼저 백업을 해 두는게 좋다.) 그러면, IDE 안에서 명령들이 예상대로 실행된다.

<Target Name="__CLANGPreprocessCreate" DependsOnTargets="$(PreprocessDependsOnTargets);">
<PropertyGroup>
<CLANG_RunPreprocessor>true</CLANG_RunPreprocessor>
<CLANG_OutputFileName>$(PreprocessOutputFilename)</CLANG_OutputFileName>
<CLANG_EmitNativeObject>false</CLANG_EmitNativeObject>
<!-- Workaround for RS-68975. We must use cpp tools intead -->
<!-- !!! CHANGED -->
<RunBCCOutOfProcess Condition="'$(Platform)'=='$(cWin64xPlatform)'">true</RunBCCOutOfProcess>
<RunBCCOutOfProcess Condition="'$(Platform)'!='$(cWin64xPlatform)'">false</RunBCCOutOfProcess>
 
</PropertyGroup>
 
<ItemGroup>
<CppFiles Include="@(InputFile)"/>
</ItemGroup>
</Target>
 
<Target Name="CLANGPreprocess" DependsOnTargets="__CLANGPreprocessCreate;_CLANGCoreCompile"/>
 
<Target Name="__CLANGToAssemblyCreate" DependsOnTargets="$(ToAssemblyDependsOnTargets);">
<PropertyGroup>
<CLANG_EmitNativeAssembly>true</CLANG_EmitNativeAssembly>
<CLANG_OutputFileName>$(AssemblyOutputFilename)</CLANG_OutputFileName>
<CLANG_EmitNativeObject>false</CLANG_EmitNativeObject>
 
<!-- !!! ADDED -->
<RunBCCOutOfProcess Condition="'$(Platform)'=='$(cWin64xPlatform)'">true</RunBCCOutOfProcess>
<RunBCCOutOfProcess Condition="'$(Platform)'!='$(cWin64xPlatform)'">false</RunBCCOutOfProcess>
 
</PropertyGroup>
 
<ItemGroup>
<CppFiles Include="@(InputFile)"/>
</ItemGroup>
</Target>

 

DLL Import 라이브러리들을 생성하기

임의의 DLL을 가져오려면 임포트(import) 라이브러리가 필요하다. 우리 링커는 기존의 모든 COFF와 잘 작동되도록 되어 있다(여기에는 MSVC에서 사용할 수 있도록 하기 위해 써드-파티들이 DLL용으로 만든 임포트 라이브러리들도 포함된다.)

그러나, 여러분이 직접 생성해야 하는 경우, 먼저 DLL에 대한 정의(.def) 파일이 필요하다. 그렇게 하려면, LLVM-MinGW의 gendef.exe 파일을 사용하면 된다. 아직 우리 제품 안에 들어있지 않으므로 다운로드해야 한다. 다음은 써드-파티이며 우리가 확인하거나 바이러스를 검사하지 않았다. 하지만 공식 llvm-mingw 사이트에서는 Martin Storsjö의 github 릴리스를 권장한다. 한 가지 릴리스는 이것이다: https://github.com/mstorsjo/llvm-mingw/releases/tag/20220906 

gendef.exe의 복사본을 찾았다면, 실행한다:

gendef file.dll

그러면 file.def가 생성된다.

참고: 몇몇 사람들은 .def 파일의 파일 이름이 올바르지 않다는 것을 발견했다. .def 파일은 일반 텍스트이다. 여러분은 파일을 열어서 LIBRARY <dllname>.dll이 포함되어 있는지 확인할 수 있다. 여기서 <dllname>이 틀렸을 수 있다. 실제 DLL 이름이 아니라 "a"만 표시되어 있는 것을 우리가 본 적이 있기 때문이다.

그런 다음 새 링커를 사용하여 해당 임포트 라이브러리를 생성하면 된다(RAD 스튜디오의 명령 프롬프트에서 실행하거나 또는 일반 명령 프롬프트에서 rsvars.bat을 실행):

ld.lld.exe -m i386pep --out-implib file.lib file.def

(또는 LLVM 도구를 사용하여 llvm-dlltool.exe를 사용한다.)

이제 여러분의 DLL용 임포트 라이브러리가 생겼다. file.dll의 경우 file.lib 임포트 라이브러리를 가지게 된다.

DLL을 빌드할 때 DLL 임포트 라이브러리 생성하기

위와 똑같은 작업을 수행하고 싶은데, 타사 DLL이 아닌 자체 DLL에 대해 수행하고 싶은가? IDE는 빌드할 때 이 작업을 자동으로 수행한다. 하지만, 여러분이 명령줄에서 이 작업을 수행할 수도 있다:

bcc64x -tD -Xlinker --out-implib=dll.lib dll.cpp

또는

bcc64x -tD dll.cpp -Wl,--out-implib,dll.lib

두 변형 모두 DLL과 동시에 임포트 라이브러리를 생성한다.

 

C++ Win64 Modern용으로 델파이 컴포넌트/패키지를 빌드하기

패키지를 빌드할 때, 여러분은 예전 Win64 대상 플랫폼뿐만 아니라 새 Win64 대상 플랫폼에서도 사용할 수 있도록 해야 한다. 그렇게 하지 않으면, 고객이 프로젝트에서 Win64 Modern 대상 플랫폼을 사용할 때 그 컴포넌트들은 팔레트에서 회색으로 표시된다. (기술적 빌드하기 측면도 있다. 델파이의 경우 Win64가 하나만 있지만 C++의 경우 두 개가 있다. ELF와 COFF, 그리고 여러분은 COFF 정적 라이브러리 파일을 여러분의 패키지에게 제공해야 한다.) 그렇다면 컴포넌트들을 어떻게 업데이트하는가?

여러분의 패키지 안에서, Target Platforms를 마우스 오른쪽 버튼으로 클릭하고 Windows 64-bit와 Windows 64-bit (Modern)을 둘 다 추가한다. 이제 각 플랫폼으로 다시 빌드하면 여러분에게 필요한 출력 파일을 얻을 수 있다. 즉, bcc64x는 Windows 64-bit Modern 플랫폼용으로 빌드된 (정적) 패키지에 대해 링크할 수 있다.spacer.png

그러나, 그 패키지 역시 IDE 안에 설치되어야 한다. 그리고 IDE는 그 컴포넌트를 사용할 수 있는 플랫폼을 추적한다(예를 들어 Windows 전용 컴포넌트가 macOS 앱에서 사용되지 못하도록 하기 위해서다). 이제 두 Win64 플랫폼을 모두 추가했으니, Win32 디자인타임 패키지를 다시 빌드한다. 이것은 IDE 안에 설치되는 패키지이다. 그리고 그 패키지 안에 들어있는 컴포넌트들이 어느 플랫폼에서 사용될 수 있는지에 대한 정보가 들어있다. 이제, 여러분은 그 컴포넌트를 설치한다. 그리고 팔레트 안에 있는 그 컴포넌트 위로 마우스를 가져가면 Windows 64-bit Modern이 플랫폼으로 나열되는 것을 볼 수 있다.

여러분이 생성하고 있는 파일들은 다음과 같다.

  1. Win32: <package>.lib(정적 라이브러리로서의 패키지) 그리고 <package>.bpi(동적 패키지 임포트 라이브러리)
    1. Win32의 경우, 컴포넌트 패키지 하나는 두 개의 패키지로 분할되어야 한다.디자인 타임(IDE용, Win32 전용) 패키지와 런타임(앱용, 모든 플랫폼용, 즉 Win32, Win64 및 Win64 Modern) 패키지이다.
  2. Win64: <package>.a(정적 라이브러리로서의 패키지) 그리고 <package>.bpi(동적 패키지 가져오기 라이브러리)
  3. Win64X* / Windows 64-bit Modern: <package>.lib(정적 라이브러리로서의 패키지 - 향후 제공될 동적 패키지에 대해 위의 참고 사항 참조)

* 우리는 "x"를 이름에 자주 사용한다. 그 이유는 컴파일러 이름이 bcc64x이기 때문이다.

여러분은 두 가지를 달성했다.

  1. 여러분의 런타임 패키지에 Windows 64-bit Modern 플랫폼을 추가하고 앱을 빌드할 때 그 패키지 안에서 링크하는 데 필요로 하는 바이너리 파일들을 제공했다. 
  2. IDE에게 그 컴포넌트들이 Windows 64-bit modern에서 사용할 수 있다고 알려주었다: 프로젝트에 그 플랫폼을 추가한 후 디자인 타임 Win32 패키지를 다시 빌드하고 IDE에 다시 설치한다.
     

여러분이 좋아하는 것을 알려주세요!

새 도구 체인은 기반이 되는 릴리스이다. 미래를 위한 많은 것들과 우리가 미래에 할 수 있는 것들을 의미한다. 우리는 이것을 구축할 때 올바른 결정을 내리는 것을 목표로 삼았다: 여러분은 모든 곳에서 그 증거를 볼 수 있을 것이다. 플랫폼 규칙부터 C 런타임 선택, 64비트 바이너리, 품질 및 기능 범위에 대한 집중에 이르기까지 말이다.
 또한, 우리는 차이점을 최소화하고 기존 코드와의 호환성을 보장하기 위해 열심히 노력했다. 자세한 내용은 도움말 문서에 있다.

우리는 앞으로 이 도구 체인을 사용하여 우리가 출시하게 될 제품들을 만날 날을 기대하고 있다. 그리고 지금 여러분에게 얼마나 효과가 있을지 보고 싶다!
 

세이프 하버 선언문

논의된 모든 계획은 현재의 당사 의도를 나타낸다. 당사의 개발 계획 및 우선순위는 변경될 수 있다. 이는 경쟁 요인, 리소스 가용성, 독립 소프트웨어 공급업체들이 공통적으로 가지는 기타 공통된 문제 등의 영향을 받는다.   

따라서, 우리는 여기서 어떠한 약속이나 기타 형태의 보증도 제공하지 않는다. 설명된 제품 중 일부 또는 전부를 언급된 일정이나 순서에 맞게 제공한다는 약속이 아니다.  

개발 일정 대한 이러한 일반적인 표현 즉 "제품 로드맵"은 어떤 형태의 약속으로 해석되거나 추론되어서는 안 된다. 그리고 업그레이드, 업데이트, 개선 및 기타 유지 관리 릴리스에 대한 고객의 권리는 해당 소프트웨어 라이선스 계약 안에만 명시된다.

중요: 기능들은 완료되고 GA(일반 공급) 출시가 될 때까지 약속되지 않는다.

이 댓글 링크
다른 사이트에 공유하기

이 토의에 참여하세요

지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.

Guest
이 토픽(기고/질문)에 답하기

×   서식있는 텍스트로 붙여넣기.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   이전에 작성한 콘텐츠가 복원되었습니다..   편집창 비우기

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.