headers
Bryan O'Sullivan | 1 Mar 2008 01:25
Favicon

Adding non-build-related sources to IDE projects

Is there an appropriate way to cause an IDE like Visual Studio or Xcode 
to present entries for source files such as .h files and .xml files, 
which do not get compiled?

I'm currently listing those files as sources for library and executable 
targets.  This doesn't work very well: I have to make sure I'm not 
generating a Makefile, because then the files are listed in the Makefile 
rule and cause compilation to fail.  Under Xcode, doing this causes lots 
of build warnings as xcodebuild complains that it has no rules for .txt 
or .xml files.

Is there a better way?

	<b
Permalink | Reply | 1 comment |
headers
Bill Hoffman | 1 Mar 2008 02:22
Favicon
Gravatar

Re: Adding non-build-related sources to IDE projects

Bryan O'Sullivan wrote:
> Is there an appropriate way to cause an IDE like Visual Studio or Xcode 
> to present entries for source files such as .h files and .xml files, 
> which do not get compiled?
> 
> I'm currently listing those files as sources for library and executable 
> targets.  This doesn't work very well: I have to make sure I'm not 
> generating a Makefile, because then the files are listed in the Makefile 
> rule and cause compilation to fail.  Under Xcode, doing this causes lots 
> of build warnings as xcodebuild complains that it has no rules for .txt 
> or .xml files.
> 
> Is there a better way?
> 

That is the right way.   .h files should not be a problem.  For other 
files you might have to call set_source_files_properties with the 
HEADER_FILE_ONLY set to true.  I just realized the documentation for 
this is bogus...  What it does is keep it from being compiled by 
makefiles and various IDE's.

-Bill
Permalink | Reply | 0 comments |
headers
RazZziel | 1 Mar 2008 02:28
Picon

Include dir for inotify.h

Hi, I'm working on ap project that users inotify.h, a module that is
included in recent versions of glibc, but for example not in Debian
Etch.

The thing is, in any modern distro I'd have to include sys/inotify.h,
while in etch I have to include inotifytools/inotify.h. I've managed
to do it in CMake with CHECK_INCLUDE_FILES and a config.h, but I found
a cleaner solution that should work in theory but actually doesn't,
for me:

src/CMakeList.txt

>SET(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake_modules/")
>
>FIND_PACKAGE(Inotify REQUIRED)
>IF(INOTIFY_FOUND)
>  INCLUDE_DIRECTORIES( ${INOTIFY_INCLUDE_DIR} )
>ENDIF(INOTIFY_FOUND)

cmake_modules/FindInotify.cmake

>IF (INOTIFY_FOUND)
>  IF (NOT Inotify_FIND_QUIETLY)
>    MESSAGE(STATUS "Found Inotify: ${INOTIFY_INCLUDE_DIR}")
>  ENDIF (NOT Inotify_FIND_QUIETLY)
>ELSE (INOTIFY_FOUND)
>  IF (Inotify_FIND_REQUIRED)
>    MESSAGE(FATAL_ERROR "Could not find Inotify")
>  ENDIF (Inotify_FIND_REQUIRED)
>ENDIF (INOTIFY_FOUND)
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Mansion | 1 Mar 2008 10:03

Re: CMake and Lua

Bill Hoffman wrote:
> So what exactly about the CMake language gives you this feel?
>
That would be:
1) the syntax
and
2) the modularity constructs

I know its 'only' scripting to manage declarations into the engine.

Its a shame you can't write emitters except in C++ but that certainly 
wouldn't
be something I'd want to try with a language like this.
> But if we did that would we have a binary that that had all the 
> "wrapped" languages?

Why?  I don't care what you ship in the CMake core library.  I just want 
to be able to do any
coding in my project in a manner that's comfortable.

Even if the result is mixed, a few lines in site config should enable 
the engine to find the
interpreter DLLs and integrate them.

James
Permalink | Reply | 6 comments |
headers
Steven Van Ingelgem | 1 Mar 2008 10:05
Picon

check_include_file macro

Hi,

I'm testing with the "check_include_file" macro but I have an issue with it.
I need it to stop working if the include file is not found, and
re-check the next time it is ran...

But how can I achieve that? Because the behaviour I got is that it
runs but doesn't re-check anymore...

Thanks for any pointers
Permalink | Reply | 9 comments |
headers
Andreas Schneider | 1 Mar 2008 15:22
Gravatar

Re: check_include_file macro

Steven Van Ingelgem wrote:
> Hi,
> 

Hi,

> 
> I'm testing with the "check_include_file" macro but I have an issue with it.
> I need it to stop working if the include file is not found, and
> re-check the next time it is ran...
> 

normally check_include_file is to check for standard include files like
stdint.h and add it to a config.h file.

> But how can I achieve that? Because the behaviour I got is that it
> runs but doesn't re-check anymore...
> 

I think you want to write a find module which is used by 'find_package'.

> 
> Thanks for any pointers

	-- andreas

--

-- 
http://www.cynapses.org/ - cybernetic synapses
(Continue reading)

Permalink | Reply | 8 comments |
headers
Bill Hoffman | 1 Mar 2008 15:38
Favicon
Gravatar

Re: CMake and Lua

James Mansion wrote:
> Bill Hoffman wrote:
>> So what exactly about the CMake language gives you this feel?
>>
> That would be:
> 1) the syntax
> and
> 2) the modularity constructs
> 
> I know its 'only' scripting to manage declarations into the engine.
> 
> Its a shame you can't write emitters except in C++ but that certainly 
> wouldn't
So, C++ is the language we picked/like.  You are welcome to contribute 
one in C++.  Imagine if you could develop generators (I assume that is 
what you mean by emitters) in any language!  You wouldn't even be able 
to share them.
> be something I'd want to try with a language like this.
>> But if we did that would we have a binary that that had all the 
>> "wrapped" languages?
> 
> Why?  I don't care what you ship in the CMake core library.  I just want 
> to be able to do any
> coding in my project in a manner that's comfortable.
> 
Well, I suppose you don't have to use CMake.  Perhaps scons would be a 
better fit for your tastes.

If you did use an arbitrary language bound to CMake core, people 
building your project would have to build/get something different than
(Continue reading)

Permalink | Reply | 5 comments |
headers
Miguel A. Figueroa-Villanueva | 1 Mar 2008 15:54
Picon

Re: Re: CMake and Lua

On Fri, Feb 29, 2008 at 11:09 AM, Bill Hoffman wrote:
> Rodolfo Schulz de Lima wrote:
>
>  > The main issue with CMake script isn't when writing a build script, but
>  > when writing auxiliary stuff, like a more elaborate Find*.cmake. Just
>  > look at FindwxWidgets.cmake to see what I mean...
>  >
>
>  Thanks for the feedback.  I am wondering if there is something that can
>  be done in CMake c++ code to make writing a Find module like wx widgets
>  easier.   Maybe regular expressions in the find_* commands would help.
>  Lots of the verbosity comes from finding different names for libraries
>  and paths.  I think that has come up on the list or the bug tracker
>  recently.   The new break and return could clean it up some more, and
>  the use of lower case would make it look nicer.
>
>  -Bill

<quote from another related thread>
On Fri, Feb 29, 2008 at 1:22 PM, Rodolfo Schulz de Lima wrote:
> Bill Hoffman escreveu:
>  > Enjoy!
>
>  Wow, that must be a world record... I've mentioned the problem at 10:57
>  (Brazilian Standard Time), and the solution got committed at 14:18
>  (BRST). Guinness anyone?? I which my cable TV customer support were that
>  fast...thanks a lot Bill.

And you all thought Bill was so resistant to change :P
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steven Van Ingelgem | 1 Mar 2008 16:09
Picon

Re: check_include_file macro

In fact what I want is "check_include_file( uuid/uuid.h HAS_UUID_H )".
Where this check is a "blocking check" (in other words, cmake will
stop processing the cmakelists.txt)... The next time it should
re-check the include file...

As you can see find_package is not needed in this case.

Greetings

On 01/03/2008, Andreas Schneider <mail@...> wrote:
> Steven Van Ingelgem wrote:
>  > Hi,
>
> >
>
>  Hi,
>
>  >
>  > I'm testing with the "check_include_file" macro but I have an issue with it.
>  > I need it to stop working if the include file is not found, and
>  > re-check the next time it is ran...
>  >
>
>
> normally check_include_file is to check for standard include files like
>  stdint.h and add it to a config.h file.
>
>
>  > But how can I achieve that? Because the behaviour I got is that it
>  > runs but doesn't re-check anymore...
(Continue reading)

Permalink | Reply | 7 comments |
headers
Philip Lowman | 1 Mar 2008 17:44

Re: check_include_file macro

On Sat, Mar 1, 2008 at 10:09 AM, Steven Van Ingelgem <steven-JerXHA+aXlvzI5g0XRMfIw@public.gmane.org> wrote:

In fact what I want is "check_include_file( uuid/uuid.h HAS_UUID_H )".
Where this check is a "blocking check" (in other words, cmake will
stop processing the cmakelists.txt)... The next time it should
re-check the include file...

I don't know if there is a way to do this in CMake code but one thing you can do is open up CMakeCache.txt in your build tree and manually delete the line that says:
HAS_UUID_H:INTERNAL=
This will force the rechecking for the header file.

--
Philip Lowman 
_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Permalink | Reply | 6 comments |

Gmane