Hmm... Interesting. I don't see why its making a difference, but it does! Maybe the doc should make the use of ${CMAKE_CURRENT_SOURCE_DIR} more explicit ;)

Thanks!

SUBDIRS(adapters stdio stdlib string test time wchar)

INCLUDE_DIRECTORIES(BEFORE ${CMAKE_CURRENT_SOURCE_DIR})
INCLUDE_DIRECTORIES(BEFORE ${CMAKE_CURRENT_SOURCE_DIR}/include)
INCLUDE_DIRECTORIES(BEFORE ${CMAKE_CURRENT_SOURCE_DIR}/stdio)
INCLUDE_DIRECTORIES(BEFORE ${CMAKE_CURRENT_SOURCE_DIR}/stdlib)
INCLUDE_DIRECTORIES(BEFORE ${CMAKE_CURRENT_SOURCE_DIR}/string)
INCLUDE_DIRECTORIES(BEFORE ${CMAKE_CURRENT_SOURCE_DIR}/time)
INCLUDE_DIRECTORIES(BEFORE ${CMAKE_CURRENT_SOURCE_DIR}/wchar)
INCLUDE_DIRECTORIES(BEFORE ${CMAKE_CURRENT_SOURCE_DIR}/test)

hmm... now comes another question. How come I have to ask KDevelop to compile many times over to finally have a success. Shouldn't it always have an error at the same spot?

Regards,


--
Marc-André LAVERDIÈRE, B. Eng., M. A. Sc. (in progress)
Research Assitant - Computer Security Laboratory
CIISE, Université Concordia University, Montréal, Québec, Canada
www.ciise.concordia.ca

/"\
\ /    ASCII Ribbon Campaign
 X      against HTML e-mail
/ \

"Perseverance must finish its work so that you may be mature and complete, not lacking anything." -James 1:4

Filipe Sousa wrote:
Marc-André Laverdière wrote:

Dear CMakers,

I'm working on an extension to the standard C library and I'm porting to home-brew makefiles to CMake. Not making much progress so far.

It looks like one hurdle is that we use stuff like #include "stdio.h", which contains some extra definitions and then an include to the real <stdio.h>.

Here is the interesting part of the CMakeLists.txt file I use:
SUBDIRS(adapters stdio stdlib string test time wchar)

INCLUDE_DIRECTORIES(BEFORE . include stdio stdlib string test time wchar)

#add definitions, compiler switches, etc.
ADD_DEFINITIONS(-I- -pipe -Wall -W -O3 -std=c99 -posix -D__STDC_WANT_LIB_EXT1__ 1)

Now, if I have the -I-, the compiler whines that it can't find the file (especially that the newer version doesn't like -I-). I narrowed it down to the #include "stdio.h". Now, if I remove the -I-, I get a truckload of errors. My best guess is that its trying to circularly find its include files withing mine. The makefiles I manually coded in the past digested -I- very well, so this is an unenjoyed obstacle.

My guess is that I could rename our .h files and hope that there are not too many references to fix, but that's not a very tempting option.

How can I resolve this situation using CMake? Will it be really portable?
Is there an argument we can add in INCLUDE_DIRECTORIES to deal with the situation cleanly (say, INCLUDE_DIRECTORIES(QUOTES ...) )?

With kind regards,



It works here:

[EMAIL PROTECTED] ~/tmp/std $ tree
.
|-- CMakeLists.txt
|-- main.c
`-- stdio.h

0 directories, 3 files

[EMAIL PROTECTED] ~/tmp/std $ cat CMakeLists.txt
PROJECT(std C)
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR})
ADD_DEFINITIONS(-I-)
ADD_EXECUTABLE(std main.c)

[EMAIL PROTECTED] ~/tmp/std $ cat main.c
#include "stdio.h"

int main() {
  return 0;
}

[EMAIL PROTECTED] ~/tmp/std $ cat stdio.h
#include <stdio.h>


[EMAIL PROTECTED] ~/tmp/std $ mkdir build
[EMAIL PROTECTED] ~/tmp/std $ cd build/
[EMAIL PROTECTED] ~/tmp/std/build $ cmake .. && make
-- Check for working C compiler: gcc
-- Check for working C compiler: gcc -- works
-- Check size of void*
-- Check size of void* - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/fsousa/tmp/std/build
Scanning dependencies of target std
[100%] Building C object CMakeFiles/std.dir/main.o
cc1: note: obsolete option -I- used, please use -iquote instead
Linking C executable std
[100%] Building target std

[EMAIL PROTECTED] ~/tmp/std/build $ cmake --version
cmake version 2.5-20060722



------------------------------------------------------------------------

_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to