Re: [CMake] MSBuild and automatic project file regenation

[Bill Hoffman]

On 2/13/2012 11:26 AM, Michael Hertling wrote:


OK, I see. So, it's a shortcoming of VS, if I understand correctly: No
dependency of object files on project files, and I guess that this is
not amendable by the means of CMake.


...


I.e., in order to trigger a rebuild with VS, an actual change in the
sources must have taken place - good to know. Many thanks, Bill and
Aaron, for spending time on this issue.



So, I suppose you could configure a header file with all the options 
used put into a comment block, and then include that in all of your 
sources.  That would be a way of getting around the limitation in VS.


-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

[Michael Hertling]

On 02/09/2012 05:35 PM, Bill Hoffman wrote:
> 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.

OK, I see. So, it's a shortcoming of VS, if I understand correctly: No
dependency of object files on project files, and I guess that this is
not amendable by the means of CMake.

> 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 
> #include 
> 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@

I.e., in order to trigger a rebuild with VS, an actual change in the
sources must have taken place - good to know. Many thanks, Bill and
Aaron, for spending time on this issue.

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

[Bill Hoffman]

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 
#include 
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

[aaron . meadows]

n.c "#include 
int main(void)
{
  printf(\"%d\\n\",NUMBER);
  return 0;
}
")
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES COMPILE_DEFINITIONS NUMBER=1)


c:\dev2\TestProgs\CMake_Rebuild\b>cmake --build .
-- Configuring done
-- Generating done
-- Build 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\b>main.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 -G"Visual 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  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 " 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/ 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.vcp

Re: [CMake] MSBuild and automatic project file regenation

[Michael Hertling]

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 
> 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 " 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/ 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

[Michael Hertling]

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 
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 " 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/ 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

[Bill Hoffman]

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

[Michael Hertling]

On 01/10/2012 07:09 PM, Óscar Fuentes wrote:
> Michael Hertling 
> 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 .
> 
> 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

[Óscar Fuentes]

Michael Hertling 
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 .

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

[Michael Hertling]

On 01/09/2012 07:56 PM, Óscar Fuentes wrote:
> Michael Hertling 
> 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 .

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

[John Drescher]

On Mon, Jan 9, 2012 at 1:56 PM, Óscar Fuentes  wrote:
> Michael Hertling 
> 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

[Óscar Fuentes]

Michael Hertling 
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

[Michael Hertling]

On 01/09/2012 02:34 PM, David Cole wrote:
> On Sun, Jan 8, 2012 at 11:59 PM, Óscar Fuentes  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

[David Cole]

On Sun, Jan 8, 2012 at 11:59 PM, Óscar Fuentes  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