The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15223 ====================================================================== Reported By: Emmanuel Blot Assigned To: ====================================================================== Project: CMake Issue ID: 15223 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-28 17:07 CET Last Modified: 2014-10-28 17:07 CET ====================================================================== Summary: Object OUTPUT_EXTENSIONs selection is hard - if ever possible - to manage with cross compilation Description: For some (historical?) reasons, CMake considers the default object extension tas ".obj", which is quite unusual but on Windows.
CMake "Modules" files define: IF (UNIX) set(CMAKE_<LANG>_OUTPUT_EXTENSION .o) ELSE () set(CMAKE_<LANG>_OUTPUT_EXTENSION .obj) ENDIF () which makes the Unix style the exception, and Windows style the default rule. However, when cmake is used to cross compile, many (if not most) OSes use the Unix style, even if they are not Unix-based. The trouble is that UNIX variable seems to be mostly defined from the host environment, not from the target environment. The net result is that ".obj" extension is enforced for non-Windows targets, which in turn rapidly becomes a nightmare to manage. Forcing UNIX to 1 from a CMakeLists.txt sometimes helps for C source files - although it is definitely a hack - but does not with ASM files for example. Setting CMAKE_<LANG>_OUTPUT_EXTENSION from a CMakeLists.txt does not seem to be recommended - from previous CMake ML posts - and does not work anyway. Although I would personally favour .o to be the default extension and Windows the exception, I guess that for at least compatibility with previous CMake version this cannot be changed. However, being able to easily define the extension for a non Unix project, or for a cross compiled one is definitely a real need. Additional Information: I've failed - up to know - to find a way to choose the proper extension, which forced me to write ugly workaround in CMakeLists.txt files. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-28 17:07 Emmanuel Blot New Issue ====================================================================== -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
