Re: [CMake] MSBuild and automatic project file regenation
On 01/13/2012 08:02 PM, Michael Hertling wrote:
On 01/13/2012 03:42 PM, Bill Hoffman wrote:
On 1/13/2012 9:10 AM, Michael Hertling wrote:
With CMake 2.8.7 and VS 2008, I can report the following findings:
(1) Starting out from within an empty build directory: cmake ..
followed by cmake --build . configures/builds as expected.
(2) Tweaking CMakeLists.txt file only and leaving sources alone.
(3) cmake --build . rebuilds the ZERO_CHECK target and, thus,
updates the project file to reflect the changes from (2).
However, the corresponding target is not rebuilt and,
thus, does not reflect the changes from (2).
(4) A further cmake --build . does *nothing* - definitely.
(5) To get the concerned target rebuilt, I need to apply
David's hint, i.e. cmake . cmake --build ., or
clean first, i.e. cmake --build . --clean-first.
Can you provide an example and how to reproduce this?
I find it hard to believe that
cmake --build .
cmake --build .
will not build everything.
I get that the ZERO_TARGET does not get things to reload, but I don't
see how the second build would not get things up to date. It has
nothing to do with the project files depending on the targets. I assume
something really changed and there really needs to be a rebuild? What
type of thing are you changing in the CMakeLists.txt?
-Bill
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
#include stdio.h
int main(void)
{
printf(\%d\\n\,NUMBER); return 0;
}
)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS NUMBER=0)
Steps to reproduce with CMake 2.8.7 and VS 2008:
(1) From within an empty build directory: cmake srcdir followed
by cmake --build . configures/builds correctly; Debug\main
yields 0 as expected.
(2) At the end of CMakeLists.txt, change NUMBER=0 to NUMBER=1.
(3) cmake --build . triggers the ZERO_CHECK target, regenerates
main.vcproj but doesn't use the latter for rebuilding main.
Accordingly, Debug\main still yields 0.
Assuming that MSBuild/devenv/whatever doesn't load the re-
generated project file into the currently running instance,
I can well understand this behavior, but:
(4) A further cmake --build . does nothing; in particular, it
does not rebuild main, and Debug\main still yields 0.
Here, I'd expect that the regenerated project file is
loaded and the associated target rebuilt.
(5) Rebuilding the main target can be achieved via David's hint
cmake . cmake --build . or by cleaning before, e.g. via
cmake --build . --clean-first. Afterwards, Debug\main
finally yields 1.
For additional information, if one modifies the main.vcproj file by
hand, a subsequent cmake --build . also does nothing, as well as
msbuild BUILD.sln /t:main or msbuild main.vcproj.
Regards,
Michael
Any findings w.r.t. this issue? Can anyone reproduce it? Is it actually
faulty behavior, possibly worth a bug report? If so, can it be fixed in
some way? David Cole mentioned something like that. Although this isn't
really disastrous, it would be quite nice if everything is up-to-date
after a cmake --build . command, as one is used to with Makefiles.
Regards,
Michael
--
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] MSBuild and automatic project file regenation
files have been written to: C:/dev2/TestProgs/CMake_Rebuild/b
Scanning dependencies of target main
[100%] Building C object CMakeFiles/main.dir/main.c.obj
main.c
Linking C executable main.exe
[100%] Built target main
c:\dev2\TestProgs\CMake_Rebuild\bmain.exe
1
-8-
---
One interesting difference I noticed was that when I went to try this
with 2.8.7 from a vs 2008 command prompt, it configured with vs 2010. I
had to specify -GVisual Studio 9 2008 to get the 2008 configuration.
Let me know if you want me to try anything else.
Aaron Meadows
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Michael Hertling
Sent: Thursday, February 09, 2012 8:52 AM
To: cmake@cmake.org
Subject: Re: [CMake] MSBuild and automatic project file regenation
On 01/13/2012 08:02 PM, Michael Hertling wrote:
On 01/13/2012 03:42 PM, Bill Hoffman wrote:
On 1/13/2012 9:10 AM, Michael Hertling wrote:
With CMake 2.8.7 and VS 2008, I can report the following findings:
(1) Starting out from within an empty build directory: cmake ..
followed by cmake --build . configures/builds as expected.
(2) Tweaking CMakeLists.txt file only and leaving sources alone.
(3) cmake --build . rebuilds the ZERO_CHECK target and, thus,
updates the project file to reflect the changes from (2).
However, the corresponding target is not rebuilt and,
thus, does not reflect the changes from (2).
(4) A further cmake --build . does *nothing* - definitely.
(5) To get the concerned target rebuilt, I need to apply
David's hint, i.e. cmake . cmake --build ., or
clean first, i.e. cmake --build . --clean-first.
Can you provide an example and how to reproduce this?
I find it hard to believe that
cmake --build .
cmake --build .
will not build everything.
I get that the ZERO_TARGET does not get things to reload, but I don't
see how the second build would not get things up to date. It has
nothing to do with the project files depending on the targets. I
assume something really changed and there really needs to be a
rebuild? What type of thing are you changing in the CMakeLists.txt?
-Bill
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR) PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c #include stdio.h int
main(void) {
printf(\%d\\n\,NUMBER); return 0; }
)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS NUMBER=0)
Steps to reproduce with CMake 2.8.7 and VS 2008:
(1) From within an empty build directory: cmake srcdir followed
by cmake --build . configures/builds correctly; Debug\main
yields 0 as expected.
(2) At the end of CMakeLists.txt, change NUMBER=0 to NUMBER=1.
(3) cmake --build . triggers the ZERO_CHECK target, regenerates
main.vcproj but doesn't use the latter for rebuilding main.
Accordingly, Debug\main still yields 0.
Assuming that MSBuild/devenv/whatever doesn't load the re-
generated project file into the currently running instance,
I can well understand this behavior, but:
(4) A further cmake --build . does nothing; in particular, it
does not rebuild main, and Debug\main still yields 0.
Here, I'd expect that the regenerated project file is
loaded and the associated target rebuilt.
(5) Rebuilding the main target can be achieved via David's hint
cmake . cmake --build . or by cleaning before, e.g. via
cmake --build . --clean-first. Afterwards, Debug\main
finally yields 1.
For additional information, if one modifies the main.vcproj file by
hand, a subsequent cmake --build . also does nothing, as well as
msbuild BUILD.sln /t:main or msbuild main.vcproj.
Regards,
Michael
Any findings w.r.t. this issue? Can anyone reproduce it? Is it actually
faulty behavior, possibly worth a bug report? If so, can it be fixed in
some way? David Cole mentioned something like that. Although this isn't
really disastrous, it would be quite nice if everything is up-to-date
after a cmake --build . command, as one is used to with Makefiles.
Regards,
Michael
--
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
This email was sent to you by Thomson Reuters, the global news and information
company. Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be the views of
Thomson Reuters.
--
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
Re: [CMake] MSBuild and automatic project file regenation
I took a look at this, and it is behaving as expected with VS. VS does
NOT have a depend on compile flags. You can change a .vcproj file and
the flags it uses all you want, and VS will NOT rebuild any files
because of that.
So, as far as VS is concerned your source file has not changed and does
not need to rebuild. I modified your example and --build works
perfectly (I change the NUMBER in the CMakeLists.txt and main is rebuilt
with one invocation of cmake --build .)
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c #include stdio.h
#include main.h
int main(void)
{
printf(\%d\\n\,NUMBER);
return 0;
}
)
include_directories(${CMAKE_BINARY_DIR})
ADD_EXECUTABLE(main main.c)
set(NUMBER 2)
configure_file(main.h.in main.h)
$ cat ../main.h.in
#define NUMBER @NUMBER@
--
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] MSBuild and automatic project file regenation
On 01/10/2012 07:09 PM, Óscar Fuentes wrote: Michael Hertling mhertl...@online.de writes: But aren't the issues related at least? Dunno. If I understand correctly, cmake --build invokes MSBuild which - loads the solution file and the project files, - reinvokes CMake via the ZERO_CHECK project/target to regenerate them if CMakeLists.txt has been modified, - does *not* use the regenerated ones for building, so the affected projects/targets are left inherently out-of-date. Yep. Moreover, even an additional subsequent cmake --build command doesn't rebuild; in fact, it does nothing, as though there is no dependency of a project/target on its own project file. That doesn't happen here. The next cmake --build works fine (cmake 2.8.4, VS 10) With CMake 2.8.7 and VS 2008, I can report the following findings: (1) Starting out from within an empty build directory: cmake .. followed by cmake --build . configures/builds as expected. (2) Tweaking CMakeLists.txt file only and leaving sources alone. (3) cmake --build . rebuilds the ZERO_CHECK target and, thus, updates the project file to reflect the changes from (2). However, the corresponding target is not rebuilt and, thus, does not reflect the changes from (2). (4) A further cmake --build . does *nothing* - definitely. (5) To get the concerned target rebuilt, I need to apply David's hint, i.e. cmake . cmake --build ., or clean first, i.e. cmake --build . --clean-first. As I've already said previously, this seems as if there's no dependency of the target on its own project file. Moreover, I don't understand why rebuilding the ZERO_CHECK project and reconfiguring with cmake . do obviously have different results - the latter makes cmake --build . rebuild, the former doesn't. If I understand correctly, the purpose of ZERO_CHECK is to rerun CMake in order to update the project files, so the cmake --build . from (4) - at the lastest - should rebuild the affected targets. AFAICS for now, it's solely David's hint, i.e. cmake . cmake --build ., that results in the project being actually rebuilt after CMakeLists.txt has changed, unless one uses the --clean-first option. If so, I would strongly support a feature request in this respect since, IMO, it's actually quite confusing that CMake's --build command does anything but rebuilding. I agree. Do you file a feature request / bug report? Nope. Personally, I'd like to be sure that after a cmake --build command, everything is up-to-date as it is with Makefiles, provided it can be realized with MSBuild at all. Obviously, how MSBuild works when the project files are regenerated on the fly is a bug. I have no idea about how hard is to fix it, though. Try http://www.cmake.org/pipermail/cmake/2011-November/047802.html. Hmmm... After reading your example, I can't say for sure that when `cmake --build' worked the second time here it didn't cointain changes on the source files too. CMake with VS 10 and/or MSBuild is pesky, apart from the problems MSBuild has on its own. I'm looking at using other generators that support parallel builds. JOM is not truly parallel (it only builds a toplevel target at once). Ninja looks like the right thing, but doesn't work on MS Windows. Perhaps, David Cole can give us some enlightenment; since he used to work for MS, he certainly has some intimate insights into the Visual World. ;-) Anyway, this issue is no catastrophe, provided one knows the trick with cmake . cmake --build ., but it is annoying and error-prone; usually, I'd expect that after cmake --build, every- thing is up-to-date. BTW, does cmake --build work correctly in this regard with other non-Makefile generators, notably XCode? Regards, Michael -- 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] MSBuild and automatic project file regenation
On 1/13/2012 9:10 AM, Michael Hertling wrote: With CMake 2.8.7 and VS 2008, I can report the following findings: (1) Starting out from within an empty build directory: cmake .. followed by cmake --build . configures/builds as expected. (2) Tweaking CMakeLists.txt file only and leaving sources alone. (3) cmake --build . rebuilds the ZERO_CHECK target and, thus, updates the project file to reflect the changes from (2). However, the corresponding target is not rebuilt and, thus, does not reflect the changes from (2). (4) A further cmake --build . does *nothing* - definitely. (5) To get the concerned target rebuilt, I need to apply David's hint, i.e. cmake . cmake --build ., or clean first, i.e. cmake --build . --clean-first. Can you provide an example and how to reproduce this? I find it hard to believe that cmake --build . cmake --build . will not build everything. I get that the ZERO_TARGET does not get things to reload, but I don't see how the second build would not get things up to date. It has nothing to do with the project files depending on the targets. I assume something really changed and there really needs to be a rebuild? What type of thing are you changing in the CMakeLists.txt? -Bill -- 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] MSBuild and automatic project file regenation
On 01/13/2012 03:42 PM, Bill Hoffman wrote:
On 1/13/2012 9:10 AM, Michael Hertling wrote:
With CMake 2.8.7 and VS 2008, I can report the following findings:
(1) Starting out from within an empty build directory: cmake ..
followed by cmake --build . configures/builds as expected.
(2) Tweaking CMakeLists.txt file only and leaving sources alone.
(3) cmake --build . rebuilds the ZERO_CHECK target and, thus,
updates the project file to reflect the changes from (2).
However, the corresponding target is not rebuilt and,
thus, does not reflect the changes from (2).
(4) A further cmake --build . does *nothing* - definitely.
(5) To get the concerned target rebuilt, I need to apply
David's hint, i.e. cmake . cmake --build ., or
clean first, i.e. cmake --build . --clean-first.
Can you provide an example and how to reproduce this?
I find it hard to believe that
cmake --build .
cmake --build .
will not build everything.
I get that the ZERO_TARGET does not get things to reload, but I don't
see how the second build would not get things up to date. It has
nothing to do with the project files depending on the targets. I assume
something really changed and there really needs to be a rebuild? What
type of thing are you changing in the CMakeLists.txt?
-Bill
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
#include stdio.h
int main(void)
{
printf(\%d\\n\,NUMBER); return 0;
}
)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS NUMBER=0)
Steps to reproduce with CMake 2.8.7 and VS 2008:
(1) From within an empty build directory: cmake srcdir followed
by cmake --build . configures/builds correctly; Debug\main
yields 0 as expected.
(2) At the end of CMakeLists.txt, change NUMBER=0 to NUMBER=1.
(3) cmake --build . triggers the ZERO_CHECK target, regenerates
main.vcproj but doesn't use the latter for rebuilding main.
Accordingly, Debug\main still yields 0.
Assuming that MSBuild/devenv/whatever doesn't load the re-
generated project file into the currently running instance,
I can well understand this behavior, but:
(4) A further cmake --build . does nothing; in particular, it
does not rebuild main, and Debug\main still yields 0.
Here, I'd expect that the regenerated project file is
loaded and the associated target rebuilt.
(5) Rebuilding the main target can be achieved via David's hint
cmake . cmake --build . or by cleaning before, e.g. via
cmake --build . --clean-first. Afterwards, Debug\main
finally yields 1.
For additional information, if one modifies the main.vcproj file by
hand, a subsequent cmake --build . also does nothing, as well as
msbuild BUILD.sln /t:main or msbuild main.vcproj.
Regards,
Michael
--
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] MSBuild and automatic project file regenation
Michael Hertling mhertl...@online.de writes: But aren't the issues related at least? Dunno. If I understand correctly, cmake --build invokes MSBuild which - loads the solution file and the project files, - reinvokes CMake via the ZERO_CHECK project/target to regenerate them if CMakeLists.txt has been modified, - does *not* use the regenerated ones for building, so the affected projects/targets are left inherently out-of-date. Yep. Moreover, even an additional subsequent cmake --build command doesn't rebuild; in fact, it does nothing, as though there is no dependency of a project/target on its own project file. That doesn't happen here. The next cmake --build works fine (cmake 2.8.4, VS 10) AFAICS for now, it's solely David's hint, i.e. cmake . cmake --build ., that results in the project being actually rebuilt after CMakeLists.txt has changed, unless one uses the --clean-first option. If so, I would strongly support a feature request in this respect since, IMO, it's actually quite confusing that CMake's --build command does anything but rebuilding. I agree. Do you file a feature request / bug report? Nope. Personally, I'd like to be sure that after a cmake --build command, everything is up-to-date as it is with Makefiles, provided it can be realized with MSBuild at all. Obviously, how MSBuild works when the project files are regenerated on the fly is a bug. I have no idea about how hard is to fix it, though. Try http://www.cmake.org/pipermail/cmake/2011-November/047802.html. Hmmm... After reading your example, I can't say for sure that when `cmake --build' worked the second time here it didn't cointain changes on the source files too. CMake with VS 10 and/or MSBuild is pesky, apart from the problems MSBuild has on its own. I'm looking at using other generators that support parallel builds. JOM is not truly parallel (it only builds a toplevel target at once). Ninja looks like the right thing, but doesn't work on MS Windows. -- 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] MSBuild and automatic project file regenation
On Sun, Jan 8, 2012 at 11:59 PM, Óscar Fuentes o...@wanadoo.es wrote: When MSBuild.exe is used (typically by cmake --build) for building a VS2010 project generated by cmake, it correctly invokes cmake for regenerating the project files if changes to the CMakeLists.txt files are detected. However, the build does not restart nor abort, so MSBuild continues using the outdated project files that it previously read, ending some time later with lots of error messages from the compiler or linker, hence wasting time, causing confusion and making difficult to notice that a regeneration had happened. Is there any trick for stopping MSBuild as soon as cmake ends regenerating the project files? -- 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 No trick, but to avoid this, perhaps we should change the --build handler to run the cmake configure generate step before calling out to MSBuild. You can easily do this yourself from the command line by adopting the pattern: cmake . cmake --build . --config Release This is a good idea for a feature request. Not sure if we should just always do that by default and provide a way to turn off with a --no-regenerate, or vice-versa with a --please-generate-first ... :-) HTH, David -- 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] MSBuild and automatic project file regenation
On 01/09/2012 02:34 PM, David Cole wrote: On Sun, Jan 8, 2012 at 11:59 PM, Óscar Fuentes o...@wanadoo.es wrote: When MSBuild.exe is used (typically by cmake --build) for building a VS2010 project generated by cmake, it correctly invokes cmake for regenerating the project files if changes to the CMakeLists.txt files are detected. However, the build does not restart nor abort, so MSBuild continues using the outdated project files that it previously read, ending some time later with lots of error messages from the compiler or linker, hence wasting time, causing confusion and making difficult to notice that a regeneration had happened. Is there any trick for stopping MSBuild as soon as cmake ends regenerating the project files? -- 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 No trick, but to avoid this, perhaps we should change the --build handler to run the cmake configure generate step before calling out to MSBuild. You can easily do this yourself from the command line by adopting the pattern: cmake . cmake --build . --config Release This is a good idea for a feature request. Not sure if we should just always do that by default and provide a way to turn off with a --no-regenerate, or vice-versa with a --please-generate-first ... :-) HTH, David Just out of curiosity: In [1], item (1), I reported on the fact that one can modify a project's CMakeLists.txt, and cmake --build will reconfigure/regenerate, but not rebuild. Is this the same issue the OP asks about? If so, I would strongly support a feature request in this respect since, IMO, it's actually quite confusing that CMake's --build command does anything but rebuilding. Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg39596.html -- 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] MSBuild and automatic project file regenation
Michael Hertling mhertl...@online.de writes: On 01/09/2012 02:34 PM, David Cole wrote: No trick, but to avoid this, perhaps we should change the --build handler to run the cmake configure generate step before calling out to MSBuild. You can easily do this yourself from the command line by adopting the pattern: cmake . cmake --build . --config Release Fortunately my cmake scripts are simple enough so the extra invocation does not add much to the build. Thanks David. This is a good idea for a feature request. Not sure if we should just always do that by default and provide a way to turn off with a --no-regenerate, or vice-versa with a --please-generate-first ... :-) The effect of --no-regenerate would be the same as the current buggy behavior (MSBuild.exe uses outdated project files). IMHO the --please-generate-first is the right thing. Just out of curiosity: In [1], item (1), I reported on the fact that one can modify a project's CMakeLists.txt, and cmake --build will reconfigure/regenerate, but not rebuild. Is this the same issue the OP asks about? No. If so, I would strongly support a feature request in this respect since, IMO, it's actually quite confusing that CMake's --build command does anything but rebuilding. I agree. [1] http://www.mail-archive.com/cmake@cmake.org/msg39596.html This returns 404. -- 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] MSBuild and automatic project file regenation
On Mon, Jan 9, 2012 at 1:56 PM, Óscar Fuentes o...@wanadoo.es wrote: Michael Hertling mhertl...@online.de writes: On 01/09/2012 02:34 PM, David Cole wrote: No trick, but to avoid this, perhaps we should change the --build handler to run the cmake configure generate step before calling out to MSBuild. You can easily do this yourself from the command line by adopting the pattern: cmake . cmake --build . --config Release Fortunately my cmake scripts are simple enough so the extra invocation does not add much to the build. Thanks David. This is a good idea for a feature request. Not sure if we should just always do that by default and provide a way to turn off with a --no-regenerate, or vice-versa with a --please-generate-first ... :-) The effect of --no-regenerate would be the same as the current buggy behavior (MSBuild.exe uses outdated project files). IMHO the --please-generate-first is the right thing. One problem I have with doing this automatically in the --build command is I run in parallel builds for each configuration (using a program called RunJobs from codeproject.com): cmake --build X:/64Bit/VC.100/Qt/StudyManager --config RelWithDebInfo cmake --build X:/64Bit/VC.100/Qt/StudyManager --config Release cmake --build X:/64Bit/VC.100/Qt/StudyManager --config Debug for this I do the cmake X:/64Bit/VC.100/Qt/StudyManager step first then run the parallel jobs. I worry if --build forced a configure that parallel building like this could break. John -- 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] MSBuild and automatic project file regenation
On 01/09/2012 07:56 PM, Óscar Fuentes wrote: Michael Hertling mhertl...@online.de writes: On 01/09/2012 02:34 PM, David Cole wrote: No trick, but to avoid this, perhaps we should change the --build handler to run the cmake configure generate step before calling out to MSBuild. You can easily do this yourself from the command line by adopting the pattern: cmake . cmake --build . --config Release Fortunately my cmake scripts are simple enough so the extra invocation does not add much to the build. Thanks David. This is a good idea for a feature request. Not sure if we should just always do that by default and provide a way to turn off with a --no-regenerate, or vice-versa with a --please-generate-first ... :-) The effect of --no-regenerate would be the same as the current buggy behavior (MSBuild.exe uses outdated project files). IMHO the --please-generate-first is the right thing. Just out of curiosity: In [1], item (1), I reported on the fact that one can modify a project's CMakeLists.txt, and cmake --build will reconfigure/regenerate, but not rebuild. Is this the same issue the OP asks about? No. But aren't the issues related at least? If I understand correctly, cmake --build invokes MSBuild which - loads the solution file and the project files, - reinvokes CMake via the ZERO_CHECK project/target to regenerate them if CMakeLists.txt has been modified, - does *not* use the regenerated ones for building, so the affected projects/targets are left inherently out-of-date. Moreover, even an additional subsequent cmake --build command doesn't rebuild; in fact, it does nothing, as though there is no dependency of a project/target on its own project file. AFAICS for now, it's solely David's hint, i.e. cmake . cmake --build ., that results in the project being actually rebuilt after CMakeLists.txt has changed, unless one uses the --clean-first option. If so, I would strongly support a feature request in this respect since, IMO, it's actually quite confusing that CMake's --build command does anything but rebuilding. I agree. Do you file a feature request / bug report? Personally, I'd like to be sure that after a cmake --build command, everything is up-to-date as it is with Makefiles, provided it can be realized with MSBuild at all. [1] http://www.mail-archive.com/cmake@cmake.org/msg39596.html This returns 404. Try http://www.cmake.org/pipermail/cmake/2011-November/047802.html. Regards, Michael -- 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
