[CMake] Using Eclipse CDT, CMake resets Eclipse project configuration frequently
Hi, I have created an out-of-source build tree (on Windows), with the installation directory as a subfolder of the build trees. The idea is that the compiled binary requires some DLL's, images, 3D models and configuration files, at a location relative to the executable. If the files are changed, they will be copied from the source tree to the installation tree again. Therefore, I need to run make install all before running the executable. Because of the executable's dependency on the other files, I always want to build and install. (I don't expect a built file to work in itself because it won't be able to find the required files) However, sometimes the project settings are reset (I guess they are re-generated by cmake), so that I have to manually set it to do make install all again instead of make all. Does anyone know a way to enforce the install after every build? Or does anyone know a better way to make sure all the required files are updated from the src to the build tree if necessary? My layout is as follows: Src Source code directory tree Debug Debug-configured CDT project, which links to the src Debug/installation Installation directory (all required files, dlls and binaries are copied here) ReleaseRelease-configured CDT project, which links to the src Release/installation Installation directory (all required files, dlls and binaries are copied here) Jonatan - This e-mail is intended exclusively for the addressee. If you are not the addressee you must not read, copy, use or disclose the e-mail nor the content; please notify us immediately [by clicking 'Reply'] and delete this e-mail. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using Eclipse CDT, CMake resets Eclipse project configuration frequently
On 26. Jan, 2009, at 12:24, Jonatan Bijl wrote:
Hi,
I have created an out-of-source build tree (on Windows), with the
installation directory as a subfolder of the build trees. The idea is
that the compiled binary requires some DLL's, images, 3D models and
configuration files, at a location relative to the executable. If the
files are changed, they will be copied from the source tree to the
installation tree again. Therefore, I need to run make install all
before running the executable. Because of the executable's
dependency on
the other files, I always want to build and install. (I don't expect a
built file to work in itself because it won't be able to find the
required files)
In such a situation I usually try to configure_file things into the
build tree such that I can run the executable from the build tree.
Also setting EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH for this
purpose is very useful. If I need to configure some files differently
for the build and install tree, I configure them twice into separate
directories (the latter e.g. under ${CMAKE_BINARY_DIR}/InstallFiles).
This way I can have different versions of the configured files for the
build and install tree.
However, sometimes the project settings are reset (I guess they are
re-generated by cmake), so that I have to manually set it to do make
install all again instead of make all.
Does anyone know a way to enforce the install after every build?
Or does anyone know a better way to make sure all the required files
are
updated from the src to the build tree if necessary?
As I said, configure_file does the job. If the original file changed,
the process will be repeated. If you only need to copy a certain file,
you can use the COPY_ONLY option.
HTH
Michael
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Buggy progress reporting
Gopala Krishna wrote: On Mon, Jan 26, 2009 at 2:29 AM, Bill Hoffman bill.hoff...@kitware.com wrote: The progress reporting only supports one make at a time in the build tree. -Bill Is there any documentation somewhere on how the percentage reporting is implemented ? If not it would really be helpful atleast to get a hint on which source files to look at. :) No, not really, it uses a directory to communicate, and cmake -E cmake_progress_start. If you grep for progress in the source tree and look at the Makefiles you can get the idea. It is going to be very hard to make it work with more than one make in a tree. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using Eclipse CDT, CMake resets Eclipse project configuration frequently
My personal suggestion would be to use the plain MakeFiles generator
and then inside eclipse create a C++ Makefile project. You can then
point the project settings at the build directory to find the makefile
and also tell eclipse to use make all install as the build command
instead of plain make.
Then implement everything that was suggested below. You should be
able to create the CMake file in such a way as to have all the needed
files to run your application from the build tree.
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Jan 26, 2009, at 7:22 AM, Michael Wild wrote:
On 26. Jan, 2009, at 12:24, Jonatan Bijl wrote:
Hi,
I have created an out-of-source build tree (on Windows), with the
installation directory as a subfolder of the build trees. The idea is
that the compiled binary requires some DLL's, images, 3D models and
configuration files, at a location relative to the executable. If the
files are changed, they will be copied from the source tree to the
installation tree again. Therefore, I need to run make install all
before running the executable. Because of the executable's
dependency on
the other files, I always want to build and install. (I don't
expect a
built file to work in itself because it won't be able to find the
required files)
In such a situation I usually try to configure_file things into
the build tree such that I can run the executable from the build
tree. Also setting EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH
for this purpose is very useful. If I need to configure some files
differently for the build and install tree, I configure them twice
into separate directories (the latter e.g. under ${CMAKE_BINARY_DIR}/
InstallFiles). This way I can have different versions of the
configured files for the build and install tree.
However, sometimes the project settings are reset (I guess they are
re-generated by cmake), so that I have to manually set it to do make
install all again instead of make all.
Does anyone know a way to enforce the install after every build?
Or does anyone know a better way to make sure all the required
files are
updated from the src to the build tree if necessary?
As I said, configure_file does the job. If the original file
changed, the process will be repeated. If you only need to copy a
certain file, you can use the COPY_ONLY option.
HTH
Michael
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Buggy progress reporting
Bill Hoffman bill.hoff...@kitware.com writes: Gopala Krishna wrote: On Mon, Jan 26, 2009 at 2:29 AM, Bill Hoffman bill.hoff...@kitware.com wrote: The progress reporting only supports one make at a time in the build tree. -Bill Is there any documentation somewhere on how the percentage reporting is implemented ? If not it would really be helpful atleast to get a hint on which source files to look at. :) No, not really, it uses a directory to communicate, and cmake -E cmake_progress_start. If you grep for progress in the source tree and look at the Makefiles you can get the idea. It is going to be very hard to make it work with more than one make in a tree. If the directory used for communication had a pid as part of its name, wouldn't that solve it? Or is it more complicated than that? (I'm just curious.) -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Build-order in Visual Studio
Hello, is it possible to influence the build-order of MSVC from CMakeLists.txt-files? The top-level CMakeLists.txt looks like this: ADD_SUBDIRECTORY(lib1) ADD_SUBDIRECTORY(lib2) ADD_SUBDIRECTORY(lib3) ADD_SUBDIRECTORY(lib4) ADD_SUBDIRECTORY(prog) prog depends on the libs. lib3 depends on lib1 and lib4 depends on lib2. After a cMake-run the build-order in Visual Studio is pure random, even the main-program is sometimes ZERO_CHECK. Michael ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Buggy progress reporting
On 26. Jan, 2009, at 15:05, Jesper Eskilson wrote: Bill Hoffman bill.hoff...@kitware.com writes: Gopala Krishna wrote: On Mon, Jan 26, 2009 at 2:29 AM, Bill Hoffman bill.hoff...@kitware.com wrote: The progress reporting only supports one make at a time in the build tree. -Bill Is there any documentation somewhere on how the percentage reporting is implemented ? If not it would really be helpful atleast to get a hint on which source files to look at. :) No, not really, it uses a directory to communicate, and cmake -E cmake_progress_start. If you grep for progress in the source tree and look at the Makefiles you can get the idea. It is going to be very hard to make it work with more than one make in a tree. If the directory used for communication had a pid as part of its name, wouldn't that solve it? Or is it more complicated than that? (I'm just curious.) Lets say with process 1000 is building target A. Process 2000 is building target B at the same time. What happens if both depended on target C (e.g. a library) and tried to build it at the same time without knowing that there is another process trying to do the very same thing. This might lead to very buggy builds... I don't think this is anything CMake could ever possibly handle, as it also very strongly depends on the native build system (Make, VS, Xcode,...) Michael ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Build-order in Visual Studio
Micha, Use *target_link_librarieshttp://www.cmake.org/cmake/help/cmake2.6docs.html#command:target_link_libraries * and *add_dependencieshttp://www.cmake.org/cmake/help/cmake2.6docs.html#command:add_dependencies * to fix project build order. 2009/1/26 Micha Renner micha.ren...@t-online.de Hello, is it possible to influence the build-order of MSVC from CMakeLists.txt-files? The top-level CMakeLists.txt looks like this: ADD_SUBDIRECTORY(lib1) ADD_SUBDIRECTORY(lib2) ADD_SUBDIRECTORY(lib3) ADD_SUBDIRECTORY(lib4) ADD_SUBDIRECTORY(prog) prog depends on the libs. lib3 depends on lib1 and lib4 depends on lib2. After a cMake-run the build-order in Visual Studio is pure random, even the main-program is sometimes ZERO_CHECK. Michael ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Buggy progress reporting
Michael Wild them...@gmail.com writes: On 26. Jan, 2009, at 15:05, Jesper Eskilson wrote: Bill Hoffman bill.hoff...@kitware.com writes: Gopala Krishna wrote: On Mon, Jan 26, 2009 at 2:29 AM, Bill Hoffman bill.hoff...@kitware.com wrote: The progress reporting only supports one make at a time in the build tree. -Bill Is there any documentation somewhere on how the percentage reporting is implemented ? If not it would really be helpful atleast to get a hint on which source files to look at. :) No, not really, it uses a directory to communicate, and cmake -E cmake_progress_start. If you grep for progress in the source tree and look at the Makefiles you can get the idea. It is going to be very hard to make it work with more than one make in a tree. If the directory used for communication had a pid as part of its name, wouldn't that solve it? Or is it more complicated than that? (I'm just curious.) Lets say with process 1000 is building target A. Process 2000 is building target B at the same time. What happens if both depended on target C (e.g. a library) and tried to build it at the same time without knowing that there is another process trying to do the very same thing. This might lead to very buggy builds... I don't think this is anything CMake could ever possibly handle, as it also very strongly depends on the native build system (Make, VS, Xcode,...) You're right, of course. (Since Bill said that the progress meter only supported one build at a time, my brain started thinking how that could be implemented, without considering the rest of the build system.) -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Build-order in Visual Studio
Am Montag, den 26.01.2009, 16:22 +0200 schrieb Dmytro Ovdiienko: Micha, Use target_link_libraries and add_dependencies to fix project build order. I think, that this doesn't work in the case here. For target_link_libraries I need a library. If prog is first in build process then there are no libs. add_dependencies helps if all projects would be in one CMakeList-file. Michael ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] test executable failing only when run in ctest
I've come across a test on the VXL dashboard that seems to segfault only on some test machines. http://www.cdash.org/CDash/testSummary.php?project=12name=bvxm_test_apm_processorsdate=2009-01-26 One of the failing machines is mine (Mac_OS_X-10.5.6_unix_make). When I run the same test executable from the command line, all the tests pass and there is no segfault. Strangely, the segfault only occurs when the executable is run by ctest. I can reproduce the dashboard results by running ctest in the executable's directory. Has anyone seen anything like this before? Any suggestions on how to debug this? Thanks, Matt ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] test executable failing only when run in ctest
Matthew Leotta wrote: I've come across a test on the VXL dashboard that seems to segfault only on some test machines. http://www.cdash.org/CDash/testSummary.php?project=12name=bvxm_test_apm_processorsdate=2009-01-26 One of the failing machines is mine (Mac_OS_X-10.5.6_unix_make). When I run the same test executable from the command line, all the tests pass and there is no segfault. Strangely, the segfault only occurs when the executable is run by ctest. I can reproduce the dashboard results by running ctest in the executable's directory. Has anyone seen anything like this before? Any suggestions on how to debug this? Hack the test command line to run gdb on the test executable. Then run the test inside it by hand. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Will CMP0003 OLD become deprecated?
Hi all, I am currently migrating a project to CMake, and have been linking targets to project libraries using full paths (i.e., embracing the NEW CMP0003 policy of CMake = 2.6). However, my co-workers are reluctant to embrace this because the old CMP0003 policy has not yet yielded incorrect results, and because of the extra hassle of specifying full paths or link_directories(...) . So, I wanted to ask this list if in the (probably distant) future the old behavior will be deprecated. This would serve as an extra leverage to support the adoption of the NEW CMP0003 style. Thanks in advance, Adolfo Rodríguez Tsouroukdissian. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Will CMP0003 OLD become deprecated?
Adolfo Rodríguez wrote: Hi all, I am currently migrating a project to CMake, and have been linking targets to project libraries using full paths (i.e., embracing the NEW CMP0003 policy of CMake = 2.6). However, my co-workers are reluctant to embrace this because the old CMP0003 policy has not yet yielded incorrect results, and because of the extra hassle of specifying full paths or link_directories(...) . So, I wanted to ask this list if in the (probably distant) future the old behavior will be deprecated. This would serve as an extra leverage to support the adoption of the NEW CMP0003 style. CMP0003 does not require that you use full paths. If you set the policy to NEW, and your stuff works (i.e. it builds and links), you are all set. You should not get any warnings, and things should be fine. So, no need to leverage for the NEW style, just use it. There are very rare cases where the NEW style will break something, and they are very easy to fix (just add an extra link_directories call). -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] test executable failing only when run in ctest
Brad, Thanks, but I'm not sure if I completely understand your suggestion. Let me clarify. If I run the test executable ./bvxm_test_all I get no errors and no segfault. I know how to debug this, but there is nothing to debug. If in the same directory I run ctest then the test will segfault. Even stranger, on some platforms the test passes, but when I run in ctest it fails (produces the wrong values) but does not segfault. On some other platforms everything seems to work both with and without ctest. I'm actually running only the specific test that fails (the 5th one) with ./bvxm_test_all test_amp_processors or ctest -V -I 5,5 but the results are the same. When I try to debug ctest I never hit breakpoints in bvxm_test_all because ctest spawns off a separate process for bvxm_test_all, and gdb is attached to ctest. I'm not much of an expert on using gdb from the command line, I usually debug with an IDE front end (XCode or KDevelop). --Matt On Jan 26, 2009, at 11:49 AM, Brad King wrote: Matthew Leotta wrote: I've come across a test on the VXL dashboard that seems to segfault only on some test machines. http://www.cdash.org/CDash/testSummary.php?project=12name=bvxm_test_apm_processorsdate=2009-01-26 One of the failing machines is mine (Mac_OS_X-10.5.6_unix_make). When I run the same test executable from the command line, all the tests pass and there is no segfault. Strangely, the segfault only occurs when the executable is run by ctest. I can reproduce the dashboard results by running ctest in the executable's directory. Has anyone seen anything like this before? Any suggestions on how to debug this? Hack the test command line to run gdb on the test executable. Then run the test inside it by hand. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] test executable failing only when run in ctest
Matthew Leotta wrote: Brad, Thanks, but I'm not sure if I completely understand your suggestion. Let me clarify. If I run the test executable ./bvxm_test_all I get no errors and no segfault. I know how to debug this, but there is nothing to debug. If in the same directory I run ctest then the test will segfault. Even stranger, on some platforms the test passes, but when I run in ctest it fails (produces the wrong values) but does not segfault. On some other platforms everything seems to work both with and without ctest. I'm actually running only the specific test that fails (the 5th one) with ./bvxm_test_all test_amp_processors or ctest -V -I 5,5 but the results are the same. When I try to debug ctest I never hit breakpoints in bvxm_test_all because ctest spawns off a separate process for bvxm_test_all, and gdb is attached to ctest. I'm not much of an expert on using gdb from the command line, I usually debug with an IDE front end (XCode or KDevelop). add_test(run_xterm xterm) $ ctest -R run_xterm Then run gdb and the test inside the xterm to see if it fails. It could be an environment difference. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Will CMP0003 OLD become deprecated?
Adolfo Rodríguez wrote: I am currently migrating a project to CMake, and have been linking targets to project libraries using full paths (i.e., embracing the NEW CMP0003 policy of CMake = 2.6). However, my co-workers are reluctant to embrace this because the old CMP0003 policy has not yet yielded incorrect results, and because of the extra hassle of specifying full paths or link_directories(...) . So, I wanted to ask this list if in the (probably distant) future the old behavior will be deprecated. This would serve as an extra leverage to support the adoption of the NEW CMP0003 style. Yes, it may become deprecated in the (distant) future. The internal implementation of the policy mechanism defines a way to remove support for the OLD behavior of a policy and convert attempts to use it to an error. If you're looking for arguments: - Projects that need the OLD behavior technically have a bug. They specify a library to link without specifying the directory in which to search for the library. - Policies are for *compatibility* and are not intended as an API for selecting between two desirable behaviors. No one should write *new* code that needs the OLD behavior. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] test executable failing only when run in ctest
On Jan 26, 2009, at 3:04 PM, Brad King wrote: Matthew Leotta wrote: Brad, Thanks, but I'm not sure if I completely understand your suggestion. Let me clarify. If I run the test executable ./bvxm_test_all I get no errors and no segfault. I know how to debug this, but there is nothing to debug. If in the same directory I run ctest then the test will segfault. Even stranger, on some platforms the test passes, but when I run in ctest it fails (produces the wrong values) but does not segfault. On some other platforms everything seems to work both with and without ctest. I'm actually running only the specific test that fails (the 5th one) with ./bvxm_test_all test_amp_processors or ctest -V -I 5,5 but the results are the same. When I try to debug ctest I never hit breakpoints in bvxm_test_all because ctest spawns off a separate process for bvxm_test_all, and gdb is attached to ctest. I'm not much of an expert on using gdb from the command line, I usually debug with an IDE front end (XCode or KDevelop). add_test(run_xterm xterm) $ ctest -R run_xterm Then run gdb and the test inside the xterm to see if it fails. It could be an environment difference. -Brad It runs fine from within xterm when xterm is launched as a test by ctest. I suppose this means that the environment setup by ctest is not the culprit. Any other suggestions? Matt ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] test executable failing only when run in ctest
On Jan 26, 2009, at 3:29 PM, Matthew Leotta wrote: On Jan 26, 2009, at 3:04 PM, Brad King wrote: Matthew Leotta wrote: Brad, Thanks, but I'm not sure if I completely understand your suggestion. Let me clarify. If I run the test executable ./bvxm_test_all I get no errors and no segfault. I know how to debug this, but there is nothing to debug. If in the same directory I run ctest then the test will segfault. Even stranger, on some platforms the test passes, but when I run in ctest it fails (produces the wrong values) but does not segfault. On some other platforms everything seems to work both with and without ctest. I'm actually running only the specific test that fails (the 5th one) with ./bvxm_test_all test_amp_processors or ctest -V -I 5,5 but the results are the same. When I try to debug ctest I never hit breakpoints in bvxm_test_all because ctest spawns off a separate process for bvxm_test_all, and gdb is attached to ctest. I'm not much of an expert on using gdb from the command line, I usually debug with an IDE front end (XCode or KDevelop). add_test(run_xterm xterm) $ ctest -R run_xterm Then run gdb and the test inside the xterm to see if it fails. It could be an environment difference. -Brad It runs fine from within xterm when xterm is launched as a test by ctest. I suppose this means that the environment setup by ctest is not the culprit. Any other suggestions? Matt Does the test that fails take a long while to run? I asked because I have had to attach to a process using gdb on the command line (some IDE's allow you to do it also) while the test was running. Basically open a terminal and have 'top' running. Open another terminal and start up gdb in the gdb session type attach but NOTHING else, not even the return key. Now open a third xterm and start the testing with Ctest. Watch in the first xterm for the pid to appear. Quickly type the pid into the gdb xterm and hit return. If you did it fast enough then you are now attached to the actual test. Dig out your favorite gdb tutorial about stepping, stack traces and all that and have fun debugging. http://www.cs.princeton.edu/~benjasik/gdb/gdbtut.html is a short tutorial. --- Mike Jackson www.bluequartz.net ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] test executable failing only when run in ctest
Matthew Leotta wrote: On Jan 26, 2009, at 3:04 PM, Brad King wrote: add_test(run_xterm xterm) $ ctest -R run_xterm Then run gdb and the test inside the xterm to see if it fails. It could be an environment difference. -Brad It runs fine from within xterm when xterm is launched as a test by ctest. I suppose this means that the environment setup by ctest is not the culprit. Any other suggestions? It is also possible that the shell xterm starts changes the environment back. Try xterm -e gdb to run gdb directly in the terminal. Otherwise, there is always printf-style debugging :( -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Problem with FindwxWidgets.cmake
Hi,
I'm currently using CMake 2.6.2 and the FindwxWidgets.cmake module that
comes pre-packaged with the installation doesn't seem to properly work on
windows. I set CMAKE_PREFIX_PATH so that it would be able to find the
wxWidgets in a custom location. It does find wxWidgets_ROOT_DIR, but does
not find wxWidgets_LIB_DIR. We are using a unicode build of wxWidgets on
Windows, and our lib directory looks like:
${wxWidgets_ROOT_DIR}/lib/mswu/wx/setup.h
However, look at this snippet of code from FindwxWidgets.cmake:
FIND_PATH(wxWidgets_LIB_DIR
NAMES msw/build.cfg mswd/build.cfg
PATHS
${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_dll # prefer shared
${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_lib
DOC Path to wxWidgets libraries?
NO_DEFAULT_PATH
)
Notice it is only checking in msw and not mswu. Also, I do not have a
build.cfg file (I only keep relevant files inside my wxWidgets directory).
This file is enormous and complex, so I'm not even sure if this code is even
being used or if it matters.
The output I'm getting from the GUI CMake tool is:
CMake Error at C:/Program Files/CMake
2.6/share/cmake-2.6/Modules/FindPackageHandleStandardArgs.cmake:57
(MESSAGE):
Could NOT find wxWidgets (missing: wxWidgets_FOUND)
Call Stack (most recent call first):
C:/Program Files/CMake 2.6/share/cmake-2.6/Modules/FindwxWidgets.cmake:765
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
tools/tile_editor/CMakeLists.txt:1 (find_package)
Can anyone help me figure out what is going on? This thing *should* be
simple to use! Thanks.
___
CMake mailing list
CMake@cmake.org
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
