[CMake] cmake - library help

[Torri, Stephen CIV NSWCDD, W15]

> 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-sourcefiles-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