[CMake] Is it possible to show dependent files in Visual Studio folders for ADD_CUSTOM_TARGET?
Hello all,
I hope you can help me answering whether the following is possible with CMake:
We have a set of C++ libraries, some of which are header-only.
Obviously those ones don't really need to be built, but it's
interesting to define targets for them anyway to define dependencies
in other executables libraries that depend on them.
Right now, my approach to define header-only libs is like:
add_custom_target(LIB_NAME DEPENDS ${LIST_OF_HEADERS})
But then the Visual Studio (or CodeBlock) folders don't show any of
the header files, only the CMakeLists.txt file and the CMake rules
folder.
I've tried with explicit calls to SOURCE_GROUP() without results.
I would be great to have the headers shown in the project folder for
quickly opening them for editing, launching all solution files
searches, etc.
Any idea on how to achieve this? Is it possible without modifying CMake sources?
Cheers,
Jose Luis
--
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] Is it possible to show dependent files in Visual Studio folders for ADD_CUSTOM_TARGET?
That's exactly what I was looking for, thanks Fraser!
JL
On Sat, Jan 19, 2013 at 12:17 PM, Fraser Hutchison
fraser.hutchi...@gmail.com wrote:
I think this is what the SOURCES arg is for. You could just duplicate the
list of DEPENDS files as the SOURCES argument too:
add_custom_target(LIB_NAME DEPENDS ${LIST_OF_HEADERS} SOURCES
${LIST_OF_HEADERS})
Cheers,
Fraser.
--
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] Alternative IDL compiler, and adding non-present sources
Hi all! Issue 1: Porting an old project to CMake I realized there's no way to modify the predefined behavior when one adds an IDL file to a Visual Studio project, which is associating it to midl. In our project we'd rather need to execute a different IDL compiler (TAO_IDL), but declaring an add_custom_command i.e. in PREBUILD has no effect since the midl association is hard-coded in the generator. I am thinking on writing a patch for this, but prefer to have opinions about the preferred way to do it to be consistent with the rest of CMake commands and variables. Issue 2: Also related to the compilation of IDL files: If .cpp/.h files, which does not exist yet but will be built by the IDL compiler, are added to the project, CMake correctly complains about non-existing sources... Is there any way to force CMake to add them and trust us that those sources will exist someday? Thanks! Jose Luis -- ___ Jose-Luis Blanco-Claraco Phone: +34 952 132848 Dpto. Ingenieria de Sistemas y Automatica E.T.S.I. Telecomunicacion Fax: +34 952 133361 Universidad de Malaga Campus Universitario de Teatinos 29071 Malaga, Spain http://www.isa.uma.es/jlblanco ___ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Search paths for FooConfig.cmake files
Hello CMake developers!
I've been thinking it would be interesting that CMake could look for
FooConfig.cmake package files in some likely paths such as C:\Program
Files\Foo-XXX\ . This is for Windows, of course, but perhaps could be
extended to /opt/foo-XXX/ in Unix systems.
I've written a patch for this task:
http://public.kitware.com/Bug/view.php?id=8264
I know the order in which directories are searched IS an issue, and I
decided it's place seems to be between these two paths:
=
...
4. Search the standard system environment variables. This can be skipped
if NO_SYSTEM_ENVIRONMENT_PATH is passed. Path entries ending in /bin
or /sbin are automatically converted to their parent directories.
PATH
5. Typical instalation paths. For now this only applies to Windowsfor
the paths that match the following pattern (where name iscase
insensitive):
${ProgramFiles}/name* (W)
6. Search project build trees recently configured in a CMake GUI. This
can be skipped if NO_CMAKE_BUILDS_PATH is passed. It is intended for the
case when a user is building multiple dependent projects one after another.
...
=
I'd be glad of seeing this feature in future releases of CMake, so
please let me know if anyone see any compatibility problem in this patch
and how to deal with it.
Best,
JL
--
___
Jose-Luis Blanco-Claraco Phone: +34 952 132848
Dpto. Ingenieria de Sistemas y Automatica
E.T.S.I. Telecomunicacion Fax: +34 952 133361
Universidad de Malaga
Campus Universitario de Teatinos
29071 Malaga, Spain
http://www.isa.uma.es/jlblanco
___
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Fwd: Re: Why does dependency scanning in version 2.6 seem so slow?]
These are my results: All the details go below, but in two computers, both with cmake 2.6.0 (from the Ubuntu repositories), it takes ~ 50sec vs. 19sec to recompile when only one file changes... and the longest delay happens in the better PC, though the CPU's are very similar in speeds. Both cases are local file systems (through ntfs, but the same in both cases). In addition, I started with a fresh CMAKE_BINARY_DIR directory in both cases. Please, let me know if I can do any more logging. Regards, JL = PC #1 DESKTOP PC, QuadCore 2.4Ghz: = == touch'ing just one .cpp file in the project, the time make VERBOSE=1 gives: 49.882s cd /home/jlblanco/code/mrpt-release /usr/local/bin/cmake -E cmake_depends Unix Makefiles /home/jlblanco/code/mrpt-src /home/jlblanco/code/mrpt-src/src/core /home/jlblanco/code/mrpt-release /home/jlblanco/code/mrpt-release/src/core /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/DependInfo.cmake --color= Most of the time goes in these 3 steps: Dependee /home/jlblanco/code/mrpt-src/src/core/math/CMatrix.cpp is newer than depender src/core/CMakeFiles/mrpt-core.dir/math/CMatrix.o. Clearing dependencies in /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/depend.make. Clearing dependencies in /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/depend.make. Scanning dependencies of target mrpt-core Longest task real0m49.882s user0m5.424s sys0m7.064s == without touching (just realizing there's nothing to do): 12.89s Most of the time goes in: cd /home/jlblanco/code/mrpt-release /usr/local/bin/cmake -E cmake_depends Unix Makefiles /home/jlblanco/code/mrpt-src /home/jlblanco/code/mrpt-src/src/core /home/jlblanco/code/mrpt-release /home/jlblanco/code/mrpt-release/src/core /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/DependInfo.cmake --color= real0m12.896s user0m1.384s sys0m1.560s = PC # 2 LAPTOP PC, DualCore 2.0Ghz: = == touch'ing just one .cpp file in the project, the time make VERBOSE=1 gives: 18.78s Most of the tiime goes to: cd /home/jlblanco/code/mrpt-release /usr/bin/cmake -E cmake_depends Unix Makefiles /home/jlblanco/code/mrpt-src /home/jlblanco/code/mrpt-src/src/core /home/jlblanco/code/mrpt-release /home/jlblanco/code/mrpt-release/src/core /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/DependInfo.cmake --color= Dependee /home/jlblanco/code/mrpt-src/src/core/utils/CMRPTImage.cpp is newer than depender src/core/CMakeFiles/mrpt-core.dir/utils/CMRPTImage.o. Clearing dependencies in /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/depend.make. Scanning dependencies of target mrpt-core real0m18.788s user0m7.456s sys0m4.552s == without touching (just realizing there's nothing to do): 2.23s real0m2.234s user0m1.468s sys0m0.528s On Thu, Dec 4, 2008 at 4:02 AM, Bill Hoffman [EMAIL PROTECTED]wrote: Jose Luis Blanco wrote: If this helps anyone, I'm working on a large project using CMake and in two different computers, both with the same version of Ubuntu and cmake, it is *REALLY SLOW* in only one of them while scanning dependencies, but it's not in the other laptop. (The slow dep. scanning is ~1 min. too) I'd be happy to help debugging this, because it's really annoying :-( I wonder if it is hitting a network mount disk or something like that... Are the same versions of cmake identical binaries? -Bill -- ___ Jose-Luis Blanco-Claraco Phone: +34 952 132848 Dpto. Ingenieria de Sistemas y Automatica E.T.S.I. Telecomunicacion Fax: +34 952 133361 Universidad de Malaga Campus Universitario de Teatinos 29071 Malaga, Spain http://www.isa.uma.es/jlblanco ___ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Fwd: Re: Why does dependency scanning in version 2.6 seem so slow?]
If this helps anyone, I'm working on a large project using CMake and in two different computers, both with the same version of Ubuntu and cmake, it is *REALLY SLOW* in only one of them while scanning dependencies, but it's not in the other laptop. (The slow dep. scanning is ~1 min. too) I'd be happy to help debugging this, because it's really annoying :-( Regards, Jose Luis On Thu, Dec 4, 2008 at 12:46 AM, Senanu Pearson [EMAIL PROTECTED]wrote: Hi folks, Is there a way to speed up the dependency scan in version 2.6? I recently installed a new Linux OS (Mandriva 2009) which included an upgrade to cmake 2.6 (I _think_ I had version 2.4 before). However, when I run make (after running cmake .) it takes a long time (1min) to do the dependency scan. (i.e. the time when the message Scanning dependencies of target foo is printed) whereas the rest of the build takes about 10 seconds. This happens every time I run make but it does successfully build (and the cmake . step is fast). I did not experienced such slow down when going from 2.4 to 2.6 would you be able to try a CMake 2.4 on the same system? You may 1) download a tarball http://www.cmake.org/files/v2.4/cmake-2.4.8-Linux-i386.tar.gz 2) untar it somewhere, 3) update you path 4) retry the build. The odd thing is that it was almost instantaneous (with essentially the same code) under version 2.4 and is almost instantaneous on a (faster) mac (again, with the same code). CMake is not the only thing which have changed then: - system - compiler -- this may be important. - disk speed, cpu, ..; -- Erk Erk, Yes, you are right - the 2.4 build doesn't seem to be any faster. All my hardware is the same but I'm using gcc 4.3.2 and KDE4. Still, it seems strange that it is so incredibly slow. Unless anyone can offer a better solution, I'm inclined to simply switch targets in the Makefile so that I can get a quick build without having to do quite as much typing every time (yeah, and break my habit, too). Thank you, Mark ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- ___ Jose-Luis Blanco-Claraco Phone: +34 952 132848 Dpto. Ingenieria de Sistemas y Automatica E.T.S.I. Telecomunicacion Fax: +34 952 133361 Universidad de Malaga Campus Universitario de Teatinos 29071 Malaga, Spain http://www.isa.uma.es/jlblanco ___ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
