Ditto :)
On 4/6/07, Mike Jackson <[EMAIL PROTECTED]> wrote:
If you have the time.. go for it.. There is lots I would like to put up there.. just no time... -- Mike Jackson Senior Research Engineer Innovative Management & Technology Services On Apr 6, 2007, at 4:49 PM, Andrew Wagner wrote: > Thanks Eric and Mike- > > May I mirror your posts on the cmake wiki to help speed things up > for new os x users, or would one of you like to do the honors? > > I would add a bullet on > http://www.cmake.org/Wiki/CMake > in section 2.1 (cmake tutorials) > > Drew > > On Apr 5, 2007, at 5:22 PM, E. Wing wrote: > >> CMake's framework detection mechanism is now complete. Mike already >> pointed out how to use FIND_LIBRARY which is all correct. There is a >> nuance with include paths which I'll describe here. >> >> You need to decide about your #include usage pattern. Generally, OS X >> system frameworks are included as: >> #include <Cocoa/Cocoa.h> >> #include <OpenAL/al.h> >> >> But portable libraries may recommend doing flat namespaces because >> not >> everybody use the same directory name. For example, the OpenAL spec >> doesn't define where headers are located. Linux puts them in >> <AL/al.h>, OS X does <OpenAL/al.h>, and Windows doesn't put them in >> any directory so it is <al.h>. In theory, somebody else could screw >> this up even more and put it in <AL1.1/al.h>. Thus the 'portable' >> solution is: >> #include "al.h" >> >> CMake is really clever about the two cases, so if you have the usage >> first case, you want to do: >> >> FIND_PATH(COCOA_INCLUDE_DIR Cocoa/Cocoa.h) >> >> In the second case you want to do: >> FIND_PATH(OPENAL_INCLUDE_DIR al.h) >> >> CMake will set the include paths correctly depending on which style >> you specify. >> >> -Eric >> _______________________________________________ >> CMake mailing list >> CMake@cmake.org >> http://www.cmake.org/mailman/listinfo/cmake >
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
