[CMake] Master-switch options
I'm looking to have a certain group of variables controlled primarily by
one master setting
I want the cache value to be ignored when the user explicitly provides
the master variable on the command line and whenever the value of the
variable changes.
Put another way: When the user EXPLICITLY specifies or changes the value
of MasterVariable, I want to delete the values of
${${AffectedVariables_MasterVariable}} from the cache.
Example:
Master: "VARIANT"
Controls: SSE2, SSE3, PACKAGE_FORMAT
Setting1: VARIANT=Internal, SSE2=OFF, SSE3=OFF, PACKAGE_FORMAT=TGZ
Setting83: VARIANT=Eval, SSE2=ON, SSE3=ON, PACKAGE_FORMAT=DEB
Setting509: VARIANT=Client623, SSE=ON, SSE3=OFF, PACKAGE_FORMAT=RPM
PIZZA: XL
...
CMakeCache.txt values:
VARIANT=Internal, SSE2=ON, SSE3=OFF, PACKAGE_FORMAT=TGZ, PIZZA=L
$ cmake -DVARIANT=Internal -DPIZZA=Medium
VARIANT=Internal, *SSE2=OFF*, SSE3=OFF, PACKAGE_FORMAT=TGZ, PIZZA=M
(SSE2 was reset to it's default value)
$ cmake -DPACKAGE_FORMAT=RPM -DVARIANT=Internal
VARIANT=Internal, SSE2=OFF, SSE3=OFF, PACKAGE_FORMAT=RPM, PIZZA=M
(All values were reset but the -DPACKAGE_FORMAT overrode the default of
that option, non-controlled value, PIZZA, left alone)
$ cmake -DEval
VARIANT=Eval, *SSE2=ON*, *SSE3=ON*, *PACKAGE_FORMAT=DEB*, PIZZA=M
(previously user-specified package_format was reset because it was not
explicitly provided)
$ cmake .
(No changes because no VARIANT explicitly specified)
If this was being implemented by deleting the CMakeCache.txt file, then
the value of "PIZZA" would be continually clobbered along with all the
other values...
Is there a way to do this? I'm wanting to build it something like:
OPTION(SSE2 "Enable SSE2 instructions" OFF)-- General default.
...
IF ( VARIANT BECOMES "Internal" )
DEFAULT(SSE2 OFF)
DEFAULT(SSE3 OFF)
DEFAULT(PACKAGE_FORMAT "TGZ")
ELSEIF ( VARIANT BECOMES "Eval" )
DEFAULT(SSE2 ON)
DEFAULT(SSE3 OFF)
DEFAULT(PACKAGE_FORMAT "DEB")
ELSEIF ( VARIANT BECOMES "Client623" )
DEFAULT(SSE2 ON)
DEFAULT(SSE3 OFF)
DEFAULT(PACKAGE_FORMAT "RPM")
ELSEIF ...
Or perhaps the slightly less error-prone:
OPTIONS( VALUE DEFAULTS
VARIABLE:VALUE
...)
This would then complain about the following, because the second OPTIONS
has a different list for the same control as the previous incarnation:
OPTIONS(VARIANT VALUE "Internal" DEFAULTS
SSE2 OFF
SSE3 OFF
PACKAGE_FORMAT "TGZ"
)
OPTIONS(VARIANT VALUE "Eval" DEFAULTS
SSE2 ON
SES3 OFF# Typo
PACKAGE_FORMAT "DEB"
)
OPTIONS(VARIANT VALUE "Client623" DEFAULTS
SSE2 ON
SSE3 OFF
PACKAGE_FORMAT "RPM"
)
Another advantage of this is that the GUI/CCMake could use these to
build a drop-down list of "VARIANT" settings, and CMake itself could
ascertain that "-DVARIANT=Intrenal" (typo) is invalid (-DVARIANT is used
in OPTIONS but there is no OPTIONS that matches Intrenal).
- Oliver
--
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
Re: [CMake] Couple of library/link questions
Andreas Pakulat said the following on 3/20/2012 5:21 PM:
- The makefiles I'm basing this on build libevent_core.lib,
libevent_extras.lib and then libevent.lib which is basically the two
previous libraries merged.
I wanted to do:
ADD_LIBRARY(libevent_core ${CoreSrcFiles})
ADD_LIBRARY(libevent_extras ${ExtraSrcFiles})
ADD_LIBRARY(libevent)
TARGET_LINK_LIBRARIES(libevent libevent_core libevent_extras)
but this generates a warning/error, listing the two libraries in
Whats the error? It should just work.
I mis-spoke; it gives a /warning/ for the ADD_LIBRARY(libevent) with no
source files, warning that it is usually an error in the CMakeLists.txt
file.
- Oliver
--
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
Re: [CMake] Couple of library/link questions
Jean-Christophe Fillion-Robin said the following on 3/20/2012 5:54 PM: Hi Olivier, Assuming you have not set the flag, BUILD_SHARED_LIBS [1] set to TRUE, I will consider you are building static libraries. If this last statement is valid, it seems your approach is the right one. Ah, I actually expose it as a variable so that the build process can decide whether they should be shared or not :) I would also recommend you to read the following entry: http://vtk.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F I did actually look to the FAQ, but I didn't make the connection, although what I was actually trying to do was make the 3rd library (libevent) an archive of all the .obj files produced during the compilation of the first two libraries, rather than an empty stub :) I realize that this case is slightly trivial, but that's just my working point in the conversion; there are actually several other module-libraries which it compiles both into the full libevent lib and as stand-alone modules to allow end-users to be choosy about which components they require. - Oliver -- 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
[CMake] How to make package depend on tests?
I have test and package configurations on my project, I want: cmake . make package to run force injection of the "test" target prior to building the package target. Can it be done? How? :) -- 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
Re: [CMake] Making a variable a dependency...
Michael Hertling said the following on 2/6/2012 6:39 PM:
On 02/06/2012 10:56 PM, Alexander Neundorf wrote:
On Saturday 04 February 2012, Oliver Smith wrote:
My CMakeLists uses the Subversion repository information in a couple of
places (it configures a file revision.h and it uses it for the CPack
package name).
The problem is that this variable is cached and retained until the cache
is rebuilt, instead of being calculated or evaluated per make. So if I
do a build, then do an svn update and pull some changes, it will build a
new executable but it will stamp it with the revision number from when
CMake last regenerated the make files...
Is there a way to mark a variable as volatile or something so that CMake
will always recalculate it and check if it has changed?
Would it be acceptable if cmake would rerun after every build ?
You could enforce that e.g. with a add_custom_command( POST_BUILD ... ) which
could e.g. touch CMakeCache.txt or something.
Better ideas ?
Delay the generation of the revision.h header until build phase
via a custom command; look at the following exemplary project:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_CUSTOM_COMMAND(OUTPUT dummy revision.h
COMMAND ${CMAKE_COMMAND}
-DBD=${CMAKE_BINARY_DIR}
-DWC=${CMAKE_SOURCE_DIR}
-P ${CMAKE_SOURCE_DIR}/revision.cmake)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
"#include
#include \"revision.h\"
int main(void)
{
printf(\"%d\\n\",REVISION); return 0;
}
")
ADD_EXECUTABLE(main main.c revision.h)
# revision.cmake:
FIND_PACKAGE(Subversion)
Subversion_WC_INFO(${WC}@HEAD P)
FILE(WRITE ${BD}/revision.h.in "#define REVISION @P_WC_REVISION@\n")
CONFIGURE_FILE(${BD}/revision.h.in ${BD}/revision.h @ONLY)
A "make" run rebuilds the main target whenever the repository's head
revision has changed - possibly inappropriate for actual usage, just
for demonstration purposes; adapt the revision.cmake script to suit
the needs.
BTW, can anybody confirm that the above-noted example doesn't work
if the order of "dummy" and "revision.h" in the custom command is
reversed? AFAICS, revision.h is removed after being generated in
this case, so the subsequent compilation fails.
Unless I'm missing something, that won't work because P_WC_REVISION gets
cached in the CMakeCache.txt -- or does using -P cause it to skip the
caching?
- Oliver
--
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
Re: [CMake] Making a variable a dependency...
Alexander Neundorf said the following on 2/6/2012 3:56 PM: Would it be acceptable if cmake would rerun after every build ? You could enforce that e.g. with a add_custom_command( POST_BUILD ... ) which could e.g. touch CMakeCache.txt or something. Better ideas ? We're working in a client/server environment in a fairly agile production environment; we need to have /all/ executables correctly stamped with the revision they're sourced from. So I kind of need it run before each build. Further, one of my problems is that right now the variable gets cached in CMakeCache.txt, so I have to delete CMakeCache.txt or do cmake -DSubversion_FOUND=NO or similar. In the short term, I can just make it always rebuild the revision.h, but that has the downside of causing it to /always/ rebuild the library that includes it, causing all binaries to relink, and so on, which is fairly time consuming (it's a very large project :) -- 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
[CMake] CPack / Debian install location
osmith@luciddev:~/pn/WW2/src$ cmake --version
cmake version 2.8.2
I can't see to get "make package" to generate Debian packages that
install any place but /usr/bin. (I actually want them in
/playnet/ra/bin, /playnet/ra/lib and so on)
SET(CPACK_GENERATOR "DEB")
SET(CPACK_INSTALL_PREFIX "/playnet/ra")
SET(CPACK_PACKAGE_INSTALL_PREFIX "/playnet/ra")
SET(CPACK_DEBIAN_INSTALL_PREFIX "/playnet/ra")
SET(CPACK_PACKAGE_VERSION
"${REPO_WC_REVISION}.${CMAKE_BUILD_TYPE}-${WW2_TARGET_ENV}")
SET(CPACK_PACKAGE_NAME "servers")
SET(CPACK_PACKAGE_VENDOR "Cornered Rat Software")
SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY "Game servers")
SET(CPACK_PACKAGE_DESCRIPTION "'Game servers and tools.")
SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Oliver Smith")
SET(CPACK_DEBIAN_PACKAGE_INSTALL_PREFIX "/playnet/ra")
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libopenthreads-dev (>= 2.8.3-4),
lua5.1 (>= 5.1.4-5), libmysqlclient16 (>= 5.1.49), bash (>= 4.1),
gdb (>= 7.2), nfs-common, mysql-server (>= 5.1), nfs-kernel-server")
SET(CPACK_DEBIAN_PACKAGE_DESCRIPTION "Game servers")
SET(CPACK_DEBIAN_PACKAGE_SECTION "Network")
SET(CPACK_DEBIAN_PACKAGE_PRIORITY "Important")
SET(CPACK_DEBIAN_PACKAGE_RECOMMENDS "vim, mysql-client (>= 5.1),
python (>= 2.6.6)")
SET(CPACK_DEBIAN_PACKAGE_SUGGESTS "lvm2, perl (>= 5.1)")
I've played with a half dozen other variable name combinations, but it
still all goes into /usr.
- Oliver
--
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
Re: [CMake] Portable revision lookup?
Oliver kfsone Smith said the following on 2/2/2012 4:17 PM:
John Drescher said the following on 2/2/2012 3:36 PM:
Cmake has support for pulling the svn and I believe git revs using
cmake modules. Here is what I do for svn
Much appreciated -- I just didn't think to look in the "Find" package,
duly noted for future reference.
- Oliver
Hrm - ran into a problem with that, the revision is only produced when
cmake rolls the Makefiles. I.e, if you do the following:
$ cd /tmp && mkdir cmake-test && cd cmake-test && svnadmin create repo
&& svn co file:///tmp/cmake-test/repo src || echo "Failed"
$ cat >CMakeLists.txt < Repo")
Subversion_WC_INFO(${Test_SOURCE_DIR} Repo)
MESSAGE("Repo_WC_REVISION = ${Repo_WC_REVISION}")
$ cmake -G "Unix Makefiles" .
...
$ make
...
/Repo_WC_REVISION=0/
$ svn add CMakeLists.txt && svn commit -m "Bump to revision 1" && svn update
...
/At revision 1./
$ make
/Repo_WC_REVISION=0/
In particular, this prevents me using it to generate CPack package names :(
- Oliver
--
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
Re: [CMake] Portable revision lookup?
John Drescher said the following on 2/2/2012 3:36 PM: Cmake has support for pulling the svn and I believe git revs using cmake modules. Here is what I do for svn Much appreciated -- I just didn't think to look in the "Find" package, duly noted for future reference. - Oliver -- 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
[CMake] Portable revision lookup?
Right now I wrap my Linux-based build process with a script that
features the line
REVISION=`svn info ${SRC_PATH} | awk '/^Revision/ { print $2 }'`
Which is neither OS or VCS portable.
I'm trying to put together a CPack configuration to make the builds, and
I'd like to name the resulting installer for the revision it was built from.
Is there any kind of built-in mechanism I can use for this, or would I
be best just using IFs and executing os-specific commands? (I'm not
quite sure how I'm going to pluck the info out under Windows)
I'm also wondering if there is a way to query other repository
attributes - specifically the URL - I'd like to build installers named
...
e.g.
my-client.baseline.57721.deb
or
my-server.branches.1.35.57804.tbz2
Any pointers?
- Oliver
--
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
[CMake] Compile multiple-sources at a time?
I realize not every build environment supports the option, but is there a way to get CMake to generate Makefiles which aggregate source files, e.g. $ g++ -pipe -o library.a lib1.cpp lib2.cpp lib3.cpp $ g++ -pipe -o exeutable file1.cpp file2.cpp file3.cpp library.a - Oliver -- 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
[CMake] Outputting VS projects under Linux
Is it possible to create visual studio/msbuild projects under Linux? (It would ease the flow of our automation chain, and it'd be handy for working with MonoDevelop). - Oliver ___ 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
Re: [CMake] header files with visual studio
Michael Jackson said the following on 11/15/2010 11:56 AM: Ahh. It is a bit clearer the tract you are taking. What I am suggesting is that you only have to run the "scanner" once and keep the results in CMake syntax files so that CMake can just simply re-use the list. As you add headers during development you can add headers to the lists that were generated. It is the first big lump of headers which is the daunting task. After that general maintenance of the CMake files is simple and straight forward. For example in the folder: +- Solution | +- Target 1 | | +- Sources | | +- Headers you can have a file Headers.cmake which contains set (TARGET_1_HEADERS foo.h bar.h other.h) which can be generated once by a script. And in the CMakelists.txt file for Target 1 you can have: include (Headers/Headers.cmake) It's not nearly that simple; "Target1" might be the login server, which uses header files from login/, chat/, etc, etc, etc. And these dependencies change frequently. The primary purpose is not to provide an SCM list of header files, but an active dependency list of header files so that IDE functions like "search this target only" work. Our source layout has many "modules", but module != target. Any given target will have both source and header files from numerous modules/folders. Sure, everytime we alter the #Include chain we're going to have to rebuild the project files from the CMakeLists, but with per-target dependency-generated header lists ... It becomes worth it. - Oliver ___ 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
Re: [CMake] header files with visual studio
Michael Jackson said the following on 11/15/2010 9:33 AM: I have been casually following this thread and I understand the OPs hesitation when trying to add thousands of files into a CMake build system but what I think one needs to think about is that you are only going to add the files ONCE for the project. After that the CMake files are correctly created and any other additions are in the form of only a few files at a time during the course of normal development. What I end up doing in the cases where this happened to me was to create my CMake files and figure out what needs to added to a CMake file and the syntax that it needs to be added in. Then a one off shell script (or pick your favorite language) is created to look at the project, get a list of files needed, then "generate" a CMake file that can be incorporated into your project. After that is done the shell script is no longer needed because you have your CMake files and you will not need your dependency analysis tool because CMake and/or Visual Studio will have what it needs. You can place the CMake code in files called "Sources.cmake" in each source directory then have your higher level CMake files simply "include" Sources.cmake for each project. Yes there is development time for this but the shell script does not have to be pretty or efficient. It is only going to be run once to generate the cmake files. Ah - you've kind of both missed the nuance. The very last thing I want is one singular header list. Infact, the header lists for any given project will be relatively small (potentially hundreds of headers, but not thousands). The scanner only has to search the source files listed under "+ Sources" for each project and only has to include the resulting headers. The lists are thus likely to be relatively small and pretty easily generated. The result would be +- Solution | +- Target 1 | | +- Sources | | +- Headers | +- Target 2 | | +- Sources | | +- Headers ... instead of +- Solutions | +- Target 1 | | +- Sources | +- Target 2 | | +- Sources | +- Target 3 | | +- Sources ... Caveat: a header may appear under more than one target for a given CMakeLists/solution/cbp file, but that's ok. - Oliver ___ 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
Re: [CMake] header files with visual studio
Eric Noulard said the following on 11/14/2010 4:00 AM: I do (may be did?) have mental dichotomy between the "build process" I'm going to take blame there for doing a poor job of posing the original inquiry :) But may be I shall step back and just think differently about it and even if I need to explicitly use SCM for headers may be they shall just "disappear" from CMakeLists.txt? May be the public "exported" headers would still appear in the CMakeLists.txt but most of them can just go away. I don't think there is a globally quantifiable way to distinguish exportable headers, so that is a distinct data point (the same way that for many projects "*/*.cpp" isn't an accurate description of the source dependencies for any given target :) Now re-reading the Michael post it seems that having some hook (or property) to get dependency list from a particular file (or target) should be the way to go. Yep, I was thinking the same. I'll look at writing a feature request, as you suggest :) - Oliver ___ 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
Re: [CMake] header files with visual studio
Michael Hertling said the following on 11/11/2010 5:23 AM: Clearly, the downside is the usage of an external dependency scanner. Yep, but radically better than having to try and manually duplicate/recreate/maintain the dependency list :) Thank you for your posts :) - Oliver ___ 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
Re: [CMake] header files with visual studio
Eric Noulard said the following on 11/11/2010 5:53 AM: Having a lot of source code re-use from "source modules" that can be shared between several projects is off course a necessary goal when your source code base grows and the set of projects using those goes along the same curve. My experience is in this case you may have mainly two kinds of re-use: A) "external-like" re-use were the reused module is an autonomous [set of] library and executable. CMake may handle this using "ExternalProject_Add" module and the module may have his own CMakeLists.txt containing the toplevel PROJECT(...) B) "internal-like" re-use. You may import the source but the imported source may not be compiled autonomously and should be plugged somewhere in the project source tree using the module. In this case ecah "internal-like" module may be shipped with a SourceDescription.cmake file which (manually) define appropriate set of CMake VAR (_SRC_FILES,_HEADER_FILES, ...) which can be included by the upper-level using project. A-type project are edited (and source-controlled) on their own. B-type project may be edited in any user project, how you handle source control in this case depends on your organisation and project inter-dependency management. What I was hoping to achieve was a "Header Files" folder along side each "Source Files" folder so that the headers were pertinent to any given project within a solution. Does CMake "source_group" will do the jobs if each sub-project is defining its list of__FILES? Now, I admit I'm not a usual Visual Studio user so you are pretty right with the fact I didn't face any performance issue on big project with VS. I did work on relatively big source project with many imported modules (external-like or internal-like) but we were not using any IDE just emacs/vi etc and a big set of Makefiles (no CMake usage at that time). I mostly work with emacs/vi and - prior to CMake - Makefiles. I'm still mostly working with emacs/vi, but I also do a fair amount of work with Visual Studio and CodeBlocks, primarily when I need to test client interactions with server processes. Manually maintaining duplicated lists of #includes is data duplication: Like manually maintaining dependency lists. If we had to do that with CMake, well I doubt we'd be having this conversation in the first place because we probably wouldn't be /using/ CMake. So I don't understand why you would feel differently about having those lists automatically transcribed to the resultant IDE solution/project files. - Oliver ___ 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
Re: [CMake] header files with visual studio
Michael Hertling said the following on 11/6/2010 7:39 AM:
stored in the ${CMAKE_BINARY_DIR}/filelist.dat script as an assignment
to the variable FILELIST. Subsequently, this filelist.dat is read via
INCLUDE(), so CMake keeps track of it, i.e. changing the filelist.dat
results in a rebuild. Finally, the filelist custom target regenerates
filelist.dat by executing filelist.cmake. Hence, each time the set of
*.c files in CMAKE_SOURCE_DIR changes, a "make filelist" will update
filelist.dat, and the following "make" will rebuild - taking into
account the refreshed list of source files. Maybe, this approach
can be adapted to platforms other than *nix and large projects.
I already have the source files split up into their myriad sub-projects,
all I really want is to tap into the dependency generator to get a list
of header files pertinent to any given project.
In particular, this is useful for performing search operations.
Remember: Visual Studio allows you to constrain multi-file searches a
number of ways, one of which is "Just this project".
When you have thousands of header files, having every header in your
codebase arbitrarily crammed into your project file means that every
project-only search is going to return too many results.
___
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
Re: [CMake] header files with visual studio
Eric Noulard said the following on 11/6/2010 6:20 AM:
Initially it may be a pain to list them but after a while its generally better
to manually keep track of file (dis)appearing in your source tree.
(which is usually what you do when using an IDE without CMake)
I.e. if those files are/were added "by hand" into the build system then they
must but tracked by explicit list in CMakeLists.txt.
The only case (I see) you may faithfully glob for *.h *.whatever is when
those are generated files.
Not doing that means
"I don't care about source file which are added/removed
I just want to compile those"
**MY** opinion is that this way of looking to source code is wrong.
You appear to be confusing Revision Control / Asset Management with
source code editing. And while for smaller projects that may make some
sense, it breaks very quickly as the project size scales up.
The solution file for (just) our server systems has 21 top-level
projects (not counting ALL_BUILD, INSTALL and ZERO_CHECK). Because of
the high degree of code reuse and overlap, all of the host, client and
miscellaneous source codes sit side-by-side (although not in any one
single directory).
So importing "*/*.{h,hh,hpp}" into the CMakeLists file is nonsensical.
What I was hoping to achieve was a "Header Files" folder along side each
"Source Files" folder so that the headers were pertinent to any given
project within a solution.
http://www.kfs.org/~oliver/solution.jpg
___
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
Re: [CMake] header files with visual studio
Michael Jackson said the following on 11/4/2010 12:34 PM: Like, others have stated: You MUST include them in the add_executable or add_library call. The macro I give above can help keep those files organized in the Project/Solution file if you want the organization to mimic the file system for instance. Otherwise CMake will create the project will all the files in a single "Source" folder. HTH Thanks for the detailed response, Michael :) I guess I wasn't quite clear enough in the OP, I was really hoping it could be done automatically, perhaps through the dependency generator. Our project is fairly complex (it's a distributed client-server-server system with multiple distributed server processes each with their own project). A little over 5000 header files. And, never mind lines of code, there are 108,425 #include statements in our source tree. So, the question is actually: Is there a way to have CMake automatically add included headers to visual studio project files or do you need to use a dependency system to generate the lists by hand? - Oliver ___ 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
[CMake] header files with visual studio
Checked the faq and googled as much as I could but I couldn't find anything describing how to make visual studio include header files in the solution/project files? - Oliver ___ 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
Re: [CMake] This has to have been asked before...
Michael Wild said the following on 3/8/2010 1:35 PM: What I did is define custom functions that wrap add_executable, add_library and target_link_libraries. Works like a charm ;-) *DUH!* Thank you :) - Oliver ___ 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
Re: [CMake] Adding a generated source to all multiple targets
Tyler Roscoe said the following on 2/24/2010 6:50 PM:
I would write a wrapper for add_library() and/or add_executable() that
does the normal add_*() stuff and then also sets up the custom command
for generating the lua.*.cc files.
Ok - I just wanted to make sure there wasn't some built-in way of doing
it before I plowed ahead with that :)
I.e. the origin file is "lua.pkg";
For target "dbproxy" I want to run "tolua++ -n game
${db_proxy_definitions} ${common_definitions} -o
${Foo_BINARY_DIR}/lua.dbproxy.cc ${Foo_SOURCE_DIR}/lua.pkg"
For target "statsd" I want to run "tolua++ -n game ${statsd_definitions}
${common_definitions} -o ${Foo_BINARY_DIR}/lua.statsd.cc
${Foo_SOURCE_DIR}/lua.pkg"
If these are real examples from your code, I would strongly suggest
normalizing your variable names. If the target is called dbproxy then
Hehe, no, it's not :) And I didn't make it clear where I was just using
${...} to denote "stuff from another place" :)
making all the config variables for that target match the form
dbproxy_WHATEVER lets you say stuff like:
add_library(${this_target} ${${this_target}_SOURCE_FILES} ...)
Hmm - I didn't know you could do that, so I've been doing everything
project relative, but then the size of this project and the number of
sub-targets, and the huge amount of shared code between targets means
that things aren't really organized by target, so all of the targets sit
in one top-level project.
- Oliver
___
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
Re: [CMake] Adding a generated source to all multiple targets
David Cole said the following on 2/24/2010 1:25 AM:
Or this:
http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_generate_a_source_file_during_the_build.3F
Bizzare. That's where I started. I rolled out all of my changes, stepped
through recreating them based on the faq again, and this time it
works... I did an svn diff, none found...
That's half the problem solved -- the bulk of the post was, though: I
want to automatically generate one of these per-target, so that the
tolua runs with per-target compiler switches, and so that the resulting
.cc file is compiled with the per-target compile flags plus any specific
flags needed to compile that source.
I.e. the origin file is "lua.pkg";
For target "dbproxy" I want to run "tolua++ -n game
${db_proxy_definitions} ${common_definitions} -o
${Foo_BINARY_DIR}/lua.dbproxy.cc ${Foo_SOURCE_DIR}/lua.pkg"
For target "statsd" I want to run "tolua++ -n game ${statsd_definitions}
${common_definitions} -o ${Foo_BINARY_DIR}/lua.statsd.cc
${Foo_SOURCE_DIR}/lua.pkg"
And to add those .cc files to their respective targets. Obviously I can
do it by hand, duh, but I have a lot of targets, so before I do go add
it one at a time, I just want to be sure I'm not missing some mechanism
for saying "add a variation of this to all targets" or "add a variation
of this to this list of targets".
- Oliver
___
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
