On 06/04/16 20:32, Matthew Keeler wrote:
>
> I think I ran into a bug but I am wondering if anyone has seen it an worked
> around.
>
> I have a source structure like the following (this is a contrived small
> example to illustrate the problem):
>
> - CMakeLists.txt
> - main.c
> - lib
> - CMakeLists.txt
> - x.c
> - x.h
> - alt1
> - x.c
> - x.h
> - alt2
> - x.c
> - x.h
>
> CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.5)
> project(example)
> add_subdirectory(lib)
> include_directories(lib)
> add_executable(main main.c $<TARGET_OBJECTS:example>)
>
>
> main.c:
>
> #include "x.h"
>
> int main()
> {
> return example_func();
> }
>
> lib/CMakeLists.txt:
>
> option(ALT1 "ALT1" ON)
> option(ALT2 "ALT2" ON)
> set(SOURCES x.c)
> if ( ALT1 )
> add_definitions(-DALT1)
> list(APPEND SOURCES alt1/x.c)
> elseif ( ALT2 )
> add_definitions(-DALT2)
> list(APPEND SOURCES alt2/x.c)
> else ()
> message(FATAL_ERROR "No alt defined")
> endif()
> add_library(example OBJECT ${SOURCES})
>
> lib/x.h:
>
> #ifndef X_H
> #define X_H
> int example_func();
> #endif
>
> lib/x.c:
>
> #include "x.h"
> #ifdef ALT2
> #include "alt2/x.h"
> #else
> #include "alt1/x.h"
> #endif
> int example_func()
> {
> return call_example_func();
> }
>
>
> lib/alt1/x.h:
>
> #ifndef ALT1_X_H
> #define ALT1_X_H
> int alt1_example_func();
> #define call_example_func() alt1_example_func()
> #endif
>
>
> lib/alt1/x.c:
>
> int alt1_example_func()
> {
> return 1;
> }
>
> lib/alt2/x.h:
>
> #ifndef ALT2_X_H
> #define ALT2_X_H
> int alt2_example_func();
> #define call_example_func() alt2_example_func()
> #endif
>
>
> lib/alt2/x.c:
>
> int alt2_example_func()
> {
> return 2;
> }
>
>
>
> Now if I run cmake using the makefile generator and then run make, all is
> well and everything is built and runs as expected. If I use the Xcode
> generator I get the following errors:
>
> clang: error: no such file or directory: ‘<path to build
> directory>/lib/example.build/Debug/example.build/Objects-normal/x86_64/x.o’
>
> Within the directory <path to build
> directory>/lib/example.build/Debug/example.build/Objects-normal/x86_64 there
> is in fact no x.o. Instead there are two files, x-8171277E06B93FB2.o and
> x-FA155118579B6D7E.o. So it looks like for the XCode generators sources
> intermediate object files for a single CMakeLists.txt are stored within a
> single directory. And in this case the sources have the same name so the
> x-<id>.o names are used instead. However the $<TARGET_OBJECTS:…> generator
> expression seems to be referencing an incorrect name. Is there any workaround
> so that for the Xcode generator it will not store all the build artifacts in
> a single directory and not use the object file name with the unique id in it
> and secondly where is the proper place to file a bug for this.
Thank you for the minimal example. Please file a bug in the bug tracker.
Thanks,
Gregor
--
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
