> From: Doug Reiland [mailto:dreil...@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
_______________________________________________
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
