ldc-developers/ldc

Wish: accept *.obj on par with *.o for non-Windows targets

denizzzka opened this issue · 3 comments

At the moment, such targets strictly require files with .o extension

This leads to issues with CMake - CMake produces .obj files for non-Unix && non-Windows targets. As result, this forces to use in CMake scripts additional config file (it must be a separate file) in a such manner:

if(NOT "${TARGET_SYSTEM}" MATCHES "Windows")
    set(CMAKE_USER_MAKE_RULES_OVERRIDE_C "${CMAKE_CURRENT_SOURCE_DIR}/set_o_output_extension.cmake")
    set(CMAKE_USER_MAKE_RULES_OVERRIDE_ASM "${CMAKE_CURRENT_SOURCE_DIR}/set_o_output_extension.cmake")
endif()

set_o_output_extension.cmake:

set(CMAKE_C_OUTPUT_EXTENSION .o)
set(CMAKE_ASM_OUTPUT_EXTENSION .o)

Clang accepts both variants in this case.
Do we have any reason to stay on the existing scheme?

For linking? I assume you can just pass the object files as linker flags then - -LmyWeirdObject.obj.

Clang accepts both variants in this case. Do we have any reason to stay on the existing scheme?

Can you be more specific? What is "this" case?
Is whatever extensions clang accepts depending on the triple? (if so, for which triples do we need to change?)

For linking?

Yes

I assume you can just pass the object files as linker flags then - -LmyWeirdObject.obj.

CMake build system does this by different way.

(Actually, I am faced with this issue when building druntime for non-Linux && non-Windows target using runtime/CMakeLists.txt script)

Clang accepts both variants in this case. Do we have any reason to stay on the existing scheme?

Can you be more specific? What is "this" case?

Clang accepts object files for linking with name .obj on par with .o at least in case of unknown OS.

Is whatever extensions clang accepts depending on the triple? (if so, for which triples do we need to change?)

I came across the fact that for thumbv7em-unknown-none-eabi triple Clang accepts both variants (.o and .obj) and not fails CMake build, but ldc2 only accepts .o and this fails CMake build, because by default CMake generates .obj for non-Linux && non-Windows targets

Also, tested right now - when building for Linux Clang uses same approach