[CMake] cmake - library help

[aaron.meadows at thomsonreuters.com]

Speaking of GLOBbing, I have heard the same thing from the list. I read
the SO post you linked to, in particular, this seems to be the only
thing on the list which not GLOBbing gets you:

	* CMake will track the dependencies of a new file on disk
correctly - if we use glob then files not globbed first time round when
you ran CMake will not get picked up

I know that for speed, CMake will only look at the modify date/time on
the CMakeLists.txt.  Is there any reason it couldn't be modified to
expand GLOB lists and compare them to the previous expansion (possibly
storing said previous expansion in the CMakeCache).  I realize it would
be slightly slower, but seems like it would remove the negatives to
GLOBbing your source.

Any CMake developers want to comment on this thought?

Aaron C. Meadows 

-----Original Message-----
From: cmake-bounces at cmake.org [mailto:cmake-bounces at cmake.org] On Behalf
Of Torri, Stephen CIV NSWCDD, W15
Sent: Thursday, May 27, 2010 12:42 PM
To: Doug Reiland
Cc: cmake at cmake.org
Subject: Re: [CMake] cmake - library help

> From: Doug Reiland [mailto:dreiland at gmail.com]
> Sent: Thu 5/27/2010 12:48 PM
> To: Torri, Stephen CIV NSWCDD, W15
> Subject: Re: [CMake] cmake - library help
> 
> ok, I think I have this working, thanks.
> I am building static version of "foo" as well.
> Before, I could just archive in this composite object.
> How is the best way to do that?

I would post your question to the mailing list. I am in the same boat
attempting to learn cmake. My experience is with Automake/Autoconf and
Visual Studio. So I would like to know the answer myself.

> Here is my current cmake pseudo-code of what I have come up with?
> Note, SOURCES has list of files adding to shared lib
> 
> set SOURCES-static ${SOURCES}
> file(GLOB subdira-sources subdira/*.c)
> list(APPEND SOURCES-static ${subdira-sources})
> 
> then
> add_library(foo-static STATIC ${SOURCES-static})
> 
> I have several composite objects like this.Is there a better way?

Personally I add my files to a variable called SOURCES by hand. Although
it does make the CMakeLists.txt file longer than a glob you gain the
ability of CMAKE to track dependencies of the new file (see
http://stackoverflow.com/questions/1027247/best-way-to-specify-sourcefil
es-in-cmake).
 
Thinking about it for a few seconds I think we can come up with a few
principles to guide our use of GLOB or manual file entry.
 
Principle 1 - Everything is source. If everything is compiled in a
directory then using FILE ( GLOB <name> *.<filetype> ) seems to be the
best choice. The negative of this principle is that the directory cannot
have files for another purpose thereby requiring the use of LIST (
REMOVE_ITEM <name> <list of offending files> ). Personally I would
recommend a directory for each project.
 
Principle 2 - Only something are source. If only some things are source
then you have two approaches.
 
      Approach 1 - Use SET ( <name> <list of files ) for manual entry
 
      Approach 2 - All belong but not the following. Use FILE approach
from Principle 1 and then use LIST ( REMOVE_ITEM <name> <list of
offending files>
 
In the end the principle need to fit your development style. I like to
keep things seperated into directories with names that explain their
purpose. Its a way to idiot proof my life. Not everyone does that which
is fine. There is no simple hard fast rule that we need to follow. If it
is maintainable to your team then keep doing they way you have been.
 
Stephen
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


This email was sent to you by Thomson Reuters, the global news and information company.
Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.