mirror of
https://github.com/OpenMW/openmw.git
synced 2026-02-04 22:28:25 +00:00
Apparently we'd never bothered opting in, despite nearly everything in all out apps being entirely compatible and designed with long paths in mind. GetModuleFileNameW is a bit awkward as it's just about the only Win32 function that returns the minimum of the buffer size and the string size - nearly everything else returns the full size even if it won't fit, so you can pass it a null pointer and a size of zero, and it'll tell you how much space you need to allocate. I pretty much just copied the mostly-working long-path-friendly call site in the crash catcher to windowspath.cpp, but I also noticed that if the function failed and returned zero, the original implementation would loop forever, so I fixed that. There was some code that could be ditched from the catch monitor as \\?\ is a prefix you can use to opt into long paths for a single API call instead of using the manifest to set it everywhere.
42 lines
793 B
CMake
42 lines
793 B
CMake
set(ESMTOOL
|
|
esmtool.cpp
|
|
labels.hpp
|
|
labels.cpp
|
|
record.hpp
|
|
record.cpp
|
|
arguments.hpp
|
|
tes4.hpp
|
|
tes4.cpp
|
|
)
|
|
source_group(apps\\esmtool FILES ${ESMTOOL})
|
|
|
|
# Main executable
|
|
openmw_add_executable(esmtool
|
|
${ESMTOOL}
|
|
)
|
|
|
|
target_link_libraries(esmtool
|
|
Boost::program_options
|
|
components
|
|
)
|
|
|
|
if (WIN32)
|
|
target_sources(esmtool PRIVATE ${CMAKE_SOURCE_DIR}/files/windows/other-apps.manifest)
|
|
endif()
|
|
|
|
if (BUILD_WITH_CODE_COVERAGE)
|
|
target_compile_options(esmtool PRIVATE --coverage)
|
|
target_link_libraries(esmtool gcov)
|
|
endif()
|
|
|
|
if (WIN32)
|
|
install(TARGETS esmtool RUNTIME DESTINATION ".")
|
|
endif()
|
|
|
|
if (MSVC AND PRECOMPILE_HEADERS_WITH_MSVC)
|
|
target_precompile_headers(esmtool PRIVATE
|
|
<fstream>
|
|
<string>
|
|
<vector>
|
|
)
|
|
endif()
|