View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008481CMakeCMakepublic2009-02-06 22:382009-09-24 09:32
ReporterEric Wing 
Assigned ToBrad King 
PriorityimmediateSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0008481: Xcode: Breakpoints are ignored in CMake generated projects in Xcode debugger
DescriptionI am using 2.6.2 and Xcode 3.1.2 (everything current as of today). Using the Xcode generator, the generated project seems to be ignoring all my breakpoints I set in the Xcode debugger.

I can reproduce easily by taking any CMake based project and generating an Xcode project. For example, if I take Tests/Simple in the CMake source, generate an Xcode project, set a break point in simple.cxx at FooBar(), and then hit Build &Go, the program loads up and finishes execution without stopping.

This is a very serious bug for me because I need the Xcode debugger to work correctly. In my current project, I am working on a Mac specific backend for a cross-platform framework so I cannot move to another OS to debug this stuff. And command-line GDB just isn't a reasonable option for me. (I am trying to evangelize the advantages to CMake to the company that owns this cross-platform framework for formal adoption, but this bug really makes CMake lose its appeal.


TagsNo tags attached.
Attached Filesgz file icon BreakPointBug.tar.gz [^] (54,219 bytes) 2009-02-09 17:11
patch file icon cmake-xcode-debug-fix.patch [^] (2,591 bytes) 2009-07-22 02:40 [Show Content]

 Relationships
related to 0007044closedBrad King Xcode 3 generator: "Select the directory to use as the project root." 

  Notes
(0014820)
Bill Hoffman (manager)
2009-02-07 12:00

Are you sure it is building with -g or some other debug flag? Can you look at the build logs.

From a clean binary tree, what is the output of this:
cmakexbuild
(0014821)
Bill Hoffman (manager)
2009-02-07 12:04

Does plain gdb work on the same executable?
(0014827)
Eric Wing (reporter)
2009-02-07 16:55

In response to your two questions:
1) Yes, -gdwarf-2 is being passed. (This is the standard debug flag now that Apple uses.) Log output of cmakexbuild below.

2) Yes, gdb works on the executable. My session history is also included below.


[ewing@iMacAL ~/Source/CVS/xcode_breakpoint]$ cmake -GXcode ../CMakeAuthorized/CMake/Tests/Simple/
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/ewing/Source/CVS/xcode_breakpoint
[ewing@iMacAL ~/Source/CVS/xcode_breakpoint]$ cmakexbuild
=== BUILDING NATIVE TARGET libsimpleLib.a OF PROJECT Simple WITH THE DEFAULT CONFIGURATION (Debug) ===

Checking Dependencies...

PhaseScriptExecution /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/libsimpleLib.a.build/Script-565A20565A20565A20000000.sh
    cd /Users/ewing/Source/CVS/xcode_breakpoint
    /bin/sh -c /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/libsimpleLib.a.build/Script-565A20565A20565A20000000.sh
make: `CMakeFiles/cmake.check_cache' is up to date.

CompileC Simple.build/Debug/libsimpleLib.a.build/Objects-normal/i386/simpleLib.o /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simpleLib.cxx normal i386 c++ com.apple.compilers.gcc.4_0
    cd /Users/ewing/Source/CVS/xcode_breakpoint
    /Developer/usr/bin/gcc-4.0 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -DCMAKE_INTDIR="Debug" -gdwarf-2 -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/Users/ewing/Source/CVS/xcode_breakpoint/Debug -I/Users/ewing/Source/CVS/xcode_breakpoint/Debug/include -I/Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/libsimpleLib.a.build/DerivedSources -c /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simpleLib.cxx -o /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/libsimpleLib.a.build/Objects-normal/i386/simpleLib.o

CompileC Simple.build/Debug/libsimpleLib.a.build/Objects-normal/i386/simpleCLib.o /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simpleCLib.c normal i386 c com.apple.compilers.gcc.4_0
    cd /Users/ewing/Source/CVS/xcode_breakpoint
    /Developer/usr/bin/gcc-4.0 -x c -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -DCMAKE_INTDIR="Debug" -gdwarf-2 -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/Users/ewing/Source/CVS/xcode_breakpoint/Debug -I/Users/ewing/Source/CVS/xcode_breakpoint/Debug/include -I/Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/libsimpleLib.a.build/DerivedSources -c /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simpleCLib.c -o /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/libsimpleLib.a.build/Objects-normal/i386/simpleCLib.o

CompileC Simple.build/Debug/libsimpleLib.a.build/Objects-normal/i386/simpleWe.o /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simpleWe.cpp normal i386 c++ com.apple.compilers.gcc.4_0
    cd /Users/ewing/Source/CVS/xcode_breakpoint
    /Developer/usr/bin/gcc-4.0 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -DCMAKE_INTDIR="Debug" -gdwarf-2 -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/Users/ewing/Source/CVS/xcode_breakpoint/Debug -I/Users/ewing/Source/CVS/xcode_breakpoint/Debug/include -I/Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/libsimpleLib.a.build/DerivedSources -c /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simpleWe.cpp -o /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/libsimpleLib.a.build/Objects-normal/i386/simpleWe.o

Libtool /Users/ewing/Source/CVS/xcode_breakpoint/Debug/libsimpleLib.a normal i386
    mkdir /Users/ewing/Source/CVS/xcode_breakpoint/Debug
    cd /Users/ewing/Source/CVS/xcode_breakpoint
    /Developer/usr/bin/libtool -static -arch_only i386 -L/Users/ewing/Source/CVS/xcode_breakpoint/Debug -filelist /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/libsimpleLib.a.build/Objects-normal/i386/simpleLib.LinkFileList -o /Users/ewing/Source/CVS/xcode_breakpoint/Debug/libsimpleLib.a

PhaseScriptExecution /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/libsimpleLib.a.build/Script-5660F05660F05660F0000000.sh
    cd /Users/ewing/Source/CVS/xcode_breakpoint
    /bin/sh -c /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/libsimpleLib.a.build/Script-5660F05660F05660F0000000.sh
echo "Depend check for xcode"
Depend check for xcode
cd /Users/ewing/Source/CVS/xcode_breakpoint && make -C /Users/ewing/Source/CVS/xcode_breakpoint -f /Users/ewing/Source/CVS/xcode_breakpoint/CMakeScripts/XCODE_DEPEND_HELPER.make all.Debug
/bin/rm -f /Users/ewing/Source/CVS/xcode_breakpoint/Debug/Simple


=== BUILDING NATIVE TARGET Simple OF PROJECT Simple WITH THE DEFAULT CONFIGURATION (Debug) ===

Checking Dependencies...

PhaseScriptExecution /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/Simple.build/Script-55A82055A82055A820000000.sh
    cd /Users/ewing/Source/CVS/xcode_breakpoint
    /bin/sh -c /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/Simple.build/Script-55A82055A82055A820000000.sh
make: `CMakeFiles/cmake.check_cache' is up to date.

CompileC Simple.build/Debug/Simple.build/Objects-normal/i386/simple.o /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simple.cxx normal i386 c++ com.apple.compilers.gcc.4_0
    cd /Users/ewing/Source/CVS/xcode_breakpoint
    /Developer/usr/bin/gcc-4.0 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -mdynamic-no-pic -DCMAKE_INTDIR="Debug" -gdwarf-2 -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/Users/ewing/Source/CVS/xcode_breakpoint/Debug -I/Users/ewing/Source/CVS/xcode_breakpoint/Debug/include -I/Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/Simple.build/DerivedSources -c /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simple.cxx -o /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/Simple.build/Objects-normal/i386/simple.o

Ld /Users/ewing/Source/CVS/xcode_breakpoint/Debug/Simple normal i386
    cd /Users/ewing/Source/CVS/xcode_breakpoint
    /Developer/usr/bin/g++-4.0 -arch i386 -L/Users/ewing/Source/CVS/xcode_breakpoint/Debug -F/Users/ewing/Source/CVS/xcode_breakpoint/Debug -filelist /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/Simple.build/Objects-normal/i386/Simple.LinkFileList -Wl,-search_paths_first -headerpad_max_install_names /Users/ewing/Source/CVS/xcode_breakpoint/Debug/libsimpleLib.a -o /Users/ewing/Source/CVS/xcode_breakpoint/Debug/Simple

PhaseScriptExecution /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/Simple.build/Script-55AF2055AF2055AF20000000.sh
    cd /Users/ewing/Source/CVS/xcode_breakpoint
    /bin/sh -c /Users/ewing/Source/CVS/xcode_breakpoint/Simple.build/Debug/Simple.build/Script-55AF2055AF2055AF20000000.sh
echo "Depend check for xcode"
Depend check for xcode
cd /Users/ewing/Source/CVS/xcode_breakpoint && make -C /Users/ewing/Source/CVS/xcode_breakpoint -f /Users/ewing/Source/CVS/xcode_breakpoint/CMakeScripts/XCODE_DEPEND_HELPER.make all.Debug
make[1]: Nothing to be done for `all.Debug'.


=== BUILDING AGGREGATE TARGET ALL_BUILD OF PROJECT Simple WITH THE DEFAULT CONFIGURATION (Debug) ===

Checking Dependencies...

PhaseScriptExecution /Users/ewing/Source/CVS/xcode_breakpoint/build/Simple.build/Debug/ALL_BUILD.build/Script-552E60552E60552E60000000.sh
    cd /Users/ewing/Source/CVS/xcode_breakpoint
    /bin/sh -c /Users/ewing/Source/CVS/xcode_breakpoint/build/Simple.build/Debug/ALL_BUILD.build/Script-552E60552E60552E60000000.sh
make: `CMakeFiles/cmake.check_cache' is up to date.

PhaseScriptExecution /Users/ewing/Source/CVS/xcode_breakpoint/build/Simple.build/Debug/ALL_BUILD.build/Script-553570553570553570000000.sh
    cd /Users/ewing/Source/CVS/xcode_breakpoint
    /bin/sh -c /Users/ewing/Source/CVS/xcode_breakpoint/build/Simple.build/Debug/ALL_BUILD.build/Script-553570553570553570000000.sh
echo

echo Build\ all\ projects
Build all projects
** BUILD SUCCEEDED **
[ewing@iMacAL ~/Source/CVS/xcode_breakpoint]$ ls
CMakeCache.txt Debug/ build/
CMakeFiles/ Simple.build/ cmake_install.cmake
CMakeScripts/ Simple.xcodeproj/
[ewing@iMacAL ~/Source/CVS/xcode_breakpoint]$ cd Debug/
[ewing@iMacAL ~/Source/CVS/xcode_breakpoint/Debug]$ ls
Simple* libsimpleLib.a
[ewing@iMacAL ~/Source/CVS/xcode_breakpoint/Debug]$ ./Simple
Count: 0/10
Count: 1/10
Count: 2/10
Count: 3/10
Count: 4/10
Count: 5/10
Count: 6/10
Count: 7/10
Count: 8/10
Count: 9/10
This one has nonstandard extension
[ewing@iMacAL ~/Source/CVS/xcode_breakpoint/Debug]$ gdb Simple
GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries .... done

(gdb) l
1 extern void simpleLib();
2 extern "C" int FooBar();
3 extern int bar();
4 extern int bar1();
5 int main ()
6 {
7 FooBar();
8 bar();
9 simpleLib();
10 return 0;
(gdb) b 7
Breakpoint 1 at 0x2e64: file /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simple.cxx, line 7.
(gdb) r
Starting program: /Users/ewing/Source/CVS/xcode_breakpoint/Debug/Simple
Reading symbols for shared libraries +++. done

Breakpoint 1, main () at /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simple.cxx:7
7 FooBar();
(gdb) bt
#0 main () at /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simple.cxx:7
(gdb) s
FooBar () at /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simpleCLib.c:6
6 int private = 10;
(gdb) bt
#0 FooBar () at /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simpleCLib.c:6
#1 0x00002e69 in main () at /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simple.cxx:7
Current language: auto; currently c
(gdb) l
1 #include <stdio.h>
2
3 int FooBar()
4 {
5 int class;
6 int private = 10;
7 for ( class = 0; class < private; class ++ )
8 {
9 printf("Count: %d/%d\n", class, private);
10 }
(gdb) s
7 for ( class = 0; class < private; class ++ )
(gdb) s
9 printf("Count: %d/%d\n", class, private);
(gdb) s
Count: 0/10
7 for ( class = 0; class < private; class ++ )
(gdb) p class
$1 = 0
(gdb) s
9 printf("Count: %d/%d\n", class, private);
(gdb) s
Count: 1/10
7 for ( class = 0; class < private; class ++ )
(gdb) s
9 printf("Count: %d/%d\n", class, private);
(gdb) s
Count: 2/10
7 for ( class = 0; class < private; class ++ )
(gdb) s
9 printf("Count: %d/%d\n", class, private);
(gdb) p class
$2 = 3
(gdb) p private
$3 = 10
(gdb) n
Count: 3/10
7 for ( class = 0; class < private; class ++ )
(gdb) n
9 printf("Count: %d/%d\n", class, private);
(gdb) n
Count: 4/10
7 for ( class = 0; class < private; class ++ )
(gdb) n
9 printf("Count: %d/%d\n", class, private);
(gdb) n
Count: 5/10
7 for ( class = 0; class < private; class ++ )
(gdb) n
9 printf("Count: %d/%d\n", class, private);
(gdb) n
Count: 6/10
7 for ( class = 0; class < private; class ++ )
(gdb) n
9 printf("Count: %d/%d\n", class, private);
(gdb) n
Count: 7/10
7 for ( class = 0; class < private; class ++ )
(gdb) n
9 printf("Count: %d/%d\n", class, private);
(gdb) n
Count: 8/10
7 for ( class = 0; class < private; class ++ )
(gdb) bt
#0 FooBar () at /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simpleCLib.c:7
#1 0x00002e69 in main () at /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simple.cxx:7
(gdb) n
9 printf("Count: %d/%d\n", class, private);
(gdb) n
Count: 9/10
7 for ( class = 0; class < private; class ++ )
(gdb) n
11 return 0;
(gdb) n
12 }
(gdb) n
main () at /Users/ewing/Source/CVS/CMakeAuthorized/CMake/Tests/Simple/simple.cxx:8
8 bar();
(gdb) n
Current language: auto; currently c++
This one has nonstandard extension
9 simpleLib();
(gdb) n
10 return 0;
(gdb) n
11 }
(gdb) n
0x00002e32 in start ()
(gdb) n
Single stepping until exit from function start,
which has no line number information.
0x0000404a in dyld_stub_exit ()
(gdb) n
Single stepping until exit from function dyld_stub_exit,
which has no line number information.
0x8fe18be0 in __dyld_fast_stub_binding_helper_interface ()
(gdb) n
Single stepping until exit from function __dyld_fast_stub_binding_helper_interface,
which has no line number information.
0x8fe18be2 in __dyld_stub_binding_helper_interface ()
(gdb) n
Single stepping until exit from function __dyld_stub_binding_helper_interface,
which has no line number information.
0x8fe18c02 in __dyld_misaligned_stack_error ()
(gdb) n
Single stepping until exit from function __dyld_misaligned_stack_error,
which has no line number information.
0x8fe18c1a in __dyld_stub_binding_helper_interface2 ()
(gdb) n
Single stepping until exit from function __dyld_stub_binding_helper_interface2,
which has no line number information.
0x8fe06e40 in __dyld__ZN4dyld14bindLazySymbolEPK11mach_headerPm ()
(gdb) n
Single stepping until exit from function __dyld__ZN4dyld14bindLazySymbolEPK11mach_headerPm,
which has no line number information.
0x8fe0e4f0 in __dyld__ZNK11ImageLoader15containsAddressEPKv ()
(gdb) n
Single stepping until exit from function __dyld__ZNK11ImageLoader15containsAddressEPKv,
which has no line number information.
0x8fe13310 in __dyld__ZNK16ImageLoaderMachO13beginSegmentsEv ()
(gdb) n
Single stepping until exit from function __dyld__ZNK16ImageLoaderMachO13beginSegmentsEv,
which has no line number information.
0x8fe0e517 in __dyld__ZNK11ImageLoader15containsAddressEPKv ()
(gdb) n
Single stepping until exit from function __dyld__ZNK11ImageLoader15containsAddressEPKv,
which has no line number information.
0x8fe06f22 in __dyld__ZN4dyld14bindLazySymbolEPK11mach_headerPm ()
(gdb) n
Single stepping until exit from function __dyld__ZN4dyld14bindLazySymbolEPK11mach_headerPm,
which has no line number information.
0x8fe18c2f in __dyld_stub_binding_helper_interface2 ()
(gdb) c
Continuing.

Program exited normally.
(gdb) quit
(0014828)
Eric Wing (reporter)
2009-02-07 16:59

I also just tried enabling Fix & Continue which shouldn't be necessary. The setting did not help.
(0014829)
Eric Wing (reporter)
2009-02-07 17:02

For contrast, here is a natively created Xcode project output (copied from the build window). Breakpoints work here. It was quick and dirty as I didn't bother making separate library and executable targets, but I have other projects that do that and that works fine.

Building target “Simple” of project “Simple” with configuration “Debug”


Checking Dependencies

CompileC build/Simple.build/Debug/Simple.build/Objects-normal/i386/simple.o /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/../../CMakeAuthorized/CMake/Tests/Simple/simple.cxx normal i386 c++ com.apple.compilers.gcc.4_0
    cd /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple
    /Developer/usr/bin/gcc-4.0 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue -fvisibility-inlines-hidden -mmacosx-version-min=10.5 -gdwarf-2 -iquote /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-generated-files.hmap -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-own-target-headers.hmap -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-all-target-headers.hmap -iquote /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-project-headers.hmap -F/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug/include -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/DerivedSources -c /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/../../CMakeAuthorized/CMake/Tests/Simple/simple.cxx -o /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Objects-normal/i386/simple.o

CompileC build/Simple.build/Debug/Simple.build/Objects-normal/i386/simpleCLib.o /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/../../CMakeAuthorized/CMake/Tests/Simple/simpleCLib.c normal i386 c com.apple.compilers.gcc.4_0
    cd /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple
    /Developer/usr/bin/gcc-4.0 -x c -arch i386 -fmessage-length=0 -pipe -std=c99 -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue -mmacosx-version-min=10.5 -gdwarf-2 -iquote /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-generated-files.hmap -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-own-target-headers.hmap -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-all-target-headers.hmap -iquote /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-project-headers.hmap -F/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug/include -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/DerivedSources -c /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/../../CMakeAuthorized/CMake/Tests/Simple/simpleCLib.c -o /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Objects-normal/i386/simpleCLib.o

CompileC build/Simple.build/Debug/Simple.build/Objects-normal/i386/simpleLib.o /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/../../CMakeAuthorized/CMake/Tests/Simple/simpleLib.cxx normal i386 c++ com.apple.compilers.gcc.4_0
    cd /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple
    /Developer/usr/bin/gcc-4.0 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue -fvisibility-inlines-hidden -mmacosx-version-min=10.5 -gdwarf-2 -iquote /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-generated-files.hmap -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-own-target-headers.hmap -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-all-target-headers.hmap -iquote /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-project-headers.hmap -F/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug/include -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/DerivedSources -c /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/../../CMakeAuthorized/CMake/Tests/Simple/simpleLib.cxx -o /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Objects-normal/i386/simpleLib.o

CompileC build/Simple.build/Debug/Simple.build/Objects-normal/i386/simpleWe.o /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/../../CMakeAuthorized/CMake/Tests/Simple/simpleWe.cpp normal i386 c++ com.apple.compilers.gcc.4_0
    cd /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple
    /Developer/usr/bin/gcc-4.0 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue -fvisibility-inlines-hidden -mmacosx-version-min=10.5 -gdwarf-2 -iquote /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-generated-files.hmap -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-own-target-headers.hmap -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-all-target-headers.hmap -iquote /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Simple-project-headers.hmap -F/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug/include -I/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/DerivedSources -c /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/../../CMakeAuthorized/CMake/Tests/Simple/simpleWe.cpp -o /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Objects-normal/i386/simpleWe.o

Ld /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug/Simple normal i386
    mkdir /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug
    cd /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple
    setenv MACOSX_DEPLOYMENT_TARGET 10.5
    /Developer/usr/bin/g++-4.0 -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -L/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug -F/Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug -filelist /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Simple.build/Debug/Simple.build/Objects-normal/i386/Simple.LinkFileList -mmacosx-version-min=10.5 -o /Users/ewing/Source/CVS/nativexcode_breakpoint/Simple/build/Debug/Simple
(0014830)
Bill Hoffman (manager)
2009-02-07 17:17

OK, can you see anything different about the two of them? So, to be clear gdb from the command line works fine, but the debugger in Xcode does not work right? If gdb works fine, then the debug info must be there. So, it must be something wrong with the xcode project itself... Maybe the project root thing, I can not seem to find the issue, but I seem to remember something about the project root not being quite right.
(0014832)
Eric Wing (reporter)
2009-02-07 17:31

Yes, I believe you understand the issue correctly. I believe the problem is with the Xcode project itself and not the building of the executable.
(0014833)
Bill Hoffman (manager)
2009-02-07 17:38

I am open to ideas? If you could make the simplest version of a project that works and one that does not and then start to make changes and see what is the problem that would help. One thing you might want to try is copy an executable from a cmake build into an xcode project and see if it debugs that way, that will rule out compile flags as the issue.
(0014834)
Eric Wing (reporter)
2009-02-07 17:43

Very good call on the project root. I think you nailed it.

In the CMake generated project, the Info panel shows an absolute path appended to a grayed out <Project File Directory>. The absolute path points to the location of where the root CMakeLists.txt was located (in the source directory.)

In the Xcode native project, the default is a grayed out <Project File Directory>. If I try to change it, I am only allowed to pick it or directories that descend deeper or parents directories only. I cannot select sibling directories. (So out-of-source building will prevent me from pointing directly to the source code if the source directory is a sibling.) Changing this path always is rooted from <Project File Directory>. So if I pick the parent directory, it reads "<Project File Directory>/..".


If I go back to the CMake generated project and change the Project Root to something valid, i.e. where the Xcode generated project is (which is considered <Project File Directory>, the debugger seems to work again.

So I think it is probably illegal to:
1) Use absolute paths (because Xcode is appending it to <Project File Directory>
2) Point to the source directory (for out of source builds)
(0014835)
Bill Hoffman (manager)
2009-02-07 18:12

Can you try the patch in this bug: 0008313? It might solve the problem...
(0014852)
Eric Wing (reporter)
2009-02-09 15:43

So bad news to report. The patch didn't seem to fix the initial Root Directory. It still reads as before with and absolute path appended to <Project File Directory>.

And I have further bad news to report. My simple tests no longer get the breakpoint working again by changing the Root Directory manually, even with a CMake without the patch. I am trying to understand why.

There are several differences between the working breakpoint project I had Sunday and now.
1) I was on my personal Intel iMac which had an older CVS version of CMake. (Maybe from August/September?) I am currently testing on a foreign machine that has Sunday's CVS and standard 2.6.2 release installed. I am trying to reproduce on my personal PowerPC Powerbook which also has a stale CVS, but so far, no-go. But there are a few more permutations I need to try which I just remembered.

2) I forgot which project I tested. But I'm wondering if I tested a project that set the CMAKE_*_OUTPUT_DIRECTORY to build. I discovered a different bug last week (which I probably need to separately file) where if you don't put all the build products in the same directory (particularly dynamic libraries and executables), Xcode is unable to launch them if you specify the install_name to be set at build time. Xcode has magic to deal with install_names that are set when things are not yet installed to the correct places, but apparently, it only works if all the components are in the same build directory.


This also leads me to think part of the problem might be that CMake needs to respect Xcode's settings for "Place Build Products In:" and "Place Intermediate Build Files In:". I'm wondering if the project I tested that worked happened to have all of these things happen to line up just perfectly with CMake so no problem existed.
(0014854)
Eric Wing (reporter)
2009-02-09 17:02

For the record, I just tried two things to rule out the underlying executables. I created a CMake generated executable (via Xcode generator) and a Xcode generated executable (via native Xcode).

I asserted the native Xcode project was able to use breakpoints, while the CMake generated Xcode project ignored them.

I then swapped the built executables.

1) Copying the CMake generated executable over the Native Xcode's generated executable, my Native Xcode project continued to be able to use breakpoints.

2) Copying the native Xcode executable over the CMake generated executable, the CMake Xcode project continued to ignore breakpoints.

I believe this confirms that the Generated Xcode project itself is the problem and not the build options on the binary.
(0014855)
Eric Wing (reporter)
2009-02-09 17:12

I just attached my test project/files. It includes both CMake and generated.
(0014856)
Eric Wing (reporter)
2009-02-09 17:35

I just found something weird, but maybe promising.

Using the attached project, using the CMake generated project, if I bring up the Info inspector on the individual file, main.c, and then change the "Path Type" to anything (doesn't matter what as long as I change it), then the breakpoints start working.

But if I close the project and reopen it again (without regenerating), the breakpoints don't work again, and I must change the "Path Type" again to get it to work. The Path Type remembers the value I last set, so it is not the value itself that is significant, but the act of merely changing the value.

(So for example, when I first generate, it is set to Absolute Path. I change it to Relative to Enclosing Group. Breakpoints work. I close the project, reopen, and it remembers Relative to Enclosing Group, but breakpoints no longer work. I change back to Absolute Path and breakpoints resume working.

I'm not sure what this really implies though. Ideas?
(0014857)
Eric Wing (reporter)
2009-02-09 17:38

Note that in the last example I did not change the Project Root in the last test and it was still using the invalid <Project File Directory>/some/absolute/path.
(0014858)
Eric Wing (reporter)
2009-02-09 17:42

I decided to try generating using (CMake option) Relative Paths instead. It didn't seem to help.
(0014859)
Eric Wing (reporter)
2009-02-09 17:50

Quick note about the "Relative Paths". I looked at the generated project. It still is using absolute paths inside the .pbxproj and the info inspector still says "Absolute Path". I assume that means the Relative Paths option is not working with the Xcode generator.
(0014860)
Eric Wing (reporter)
2009-02-09 17:52

Since I know you are going to ask, I changed the Native Xcode project to use Absolute Path for the main.c file, closed the project and reopened. The native project continues to work with breakpoints.
(0014861)
Bill Hoffman (manager)
2009-02-09 18:30
edited on: 2009-02-09 18:32

OK, the relative path thing is mostly broken everywhere, and should be NOT be used.

I am still confused about what works and what does not at this point. I would really like it if you could do this:

1. generate a very simple CMake Xcode project
2. edit the generated project file in such a way that the break points start to work.
3. Post both the broken CMake generated original project and the working edited project.

If you can do that, I can most likely fix the problem.

(0014862)
Eric Wing (reporter)
2009-02-09 18:37

So the problem so far is I can't 'save' a working generated Xcode project. The situation is:

1) I generate an Xcode project and open it.
2) I set a breakpoint. (Breakpoint won't work.)
3) I change a specific file's "Path Type" to something different.
4) Breakpoint works.
5) Close project.
6) Reopen project, and must repeat step 3.
(0014863)
Mike Jackson (reporter)
2009-02-09 20:24

Try going to the Xcode Preferences -> Debugging -> Load Symbols Lazily and turn that OFF. I had the same "yellow break point" issue, flipped that setting and the debugger started working.

Here is a relevant post from the Xcode mailing list:

http://lists.apple.com/archives/Xcode-users/2008/Dec/msg00057.html [^]

Bill and Eric, give that setting a try and see what happens.

Mike Jackson
(0014864)
Bill Hoffman (manager)
2009-02-09 21:19

It should just work Mike, there is obviously something wrong with the cmake generated Xcode project file. Eric, you just have not found the right fix yet. My guess is changing the path type is not the fix, it just somehow registers the file with the running Xcode and allows the break to be set. There must be some other setting, project root, or such that causes the problem.
(0014865)
Mike Jackson (reporter)
2009-02-09 21:27

The Xcode project I tried _was_ cmake generated. At first break points did NOT work. I then changed the "load symbols lazily" to "OFF" (unchecked) and the Xcode project now correctly honored the break point setting.

 Eric, can you try this also?

Mike
(0014866)
Bill Hoffman (manager)
2009-02-09 21:35

Sure, but Eric said that if he creates a project via Xcode, there is no problem at all even with the same simple C code project. So, there must be something wrong...
(0014867)
Mike Jackson (reporter)
2009-02-09 21:36

I downloaded the sample project attached to this bug report. I used a recent cvs checkout of CMake to create an Xcode project from the "Simple" folder Project by the following:

cd Simple
mkdir xcode
cd xcode
CMake -G "Xcode" ../
open simple.xcodeproj

Xcode opened the project. I set a break point in "main" and tried to debug. The debugger did NOT stop at the break point. The break point turned "Yellow" at that point.

I then went to the preferences for Xcode -> Debugging-> Load Symbols Lazily and "Unchecked" that setting. I then completely quit xcode. I then re-opened the simple.xcodeproj project and started the debugger again. The debugger now stopped at the break point that I had set in my last session.

Does that clear up what I did to reproduce this issue?

Which I don't think is an issue that CMake can "fix". It is going to be up to the user to keep that preference set correctly. What we might want to do is post something to the wiki and mailing list so that others (google) can gain from this.

Mike
(0014868)
Mike Jackson (reporter)
2009-02-09 21:40

From reading the link that I provided it would seem that there are times when even Xcode has a problem figuring out what goes where. This would seem to indicate an Xcode issue and not a CMake issue. What is the key now is to figure out how CMake can minimize when Xcode has its problems. So maybe there is an issue with how the Xcode projects are generated but there is a workable solution to the problem by adjusting the setting in the Xcode preferences.

Mike
(0014869)
Bill Hoffman (manager)
2009-02-09 21:43

Eric claims:
1. create a project from the Xcode gui that has the same code, and break points work.

2. use cmake to create a project with the same code
  - break points do not work.


Eric fixed it by toggling a file type.
Mike fixed it by changing to non-lazy symbols (sounds like a bad thing for a big project, very sloooow).

The point is nothing needed to be done for the native Xcode project, so I still thing there might be something CMake could do that would fix the problem.
(0014870)
Eric Wing (reporter)
2009-02-09 21:46

Mike: Unchecking the option did seem to fix the issue. But since the native project has no problem checked or unchecked, it seems reasonable to assume there is something wrong with the CMake generation. But at least for now, I have a work-around. Thank you very much Mike.

Bill: I am trying lots of things, but I can't figure out what it is. I've changed compiler types, SDKs, Xcode version numbers, Project Root, debugging flags, output directory paths, and so forth. I've started hacking the direct XML in the project file, but the CMake generated output is so different from my handcrafted project, it is hard to intelligently try things. I've tried manually setting relative paths and changed blocks of compiler options to match the handcrafted file, but so far it hasn't seemed to help (and sometimes it crashes).

I'm wondering if the original Project Root 'fix' from Saturday just happened to be a coincidence with me changing a file's "Path Type" somewhere. I will test that system again later tonight. But I am running out of ideas.
(0014871)
Bill Hoffman (manager)
2009-02-09 22:02
edited on: 2009-02-09 22:03

The fun of reverse engineering.... You have to take the cmake generated file and simplify it as much as possible. Try loading it into Xcode, remove all the extra targets, save it, make sure the problem is still there, and then start to hack the xml file. I would not worry about SDK's or compilers, it is most likely some very simple thing in the xml file...

(0014872)
Mike Jackson (reporter)
2009-02-09 22:10

Ding. We have a winner.

Create the CMake Build Directory inside the Project directory like so:

cd Simple
mkdir xcode
cd xcode
CMake -G "Xcode" ../
emacs simple.xcodeproj/project.pbxproj

Change the Project Root to the following:
projectRoot = /..;

Save the file.
Open the project in Xcode like normal.
Double check that "Load Symbols Lazily" is ON for this test.
Set a break point
Start debugger.
Debugger stops at break point.

The issue is that the Project root is _relative_ to the directory in which the project file lives. I don't think that can change. CMake is setting the project root as an absolute path which wont work based on how Xcode interprets the "projectroot" setting. If Xcode can not find the project root Xcode will not know what files belong to what target, like in the posting I quoted above.

Eric,
  Please try this fix on your end to see if that simple fix works for you.
(0014873)
Mike Jackson (reporter)
2009-02-09 22:17

I also tried an out of source build to reproduce this issue and I can 100% reproduce it.

Have CMake create the Xcode project file
Open, set a break point and see that Xcode ignores the break point.
Close the Xcode project.
Edit the project.pbxproj file in a text editor and set the "projectRoot" entry to a relative path, save file.
Open The Xcode project and try to debug. Xcode now will stop at the break point.

Close the project.
Edit the project.pbxproj file again putting the "projectRoot" back to the way CMake had it. Save file
Open and try debugging. See how Xcode ignores the break point.

At least it works for me with 10.5.6, Xcode 3.1.2 running on Intel hardware.

Mike
(0014876)
Bill Hoffman (manager)
2009-02-09 23:20

Thanks Mike, sounds like a fix. One more thing, what if the projectroot is empty does that work?
(0014878)
Eric Wing (reporter)
2009-02-10 03:29

Mike, thanks greatlyfor trying this. I'm pretty frustrated by this. So when I test it on a new Mac Pro (new as of last week), your fix isn't working for me. It is using the latest Xcode (the one with the iPhone 2.2.1 firmware that just came out), and CMake 2.6.2 (current stable).

But your fix sounds similar to the fix that was working on my Intel iMac this past Saturday. I will try to reproduce you steps on that machine when I get back to it. As mentioned earlier above, that one is running a stale CVS CMake (2.7 circa August) and the Xcode is tied to the iPhone 2.2.0 firmware.
(0014879)
Eric Wing (reporter)
2009-02-10 08:03

Mike, I tried my iMac again, against this test specific test case but I can't reproduce it on my machine. I believe you when you say it works because this past Saturday it worked for me, but I can't seem to reproduce that either.

Out of curiosity, does changing the Project Root in the Project Inspector (choosing a directory) have the same effect as hacking the project file directly?

What CMake version are you running? Do you compile it yourself, or download the package, or use something like Macports or Fink? Are you using gcc 4.2 or LLVM?
(0014880)
Mike Jackson (reporter)
2009-02-10 09:17

Yes, if you change the project root via the Project Inspector to a directory it will have the same effect as hacking the project file.

I am running CVS CMake late last week of which I compile myself using the standard tools that come with Xcode 3.1.2. GCC is set to version 4.0.1.

....

After some more testing I can not reproduce what I did last night. Odd. I have tried a bunch of stuff also but nothing consistent as of yet.

 I will not be able to get back to this until later this afternoon (EST). Sorry for the false hope.

Mike
(0014892)
Mike Jackson (reporter)
2009-02-11 09:26

I did some more testing on this issue and my initial reports are not really reproducible. What I think might be reproducible is changing the "sourceTree" property of the each source file added to the project along with a relative path to the Xcode project file instead of an absolute path.

from:
467EB0467EB0467EB0000000 /* /Users/mjackson/Downloads/BreakPointBug/Simple-Build/main.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = "sourcecode.c.c"; name = "main.c"; path = "/Users/mjackson/Downloads/BreakPointBug/Simple-Build/main.c"; sourceTree = "<absolute>"; };

to:
467EB0467EB0467EB0000000 /* /Users/mjackson/Downloads/BreakPointBug/Simple-Build/main.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = "sourcecode.c.c"; name = "main.c"; path = ../main.c; sourceTree = SOURCE_ROOT; };

Making this change seems to be able to let me Debug the project without a problem. In order to test each iteration I run the following commands before each test:

[mjackson@Shepard:Build]$ rm -rf *; cmake -G Xcode ../
[mjackson@Shepard:Build]$ mate simple.xcodeproj/project.pbxproj
<Edit the file to make the changes. Save and close the file>
[mjackson@Shepard:Build]$ open simple.xcodeproj
<select the "Compile & Debug" command>
 The debugger will stop at a breakpoint that is set in main.c

I still think that the projectRoot needs to be fixed also but may be less important to this specific issue.

I tried turning on SET (CMAKE_USE_RELATIVE_PATHS "TRUE") to see if CMake would automatically generate the relative paths but that command did not seem to have any affect on the generated Xcode projects. I tried to debug through cmake to try and figure out why it was failing to generate the relative paths but came up empty.

The work-around for all of this is to turn off the "Load Symbols Lazily" preference in Xcode.

Not sure where this leaves the bug at this point.

Mike Jackson
(0014901)
Eric Wing (reporter)
2009-02-11 15:44

I did some testing with the current CVS version on my iMac, but I get the exact same results as my stale version.

I asked for help from an Xcode engineer last night at my local NSCoderNight. Unfortunately, we weren't able to make any further progress on this bug.

But he did tell me that projectRoot is only used for SCM and the Xcode snapshots feature. (Neither which I use by the way for the same reason...Xcode doesn't currently support Mercurial or Git. The snapshots feature is totally redundant with distributed SCMs and Xcode's implementation is much less useful plus I don't really trust Xcode all that much with preserving my data integrity.)

So as you say, projectRoot needs to be fixed, but I don't think its directly related to this bug.
(0014902)
Bill Hoffman (manager)
2009-02-11 16:10

This really seems like a bug in Xcode. If you have any connections at Apple, can we try to get it fixed? A full path to a file should work. It will be really hard to get relative paths working, CMAKE_USE_RELATIVE_PATHS really does not work for a variety of reasons, and most likely never will.
(0014903)
Eric Wing (reporter)
2009-02-11 16:17

Unfortunately, my connections are not that strong. We would have to file a bug through usual channels and hope the people receive the bug don't dismiss it as a CMake bug.
(0014904)
Mike Jackson (reporter)
2009-02-11 16:24

File the bug with Apple. In the time between the fix (probably forever) you can still work around the problem as stated above.

Mike
(0016930)
Doug Gregor (reporter)
2009-07-22 02:42

The attached patch (against CMake CVS) seems to fix the problem with Xcode 3.1 on Leopard. I tested it with the LLVM+Clang CMake project, which built from scratch and for which I was able to set a breakpoint and debug normally. It would really help if others could test this patch, too!
(0016935)
David Cole (manager)
2009-07-22 11:34

Patch applied to CVS HEAD of CMake.

$ cvs commit -m "BUG: Fix issue 0008481 - generate Xcode projects such that breakpoints may be used from the Xcode debugger without adjusting any settings within the Xcode GUI first... Thanks to Doug Gregor for the patch."

/cvsroot/CMake/CMake/Source/cmGlobalXCodeGenerator.cxx,v <-- Source/cmGlobalXCodeGenerator.cxx
new revision: 1.219; previous revision: 1.218
(0016956)
Brad King (manager)
2009-07-24 10:19

Unfortunately Doug's patch causes Xcode to write files into the *source* tree:

$ find Tests/COnly/build -type f
Tests/COnly/build/COnly.build/Release/ALL_BUILD.build/ALL_BUILD.dep
Tests/COnly/build/COnly.build/Release/ALL_BUILD.build/Script-528760528760528760000000.sh
Tests/COnly/build/COnly.build/Release/ALL_BUILD.build/Script-52EDE052EDE052EDE0000000.sh
(0016961)
Doug Gregor (reporter)
2009-07-24 11:18

Ouch. Please revert; I'll have to take a deeper look at what is going on.
(0016962)
Doug Gregor (reporter)
2009-07-24 13:03

It appears that adding

  SYMROOT = "<project binary dir>/build";

into the buildSettings of each XCBuildConfiguration entry (where CMake puts SDKROOT, MACOSX_DEPLOYMENT_TARGET, and ARCHS) will change the default "build results" location to go where we want it.
(0016963)
David Cole (manager)
2009-07-24 15:59

Additional fix to eliminate writing files into the source tree...

$ cvs commit -m "BUG: Additional fix necessary for issue 0008481 so that Xcode builds do not write files into the source tree. Also add a test that runs last to check for local modifications in CMake_SOURCE_DIR based on whether 'cvs -q -n up -dP' output is empty. Test fails on dashboard runs when there are local modifications. Test passes on non-dashboard runs with local modifications so that CMake developers may have mods when running the test locally."

/cvsroot/CMake/CMake/Source/cmGlobalXCodeGenerator.cxx,v <-- Source/cmGlobalXCodeGenerator.cxx
new revision: 1.220; previous revision: 1.219
/cvsroot/CMake/CMake/Tests/CMakeLists.txt,v <-- Tests/CMakeLists.txt
new revision: 1.97; previous revision: 1.96
/cvsroot/CMake/CMake/Tests/CMakeTests/CMakeLists.txt,v <-- Tests/CMakeTests/CMakeLists.txt
new revision: 1.14; previous revision: 1.13
/cvsroot/CMake/CMake/Tests/CMakeTests/CheckSourceTreeTest.cmake.in,v <-- Tests/CMakeTests/CheckSourceTreeTest.cmake.in
initial revision: 1.1
(0016964)
David Cole (manager)
2009-07-24 16:15

$ cvs commit -m "BUG: Oops. Left chunk of junk at the bottom of the main Tests CMakeLists.txt file with the last commit... Sorry." Tests/CMakeLists.txt

/cvsroot/CMake/CMake/Tests/CMakeLists.txt,v <-- Tests/CMakeLists.txt
new revision: 1.98; previous revision: 1.97
(0016965)
David Cole (manager)
2009-07-24 16:32

...the Continuous saga continues...

$ cvs commit -m "BUG: Close endif statements with same string as if so that it still configures with CMake 2.4 -- also check for existence of FindCVS.cmake before doing find_package(CVS QUIET) also for CMake 2.4 sake..." Tests/CMakeLists.txt

/cvsroot/CMake/CMake/Tests/CMakeLists.txt,v <-- Tests/CMakeLists.txt
new revision: 1.99; previous revision: 1.98
(0016966)
David Cole (manager)
2009-07-24 17:13

...and one more improvement...

$ cvs commit -m "BUG: Improve CheckSourceTree test so that it ignores 'U ' output from cvs update. Also: improve failure logic for dashboard runs and developer runs."

/cvsroot/CMake/CMake/Tests/CMakeTests/CheckSourceTreeTest.cmake.in,v <-- Tests/CMakeTests/CheckSourceTreeTest.cmake.in
new revision: 1.2; previous revision: 1.1
(0016967)
David Cole (manager)
2009-07-24 17:29

$ cvs commit -m "BUG: Close endif statements with same string as if so that it still configures with CMake 2.4. One more time. Encore, encore." Tests/CMakeTests/CMakeLists.txt

/cvsroot/CMake/CMake/Tests/CMakeTests/CMakeLists.txt,v <-- Tests/CMakeTests/CMakeLists.txt
new revision: 1.15; previous revision: 1.14
(0016968)
David Cole (manager)
2009-07-24 18:30

$ cvs commit -m "BUG: One last attempt for today to get the new CheckSourceTree test running on dashboards driven by CMake 2.4... Good night now."

/cvsroot/CMake/CMake/Tests/CMakeLists.txt,v <-- Tests/CMakeLists.txt
new revision: 1.100; previous revision: 1.99
(0017608)
Brad King (manager)
2009-09-18 11:10

Is this bug resolved now?
(0017609)
David Cole (manager)
2009-09-18 11:28

As far as I am concerned it is now resolved. (I left it open back when I last "fixed" it because of the multiple commits I had to make to fix it.... Then I wanted to wait till I was sure the dashboard was stable.... Then I forgot to come back and mark it as resolved.)

If Eric or Doug disagrees, they can re-open the issue...
(0017610)
Brad King (manager)
2009-09-18 13:38

This was posted yesterday:

http://www.cmake.org/pipermail/cmake/2009-September/032016.html [^]
(0017642)
Brad King (manager)
2009-09-19 11:22

Okay, that post seems to be a different problem from this bug. Discussion of that problem does not belong here, so I'm closing this one again.
(0017684)
Brad King (manager)
2009-09-21 17:05

After further investigation, the problem reported in this thread:

  http://www.cmake.org/pipermail/cmake/2009-September/032112.html [^]

was in fact caused by the fix for this issue.
(0017685)
Brad King (manager)
2009-09-21 17:09

Furthermore, the fix does not interact well with CMAKE_USE_RELATIVE_PATHS.
The patch took the output of cmGlobalXCodeGenerator::ConvertToRelativeForXCode and converted it to a relative path again. It worked because the first method does nothing if CMAKE_USE_RELATIVE_PATHS is off (default).

Really we need to just make ConvertToRelativeForXCode always generate a relative path. Then most of the original fix is unnecessary. However, we need to make all this work with older Xcode versions too.
(0017698)
Brad King (manager)
2009-09-22 10:20

This thread points out that projectRoot="" and projectDirPath="/path/to/source" is also necessary for SCM to work:

  http://www.cmake.org/pipermail/cmake/2008-December/026097.html [^]
(0017710)
Brad King (manager)
2009-09-22 16:21

I've committed changes to reference all source files relative to the top of the source tree. It simplifies the previous fix and converts paths relative to subdirectory projects correctly. This addresses the problems in both threads mentioned above.

Optionally force conversion to relative path
/cvsroot/CMake/CMake/Source/cmLocalGenerator.cxx,v <-- Source/cmLocalGenerator.cxx
new revision: 1.315; previous revision: 1.314
/cvsroot/CMake/CMake/Source/cmLocalGenerator.h,v <-- Source/cmLocalGenerator.h
new revision: 1.117; previous revision: 1.116

Fix Xcode project references to the source tree
/cvsroot/CMake/CMake/Source/cmGlobalXCodeGenerator.cxx,v <-- Source/cmGlobalXCodeGenerator.cxx
new revision: 1.230; previous revision: 1.229
/cvsroot/CMake/CMake/Source/cmGlobalXCodeGenerator.h,v <-- Source/cmGlobalXCodeGenerator.h
new revision: 1.63; previous revision: 1.62
(0017735)
Brad King (manager)
2009-09-23 14:09

The previous changed caused Xcode 1.5 to write files into the source tree because projectDirPath now always points at it.
(0017736)
Brad King (manager)
2009-09-23 14:10

...and the fix:

Add Xcode SYMROOT setting for custom targets
/cvsroot/CMake/CMake/Source/cmGlobalXCodeGenerator.cxx,v <-- Source/cmGlobalXCodeGenerator.cxx
new revision: 1.232; previous revision: 1.231

 Issue History
Date Modified Username Field Change
2009-02-06 22:38 Eric Wing New Issue
2009-02-07 12:00 Bill Hoffman Note Added: 0014820
2009-02-07 12:00 Bill Hoffman Status new => assigned
2009-02-07 12:00 Bill Hoffman Assigned To => Bill Hoffman
2009-02-07 12:04 Bill Hoffman Note Added: 0014821
2009-02-07 16:55 Eric Wing Note Added: 0014827
2009-02-07 16:59 Eric Wing Note Added: 0014828
2009-02-07 17:02 Eric Wing Note Added: 0014829
2009-02-07 17:17 Bill Hoffman Note Added: 0014830
2009-02-07 17:31 Eric Wing Note Added: 0014832
2009-02-07 17:38 Bill Hoffman Note Added: 0014833
2009-02-07 17:43 Eric Wing Note Added: 0014834
2009-02-07 18:12 Bill Hoffman Note Added: 0014835
2009-02-09 15:43 Eric Wing Note Added: 0014852
2009-02-09 17:02 Eric Wing Note Added: 0014854
2009-02-09 17:11 Eric Wing File Added: BreakPointBug.tar.gz
2009-02-09 17:12 Eric Wing Note Added: 0014855
2009-02-09 17:35 Eric Wing Note Added: 0014856
2009-02-09 17:38 Eric Wing Note Added: 0014857
2009-02-09 17:42 Eric Wing Note Added: 0014858
2009-02-09 17:50 Eric Wing Note Added: 0014859
2009-02-09 17:52 Eric Wing Note Added: 0014860
2009-02-09 18:30 Bill Hoffman Note Added: 0014861
2009-02-09 18:31 Bill Hoffman Note Edited: 0014861
2009-02-09 18:32 Bill Hoffman Note Edited: 0014861
2009-02-09 18:37 Eric Wing Note Added: 0014862
2009-02-09 20:24 Mike Jackson Note Added: 0014863
2009-02-09 21:19 Bill Hoffman Note Added: 0014864
2009-02-09 21:27 Mike Jackson Note Added: 0014865
2009-02-09 21:35 Bill Hoffman Note Added: 0014866
2009-02-09 21:36 Mike Jackson Note Added: 0014867
2009-02-09 21:40 Mike Jackson Note Added: 0014868
2009-02-09 21:43 Bill Hoffman Note Added: 0014869
2009-02-09 21:46 Eric Wing Note Added: 0014870
2009-02-09 22:02 Bill Hoffman Note Added: 0014871
2009-02-09 22:03 Bill Hoffman Note Edited: 0014871
2009-02-09 22:10 Mike Jackson Note Added: 0014872
2009-02-09 22:17 Mike Jackson Note Added: 0014873
2009-02-09 23:20 Bill Hoffman Note Added: 0014876
2009-02-10 03:29 Eric Wing Note Added: 0014878
2009-02-10 08:03 Eric Wing Note Added: 0014879
2009-02-10 09:17 Mike Jackson Note Added: 0014880
2009-02-11 09:26 Mike Jackson Note Added: 0014892
2009-02-11 15:44 Eric Wing Note Added: 0014901
2009-02-11 16:10 Bill Hoffman Note Added: 0014902
2009-02-11 16:17 Eric Wing Note Added: 0014903
2009-02-11 16:24 Mike Jackson Note Added: 0014904
2009-07-22 02:40 Doug Gregor File Added: cmake-xcode-debug-fix.patch
2009-07-22 02:42 Doug Gregor Note Added: 0016930
2009-07-22 09:45 Bill Hoffman Assigned To Bill Hoffman => David Cole
2009-07-22 11:34 David Cole Note Added: 0016935
2009-07-24 10:19 Brad King Note Added: 0016956
2009-07-24 11:18 Doug Gregor Note Added: 0016961
2009-07-24 13:03 Doug Gregor Note Added: 0016962
2009-07-24 15:59 David Cole Note Added: 0016963
2009-07-24 16:15 David Cole Note Added: 0016964
2009-07-24 16:32 David Cole Note Added: 0016965
2009-07-24 17:13 David Cole Note Added: 0016966
2009-07-24 17:29 David Cole Note Added: 0016967
2009-07-24 18:30 David Cole Note Added: 0016968
2009-09-18 11:10 Brad King Note Added: 0017608
2009-09-18 11:28 David Cole Note Added: 0017609
2009-09-18 11:28 David Cole Status assigned => resolved
2009-09-18 11:28 David Cole Resolution open => fixed
2009-09-18 13:38 Brad King Note Added: 0017610
2009-09-18 13:38 Brad King Status resolved => feedback
2009-09-18 13:38 Brad King Resolution fixed => reopened
2009-09-19 11:22 Brad King Note Added: 0017642
2009-09-19 11:22 Brad King Status feedback => closed
2009-09-19 11:22 Brad King Resolution reopened => fixed
2009-09-21 17:05 Brad King Assigned To David Cole => Brad King
2009-09-21 17:05 Brad King Note Added: 0017684
2009-09-21 17:05 Brad King Status closed => feedback
2009-09-21 17:05 Brad King Resolution fixed => reopened
2009-09-21 17:09 Brad King Note Added: 0017685
2009-09-22 10:20 Brad King Note Added: 0017698
2009-09-22 10:22 Brad King Relationship added related to 0007044
2009-09-22 16:21 Brad King Note Added: 0017710
2009-09-23 08:22 Brad King Status feedback => closed
2009-09-23 08:22 Brad King Resolution reopened => fixed
2009-09-23 14:09 Brad King Note Added: 0017735
2009-09-23 14:09 Brad King Status closed => feedback
2009-09-23 14:09 Brad King Resolution fixed => reopened
2009-09-23 14:10 Brad King Note Added: 0017736
2009-09-24 09:32 Brad King Status feedback => closed
2009-09-24 09:32 Brad King Resolution reopened => fixed


Copyright © 2000 - 2018 MantisBT Team