ldc-developers / ldc

The LLVM-based D Compiler.
http://wiki.dlang.org/LDC
Other
1.21k stars 261 forks source link

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

Open denizzzka opened 2 months ago

denizzzka commented 2 months ago

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?

kinke commented 2 months ago

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

JohanEngelen commented 2 months ago

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?)

denizzzka commented 2 months ago

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