-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Support shared builds of Chakra.ICU #4737
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,7 +9,8 @@ | |
| <ProjectName>Chakra.ICU.Stubdata</ProjectName> | ||
| </PropertyGroup> | ||
| <PropertyGroup Label="Configuration"> | ||
| <ConfigurationType>StaticLibrary</ConfigurationType> | ||
| <ConfigurationType Condition="'$(ChakraICU)'!='shared'">StaticLibrary</ConfigurationType> | ||
| <ConfigurationType Condition="'$(ChakraICU)'=='shared'">DynamicLibrary</ConfigurationType> | ||
| </PropertyGroup> | ||
| <Import Project="$(BuildConfigPropsPath)Chakra.Build.Default.props" /> | ||
| <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" /> | ||
|
|
@@ -31,6 +32,12 @@ | |
| $(IcuSourceDirectory)\common | ||
| </AdditionalIncludeDirectories> | ||
| </ClCompile> | ||
| <Link Condition="'$(ChakraICU)'=='shared'"> | ||
| <SubSystem>Console</SubSystem> | ||
| <!-- Make Chakra.ICU.Stubdata pretend like its Chakra.ICU.Data for linking purposes --> | ||
| <OutputFile>$(OutDir)\Chakra.ICU.Data.dll</OutputFile> | ||
| <ImportLibrary>$(OutDir)\Chakra.ICU.Data.lib</ImportLibrary> | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @curtisman is there any way around this? At runtime, we want Common.dll to auto-load Data.dll, but to create Data.dll we need Common. Thus, Stubdata is built and common links against Stubdata.lib... normally. Except then Common will try to auto-load Stubdata.dll rather than Data.dll, which isn't what we want. I couldn't find a way to work around this, and having the stubdata project output misnamed files like this is what stubdata.vcxproj in upstream ICU does. |
||
| </Link> | ||
| </ItemDefinitionGroup> | ||
| <ItemGroup Condition="'$(ChakraICU)'!='false'"> | ||
| <ClCompile Include="$(IcuStubdataSources)" /> | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,8 +8,6 @@ | |
| #ifdef WINDOWS10_ICU | ||
| #include <icu.h> | ||
| #else | ||
| #define U_STATIC_IMPLEMENTATION 1 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this not still needed if building non-shared? (I didn't see this added to CommonDefines.h or anywhere else)
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It looks like Chakra.Build.props sets the define, but I don't know if you build with both static and dynamic linking of ICU or not..?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We build with one or the other at any given time. So, the build files set this if ChakraICU=static now. |
||
| #define U_SHOW_CPLUSPLUS_API 0 | ||
| #include "unicode/ucal.h" | ||
| #include "unicode/ucol.h" | ||
| #include "unicode/udat.h" | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I missed this. Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that I expect conflicts on this define name, but this exposes this define to every compilation unit (as opposed to ICU-related-only), no?
In reply to: 170405597 [](ancestors = 170405597)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but I am of the opinion that it is much easier in the long run to not keep ICU integration points separate. While its theoretically possible that we will need to change globalization libraries yet again, in the meantime it is much nicer to be able to use the recycler/common data structures right next to ICU calls. So, in that sense, its good to make the entire codebase aware of ICU in this way.