Re: [CMake] Header only libraries with code generated files...
I agree that is sounds like the right way and it is what I would like to use. However, before going through the work I just wanted to make sure it didn't suffer from the same quirks that add_custom_target does when dealing with code generation in different directory. As outlined in this blog post: https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/ -Kris -Original Message- From: Kyle Edwards [mailto:kyle.edwa...@kitware.com] Sent: Friday, June 28, 2019 11:31 AM To: Malfettone, Kris Cc: cmake@cmake.org Subject: Re: [CMake] Header only libraries with code generated files... It sounds like you want to use the INTERFACE version of target_include_directories(): https://cmake.org/cmake/help/latest/command/target_include_directories.html What this means is "anything that links against interface library foo will also need to add these paths to its include directories." You will also want to use add_dependencies() to make the interface library dependent on the generation steps: https://cmake.org/cmake/help/latest/command/add_dependencies.html Kyle On Fri, Jun 28, 2019 at 11:17 AM Malfettone, Kris wrote: > > Hi all, > > I had a question about managing code generated header only libraries is a > very large project. Currently, we have a very large project with many static > and many generated files. The problem I have is that due to the size of the > project many usages (exe’s and libraries) of those code generated files > (header files) are done in separate folders from the generation targets. > That leads me to have to be very careful and explicit with using > add_custom_command(…), add_custom_target(…), add_depenendcies(…), and > set_source_files_properties( … PROPERTIES GENERATED TRUE ). Most of that > knowledge / setup modeled after reading > https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/ > > > > I was wondering if I was able to simplify that by using Interface Libraries > and doing target_link_libraries( exe_name > MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ). I guess my > concerns were when adding the interface library to a target in another folder > would I still have to: > > · Manually add the transitive dependencies > > · Manually indicate that the generated files are code generated. > > > > > > I am also assuming my setup would be something like this when using Interface > Libraries…. > > 1. Still use add_custom_command/add_custom_target to do the generation > steps. > > 2. Add the interface library in the same folder as the generation > steps, managing its relationship with the code generation target via > add_dependencies() meaning most of the code generation quirks are avoided. > > 3. When adding executables or libraries in other folders just use > target_link_libraries( exe_name > MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ) > > a. Hoping that any transitive dependencies to the code generation steps > would be handled by exe_name being dependent on > MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES > > b. Also hoping that I wouldn’t have to specify which files are code > generated at that step > > > > I hope this makes sense. > > > > -Kris > > > > > IMPORTANT: The information contained in this email and/or its attachments is > confidential. If you are not the intended recipient, please notify the sender > immediately by reply and immediately delete this message and all its > attachments. Any review, use, reproduction, disclosure or dissemination of > this message or any attachment by an unintended recipient is strictly > prohibited. Neither this message nor any attachment is intended as or should > be construed as an offer, solicitation or recommendation to buy or sell any > security or other financial instrument. Neither the sender, his or her > employer nor any of their respective affiliates makes any warranties as to > the completeness or accuracy of any of the information contained herein or > that this message or any of its attachments is free of viruses. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware o
[CMake] Header only libraries with code generated files...
Hi all, I had a question about managing code generated header only libraries is a very large project. Currently, we have a very large project with many static and many generated files. The problem I have is that due to the size of the project many usages (exe's and libraries) of those code generated files (header files) are done in separate folders from the generation targets. That leads me to have to be very careful and explicit with using add_custom_command(...), add_custom_target(...), add_depenendcies(...), and set_source_files_properties( ... PROPERTIES GENERATED TRUE ). Most of that knowledge / setup modeled after reading https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/ I was wondering if I was able to simplify that by using Interface Libraries and doing target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ). I guess my concerns were when adding the interface library to a target in another folder would I still have to: * Manually add the transitive dependencies * Manually indicate that the generated files are code generated. I am also assuming my setup would be something like this when using Interface Libraries 1. Still use add_custom_command/add_custom_target to do the generation steps. 2. Add the interface library in the same folder as the generation steps, managing its relationship with the code generation target via add_dependencies() meaning most of the code generation quirks are avoided. 3. When adding executables or libraries in other folders just use target_link_libraries( exe_name MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ) a. Hoping that any transitive dependencies to the code generation steps would be handled by exe_name being dependent on MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES b. Also hoping that I wouldn't have to specify which files are code generated at that step I hope this makes sense. -Kris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Memory usage and configuration time for large project
I manage a very large project using CMake that I have done significant
restructuring to lower the CMake configure times. I will say the one thing
that surprised me the most is that for one piece of it where we have repeated
work done say “for each folder in this subdir build 11 executables with a ton
of code generation.” If I structure the build as such:
One top level CMakeLists.txt and one single line CMakeLists.txt in each subdir
containing do_work(${SUBDIR}):
foreach( SUBDIR ${LIST_OF_SUBDIRS} )
add_subdirectory(${SUBDIR})
endforeach()
Versus:
One top level CMakeLists.txt:
foreach( SUBDIR ${LIST_OF_SUBDIRS} )
do_work(${SUBDIR})
endforeach()
In short, the decision to do all the work in the same CMakeLists.txt file or do
I enter and leave a CMakeLists.txt for each directory causes a dramatic
performance and memory difference.
The add_subdirectory method saves many Gigs of RAM and reduces our configure
time from 30 minutes to 5 minutes. Please note I am writing this from memory
so my numbers may be a bit off but scale is accurate.
I don’t know if this is applicable to your case but it was the biggest saving
in my project and took a long time to figure out.
-Kris
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Isaiah Norton
Sent: Friday, May 04, 2018 7:51 PM
To: Patrick E Gartung
Cc: cmake@cmake.org
Subject: Re: [CMake] Memory usage and configuration time for large project
As one ballpark datapoint: a "superbuild" of 3D Slicer
(slicer.org) has a similar object and library count:
macbook-pro:s5nj inorton$ find ./ -name *.o | wc -l
14127
macbook-pro:s5nj inorton$ find ./ -name *.dylib -or -name *.so | wc -l
2158
Based on a few quick tests, the aggregate cmake time is probably about 6-8
minutes for the ninja generator, over the multi-hour build (each dependency is
configured and built as a separate sub-project via CMake's ExternalProject
mechanism) -- with the caveat that each of those cmake runs is doing lengthy
checks that should only be done once if your project strictly uses
`add_subdirectory`.
As a more concrete point of comparison, building VTK generates 5747 object
files, and a clean configure on my 2-core macbook takes about 90s.
Isaiah
On Fri, May 4, 2018 at 2:16 PM, Patrick E Gartung
> wrote:
Just to be clear, the memory and time used are just to configure and generate
the makefiles or Ninja file. The build itself can take several hours.
On 4/30/18, 4:55 PM, "R0b0t1" >
wrote:
On Mon, Apr 30, 2018 at 4:44 PM, Patrick E Gartung
> wrote:
> Hi,
>
> We have a large c/c++/fortran project, CMSSW, that is built with a custom
tool, scram.
>
> https://github.com/cms-sw/cmssw
>
> The project might move to a cmake based build in the future. The scripts
to convert to CmakeLists.tx has been written
>
> https://github.com/cms-sw/cmssw2cmake
>
> Tests show that with the cmake files generated with this script,
configuring the project uses up to 1.5GB of ram and takes 11 minutes when using
-GMakefiles. Using -GNinja and using the latest cmake, this time can be reduced
to 8 minutes.
>
> The project builds 14k object files, 2.2k libraries, ~600 binaries, 500
generated source files with links to ~100 external libraries.
>
> Is this amount of memory usage and time typical for a project of this
size?
>
I'm inclined to say "yes" as many builds such as Firefox, its
supporting libraries, and Chrome all take lots of time and memory.
Chrome uses Ninja, I might add. But the issue is not CMake itself.
CMake tends to produce better builds.
As I am not intimately familiar with your project, I can't make good
concrete suggestions. You may enjoy reading
https://news.ycombinator.com/item?id=14733829 and searching for build
optimization strategies.
Keep in mind a lot of the blame falls on C++ and Windows, should you
be using Windows. If you aren't using Windows, then the advice in the
comments above should still be relevant, and give you something to go
on.
Cheers,
R0b0t1
> Patrick Gartung
> Fermilab
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
[CMake] Best way to integrate sphinx documentation into a project with a large number of code generated sources...
Hi all, I have a very large project (many thousands of targets) that I manage with CMake. I currently, as part of my build, code generate the vast majority of sources and some sources are several layers deep of generation steps. I would like to add in a step to generate Sphinx documentation for my project but because the sphinx generation step must be run after all the various pieces have been generated, so it can parse the generated source files, it can be quite tedious to setup the CMake rules for it. For instance, the general gist is that I must make sure that the "generate sphinx" target has the proper dependencies on all the various number of pieces that need to build first. I was wondering if there was an alternative way for me to setup the "generate sphinx" target that I could more easily both ensure that my entire project is built first but not have to specify the dependencies anywhere as I add in more steps or targets into my process. For instance, one idea I was thinking of was if I modeled my project as two projects one the actual building and the other just the documentation generation. The second project could reference the other as an external project. Would that be a good way to go? Has anyone else dealt with this in the past? -Kris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...
Thank you Nils, will do. From: Nils Gladitz [mailto:nilsglad...@gmail.com] Sent: Wednesday, February 22, 2017 4:17 PM To: Malfettone, Kris <kris.malfett...@msx.bala.susq.com>; cmake@cmake.org Subject: Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules... On 22.02.2017 22:11, Malfettone, Kris wrote: Is there a bug tracker or somewhere that I should report this as well? I just want to make sure I put the right information in the right spot so the ninja generator maintainer might see it. I am not sure there is a dedicated maintainer for the Ninja generator currently but either way the users mailing list might not be the best place to reach the developers. The issue tracker is available here: https://gitlab.kitware.com/cmake/cmake/issues The developers mailing list here: https://cmake.org/mailman/listinfo/cmake-developers Nils IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...
Is there a bug tracker or somewhere that I should report this as well? I just want to make sure I put the right information in the right spot so the ninja generator maintainer might see it. From: Nils Gladitz [mailto:nilsglad...@gmail.com] Sent: Wednesday, February 15, 2017 9:41 AM To: Malfettone, Kris <kris.malfett...@msx.bala.susq.com>; cmake@cmake.org Subject: Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules... On 15.02.2017 15:16, Malfettone, Kris wrote: Just noticed a problem in my example. In my attempt to simplify my example I moved both outputs into the same folder which in my opinion is invalid because both output file names are the same. However, the same basic setup does reproduce the problem if you move the two targets into their own subdirs. I was just trying to avoid describing that in the email. Here is what I mean below: I thought you meant you had a target named "test" but apparently only your output is named that way. That certainly isn't covered by the existing policy. Nils IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...
Just noticed a problem in my example. In my attempt to simplify my example I
moved both outputs into the same folder which in my opinion is invalid because
both output file names are the same. However, the same basic setup does
reproduce the problem if you move the two targets into their own subdirs. I
was just trying to avoid describing that in the email. Here is what I mean
below:
Top level CMakeLists.txt:
cmake_minimum_required(VERSION 3.7)
enable_testing()
project("bugreproduce")
add_subdirectory("subdir")
add_subdirectory("subdir2")
subdir with CMakeLists.txt:
add_executable( "Foo.test" foo_test.cpp )
set_target_properties("Foo.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Foo.test" COMMAND test)
subdir2 with CMakeLists.txt:
add_executable( "Bar.test" bar_test.cpp )
set_target_properties("Bar.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Bar.test" COMMAND test )
Contents of both source files (obviously in their respective subdirectories):
int main( int, char** )
{
return 0;
}
Sorry for that.
From: Malfettone, Kris
Sent: Wednesday, February 15, 2017 9:07 AM
To: Malfettone, Kris <kris.malfett...@msx.bala.susq.com>; Nils Gladitz
<nilsglad...@gmail.com>; cmake@cmake.org
Subject: RE: [CMake] Potential bug: Having executables named "test" causes
Ninja generator to generate ambiguous rules...
So I was able to reproduce the problem with this very simple CMakeLists.txt
setup. I cannot attach source files due to my company's mail server
automatically stripping them out attachments with code but here is all you
would need to reproduce the problem:
Single CMakeLists.txt with the following:
cmake_minimum_required(VERSION 3.7)
enable_testing()
project("bugreproduce")
add_executable( "Foo.test" foo_test.cpp )
add_executable( "Bar.test" bar_test.cpp )
set_target_properties("Foo.test" PROPERTIES OUTPUT_NAME test )
set_target_properties("Bar.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Foo.test" COMMAND test)
add_test(NAME "Bar.test" COMMAND test )
Two source files named foo_test.cpp and bar_test.cpp both containing the
following code in the same directory:
int main( int, char** )
{
return 0;
}
If you generate a Makefile based solution everything works fine. However, if
you generate a ninja based solution then you get the following:
ninja: warning: multiple rules generate test. builds involving this target will
not be correct; continuing anyway [-w dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will
not be correct; continuing anyway [-w dupbuild=warn]
-Kris
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Malfettone, Kris
Sent: Wednesday, February 15, 2017 8:27 AM
To: Nils Gladitz <nilsglad...@gmail.com<mailto:nilsglad...@gmail.com>>;
cmake@cmake.org<mailto:cmake@cmake.org>
Subject: Re: [CMake] Potential bug: Having executables named "test" causes
Ninja generator to generate ambiguous rules...
Good to know. Thanks for the quick response. Though I do not believe I am
violating that particular rule here. That is why I do not receive either a
warning or error from CMake in my output.
The only warning I see is from ninja:
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_1/test.
builds involving this target will not be correct; continuing anyway [-w
dupbuild=warn]
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_2/test.
builds involving this target will not be correct; continuing anyway [-w
dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will
not be correct; continuing anyway [-w dupbuild=warn]
I think the difference is that my target names are:
MD.MDF.Formats.SIG.BCP.v0_1.test
MD.MDF.Formats.SIG.BCP.v0_2.test
It is the ninja generator that is trying to setup aliases for each of them as a
shortened form. So I think one of the following statements are true:
* The cmake rule intended for the above two target names to be invalid.
But the check to issue a warning or error has a bug causing them to be missed.
This would explain why I do not get the error in my configure results.
* The cmake rule intended for the above two target names to be valid.
However, on further reflection the rule should be made stricter to include my
target names above. This would then require and update to the cmake code
checking that policy and lead to me actually getting a warning or error from
cmake during configure.
* The ninja generator has a bug and is setting up ambiguous aliases for
what CMake considers valid target names.
My project is huge so I will try and craft a simplified CMakeLists.txt example
to reproduce the problem as well.
Does this make sense? Am I still missing something?
-Kris
Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...
So I was able to reproduce the problem with this very simple CMakeLists.txt
setup. I cannot attach source files due to my company's mail server
automatically stripping them out attachments with code but here is all you
would need to reproduce the problem:
Single CMakeLists.txt with the following:
cmake_minimum_required(VERSION 3.7)
enable_testing()
project("bugreproduce")
add_executable( "Foo.test" foo_test.cpp )
add_executable( "Bar.test" bar_test.cpp )
set_target_properties("Foo.test" PROPERTIES OUTPUT_NAME test )
set_target_properties("Bar.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Foo.test" COMMAND test)
add_test(NAME "Bar.test" COMMAND test )
Two source files named foo_test.cpp and bar_test.cpp both containing the
following code in the same directory:
int main( int, char** )
{
return 0;
}
If you generate a Makefile based solution everything works fine. However, if
you generate a ninja based solution then you get the following:
ninja: warning: multiple rules generate test. builds involving this target will
not be correct; continuing anyway [-w dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will
not be correct; continuing anyway [-w dupbuild=warn]
-Kris
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Malfettone, Kris
Sent: Wednesday, February 15, 2017 8:27 AM
To: Nils Gladitz <nilsglad...@gmail.com>; cmake@cmake.org
Subject: Re: [CMake] Potential bug: Having executables named "test" causes
Ninja generator to generate ambiguous rules...
Good to know. Thanks for the quick response. Though I do not believe I am
violating that particular rule here. That is why I do not receive either a
warning or error from CMake in my output.
The only warning I see is from ninja:
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_1/test.
builds involving this target will not be correct; continuing anyway [-w
dupbuild=warn]
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_2/test.
builds involving this target will not be correct; continuing anyway [-w
dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will
not be correct; continuing anyway [-w dupbuild=warn]
I think the difference is that my target names are:
MD.MDF.Formats.SIG.BCP.v0_1.test
MD.MDF.Formats.SIG.BCP.v0_2.test
It is the ninja generator that is trying to setup aliases for each of them as a
shortened form. So I think one of the following statements are true:
* The cmake rule intended for the above two target names to be invalid.
But the check to issue a warning or error has a bug causing them to be missed.
This would explain why I do not get the error in my configure results.
* The cmake rule intended for the above two target names to be valid.
However, on further reflection the rule should be made stricter to include my
target names above. This would then require and update to the cmake code
checking that policy and lead to me actually getting a warning or error from
cmake during configure.
* The ninja generator has a bug and is setting up ambiguous aliases for
what CMake considers valid target names.
My project is huge so I will try and craft a simplified CMakeLists.txt example
to reproduce the problem as well.
Does this make sense? Am I still missing something?
-Kris
From: Nils Gladitz [mailto:nilsglad...@gmail.com]
Sent: Wednesday, February 15, 2017 3:36 AM
To: Malfettone, Kris
<kris.malfett...@msx.bala.susq.com<mailto:kris.malfett...@msx.bala.susq.com>>;
cmake@cmake.org<mailto:cmake@cmake.org>
Subject: Re: [CMake] Potential bug: Having executables named "test" causes
Ninja generator to generate ambiguous rules...
On 14.02.2017 22:53, Malfettone, Kris wrote:
If so, are executables named "test" no longer supported?
Am I missing something or wrong in some way?
Issues existed before 3.0 but since 3.0 "test" and similarly problematic target
names have been explicitly reserved.
Any CMake Version >= 3.0 will issue a warning (when the required version is <
3.0) or an error (when the required version is >= 3.0) by default:
https://cmake.org/cmake/help/v3.8/policy/CMP0037.html
Nils
IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the sender
immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of this
message or any attachment by an unintended recipient is strictly prohibited.
Neither this message nor any attachment is intended as or should be construed
as an offer, solicitation or recommendation to buy or sell any security or
other financial instrument. Neither the sender, his or he
Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...
Good to know. Thanks for the quick response. Though I do not believe I am violating that particular rule here. That is why I do not receive either a warning or error from CMake in my output. The only warning I see is from ninja: ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_1/test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn] ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_2/test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn] ninja: warning: multiple rules generate test. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn] I think the difference is that my target names are: MD.MDF.Formats.SIG.BCP.v0_1.test MD.MDF.Formats.SIG.BCP.v0_2.test It is the ninja generator that is trying to setup aliases for each of them as a shortened form. So I think one of the following statements are true: * The cmake rule intended for the above two target names to be invalid. But the check to issue a warning or error has a bug causing them to be missed. This would explain why I do not get the error in my configure results. * The cmake rule intended for the above two target names to be valid. However, on further reflection the rule should be made stricter to include my target names above. This would then require and update to the cmake code checking that policy and lead to me actually getting a warning or error from cmake during configure. * The ninja generator has a bug and is setting up ambiguous aliases for what CMake considers valid target names. My project is huge so I will try and craft a simplified CMakeLists.txt example to reproduce the problem as well. Does this make sense? Am I still missing something? -Kris From: Nils Gladitz [mailto:nilsglad...@gmail.com] Sent: Wednesday, February 15, 2017 3:36 AM To: Malfettone, Kris <kris.malfett...@msx.bala.susq.com>; cmake@cmake.org Subject: Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules... On 14.02.2017 22:53, Malfettone, Kris wrote: If so, are executables named "test" no longer supported? Am I missing something or wrong in some way? Issues existed before 3.0 but since 3.0 "test" and similarly problematic target names have been explicitly reserved. Any CMake Version >= 3.0 will issue a warning (when the required version is < 3.0) or an error (when the required version is >= 3.0) by default: https://cmake.org/cmake/help/v3.8/policy/CMP0037.html Nils IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...
Hi, I am trying to migrate a very large project from cmake 2.8.11.2 + ninja 1.3.4 to cmake 3.7.2 + ninja 1.7.2 and found what might be a bug with the ninja generator. In my project we have a number of executables that are named "test". This is normally not a problem since each one as a different target name that is unique. However, with the move to CMake 3.7.2 the Ninja generator seems to generate ambiguous target aliases for the project. If I rename my outputs to something such as "testfoo", the problem goes away. Looking at the build.ninja that is generated there are clearly multiple ambiguous targets. One that I generates the output file named "test" and one I believe meant to run our unit tests. That second part I believe is what is different between the versions of CMake that I am using. The other thing is I believe even if those are removed there would be a final ambiguity between my executable and built in "test" command because the portion of the code the generates the section of the build.ninja file commented as "# Target aliases." seems to try and avoid ambiguities between targets but fails to consider built in cmake targets such as "test,install,install/strip,etc..." Again, I am not a build.ninja expert so I may be wrong in my understanding. Some further info, this does not occur on windows because on windows the targets all end with ".exe" and it does not happen with the Makefile generator on Linux. Is this expected behavior? If so, are executables named "test" no longer supported? Am I missing something or wrong in some way? Any help would be appreciated. Thanks, Kris Malfettone IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Correct way to make an arbitrary file trigger a reconfigure...
Thank you both for you responses.
As a side note, it might be nice to add a function to cmake along the lines of
add_cmake_cache_dependency(…) or some better name that just adds the dependency
without having to configure a dummy file.
-Kris
From: David Cole [mailto:dlrd...@aol.com]
Sent: Tuesday, October 15, 2013 8:55 AM
To: slekh...@gmail.com; kris.malfett...@sig.com
Cc: cmake@cmake.org
Subject: Re: [CMake] Correct way to make an arbitrary file trigger a
reconfigure...
Kris,
I would use your configure_file construct if I had a reason to do this. It will
work regardless of platform or CMake generator chosen... I would even go so far
as to call it the recommended way.
HTH,
David
-Original Message-
From: Sergey Lekhanov slekh...@gmail.commailto:slekh...@gmail.com
To: Kris Malfettone kris.malfett...@sig.commailto:kris.malfett...@sig.com
Cc: Kris Malfettone kris.malfett...@sig.commailto:kris.malfett...@sig.com;
cmake cmake@cmake.orgmailto:cmake@cmake.org
Sent: Mon, Oct 14, 2013 9:30 pm
Subject: Re: [CMake] Correct way to make an arbitrary file trigger a
reconfigure...
Hi Kris,
I have done that by following:
1) use Ninja Generator;
2) include empty rerun.cmake file, I put this file into binary dir, so I need
a patch;
3) add a patch to Ninja Generator to correctly write dependencies for
build.ninja from included cmake files, if cmake file is in the binary
directory;
4) add a custom commands that check the new files and touching rerun.cmake
file;
5) once rerun.cmake file is touched ninja will rerun cmake;
Best regards,
Sergey
—
Sent from Mailbox for iPhone
On Tue, Oct 15, 2013 at 7:02 AM, Malfettone, Kris
kris.malfett...@sig.commailto:kris.malfett...@sig.com wrote:
Anyone?
From: cmake-boun...@cmake.orgmailto:cmake-boun...@cmake.org
[mailto:cmake-boun...@cmake.org] On Behalf Of Malfettone, Kris
Sent: Thursday, October 03, 2013 8:43 AM
To: cmake@cmake.orgmailto:cmake@cmake.org
Subject: [CMake] Correct way to make an arbitrary file trigger a reconfigure...
Hi, I am trying to make cmake reconfigure whenever a certain file is touched.
This is because the file ends up listing out a set of directories that need to
be built during the build. Currently I do a trick where I use configure file
to write out a file that will never be used but causes the input file to
trigger reconfigures.
For example:
configure_file( file_i_care_about.txt
${CMAKE_CURRENT_BINARY_DIR}/tmp_file_that_isn’t_used.txt )
Is there another recommended way or is this the best approach. I have tried
searching for this but haven’t found anything on it yet.
-Kris
IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the sender
immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of this
message or any attachment by an unintended recipient is strictly prohibited.
Neither this message nor any attachment is intended as or should be construed
as an offer, solicitation or recommendation to buy or sell any security or
other financial instrument. Neither the sender, his or her employer nor any of
their respective affiliates makes any warranties as to the completeness or
accuracy of any of the information contained herein or that this message or any
of its attachments is free of viruses.
IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the sender
immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of this
message or any attachment by an unintended recipient is strictly prohibited.
Neither this message nor any attachment is intended as or should be construed
as an offer, solicitation or recommendation to buy or sell any security or
other financial instrument. Neither the sender, his or her employer nor any of
their respective affiliates makes any warranties as to the completeness or
accuracy of any of the information contained herein or that this message or any
of its attachments is free of viruses.
--
Powered by www.kitware.comhttp://www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Correct way to make an arbitrary file trigger a reconfigure...
Anyone?
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Malfettone, Kris
Sent: Thursday, October 03, 2013 8:43 AM
To: cmake@cmake.org
Subject: [CMake] Correct way to make an arbitrary file trigger a reconfigure...
Hi, I am trying to make cmake reconfigure whenever a certain file is touched.
This is because the file ends up listing out a set of directories that need to
be built during the build. Currently I do a trick where I use configure file
to write out a file that will never be used but causes the input file to
trigger reconfigures.
For example:
configure_file( file_i_care_about.txt
${CMAKE_CURRENT_BINARY_DIR}/tmp_file_that_isn't_used.txt )
Is there another recommended way or is this the best approach. I have tried
searching for this but haven't found anything on it yet.
-Kris
IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the sender
immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of this
message or any attachment by an unintended recipient is strictly prohibited.
Neither this message nor any attachment is intended as or should be construed
as an offer, solicitation or recommendation to buy or sell any security or
other financial instrument. Neither the sender, his or her employer nor any of
their respective affiliates makes any warranties as to the completeness or
accuracy of any of the information contained herein or that this message or any
of its attachments is free of viruses.
IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the sender
immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of this
message or any attachment by an unintended recipient is strictly prohibited.
Neither this message nor any attachment is intended as or should be construed
as an offer, solicitation or recommendation to buy or sell any security or
other financial instrument. Neither the sender, his or her employer nor any of
their respective affiliates makes any warranties as to the completeness or
accuracy of any of the information contained herein or that this message or any
of its attachments is free of viruses.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Correct way to make an arbitrary file trigger a reconfigure...
Hi, I am trying to make cmake reconfigure whenever a certain file is touched.
This is because the file ends up listing out a set of directories that need to
be built during the build. Currently I do a trick where I use configure file
to write out a file that will never be used but causes the input file to
trigger reconfigures.
For example:
configure_file( file_i_care_about.txt
${CMAKE_CURRENT_BINARY_DIR}/tmp_file_that_isn't_used.txt )
Is there another recommended way or is this the best approach. I have tried
searching for this but haven't found anything on it yet.
-Kris
IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the sender
immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of this
message or any attachment by an unintended recipient is strictly prohibited.
Neither this message nor any attachment is intended as or should be construed
as an offer, solicitation or recommendation to buy or sell any security or
other financial instrument. Neither the sender, his or her employer nor any of
their respective affiliates makes any warranties as to the completeness or
accuracy of any of the information contained herein or that this message or any
of its attachments is free of viruses.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generator Toolset fails
I have this same problem but didn’t see a response to this problem. Is there a fix for it? Or information related to it? -Kris From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Mike Sent: Wednesday, May 29, 2013 10:06 AM To: cmake@cmake.org Subject: [CMake] Generator Toolset fails Hello, I'm trying to generate a Visual Studio 11 solution using v100 toolset and it is failing to compile a test program: I run cmake -G Visual Studio 11 Win64 -T v100 path to source -- The C compiler identification is MSVC 16.0.40219.1 -- The CXX compiler identification is MSVC 16.0.40219.1 -- Check for working C compiler using: Visual Studio 11 Win64 -- Check for working C compiler using: Visual Studio 11 Win64 -- broken CMake Error at D:/vc11build/cmake-2.8.11/install/data/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler c:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/x86_amd64/cl.exe is not able to compile a simple test program. It fails with the following output: Change Dir: D:/vc11build/cmake-2.8.11/vc11w10-test/CMakeFiles/CMakeTmp Run Build Command:C:\PROGRA~2\MICROS~3.0\Common7\IDE\devenv.comhttp://devenv.com CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec2195211524 Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.60315.1. Copyright (C) Microsoft Corp. All rights reserved. The operation could not be completed. The parameter is incorrect. It then lists the devenv.comhttp://devenv.com usage parameters: devenv [solutionfile | projectfile | anyfile.ext] [switches] And so on. Finally: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:11 (project) -- Configuring incomplete, errors occurred! And so on. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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] Generator Toolset fails
Thank you, it works now and that is definitely a better work around. -Kris -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Thursday, June 13, 2013 5:01 PM To: Malfettone, Kris Cc: cmake@cmake.org; Mike Subject: Re: [CMake] Generator Toolset fails On 6/13/2013 4:36 PM, Malfettone, Kris wrote: Just wanted to add some extra information. I found a way to work around the problem by first generating with: cmake –G Visual Studio 11 path_to_src Then reconfiguring directly after with: cmake –G Visual Studio 11 -DCMAKE_GENERATOR_TOOLSET=v100 path_to_src I think the key to the workaround working is that while the –T command line argument checks for changes in CMAKE_GENERATOR_TOOLSET between configuring, using the cache variable does not. This also means the it doesn’t execute the try compile step again in the second configure step since it doesn’t think it needs to. Behavior for changing the toolset in an existing tree is not well-defined so this may not produce a fully consistent build. Run Build Command:C:\PROGRA~2\MICROS~3.0\Common7\IDE\devenv.com Try setting CMAKE_MAKE_PROGRAM to the path to msbuild instead of devenv, in a new run on a fresh build tree, along with the desired toolset. -Brad IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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] Ninja on windows ( latest ninja from git, cmake 2.8.9 )
So I think I found the issue. When the include directories are specified via the network path ( \\machine\dir\ ) vs. a drive letter ( N:\dir ) ninja always thinks they are out of date. This is a pretty big hurdle for us since our toolchain files can be mapped to different drives for different users so our builds reference the network paths. This seems like a bug in ninja, but it could also be a problem with the Windows APIs used to get the information. Any thoughts? -Kris -Original Message- From: Eric Noulard [mailto:eric.noul...@gmail.com] Sent: Tuesday, August 14, 2012 2:53 PM To: Malfettone, Kris Cc: David Cole; cmake@cmake.org Subject: Re: [CMake] Ninja on windows ( latest ninja from git, cmake 2.8.9 ) 2012/8/14 Malfettone, Kris kris.malfett...@sig.com: So I found the -d explain option of ninja and it says that it thinks my boost libraries / other library includes are dirty. The only think I can think of here is that they are on a network drive and not on my local machine. Any thoughts on that? If those two machines have time discrepancy (no time synchronization) then the file on the network share may appear to be in the future of your local file, your build tree is local right? Just try to check the date on the network file server w.r.t. to the time on your local machine. or copy the file locally and retry. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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] Ninja on windows ( latest ninja from git, cmake 2.8.9 )
Sure although you will need to map a network drive to properly recreate it.
In a project have:
CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(foo)
#include_directories(H:\\test)
include_directories(machine\\share\\test)
add_executable(foo main.cpp)
main.cpp
#include inc.h
int main( int, char ** )
{
return code(1);
}
Then on shared network folder test that contains:
inc.h
inline int code( int i ) { return i+1; }
To reproduce first build the project foo by trying to use the include directory
as: machine\\share\\test
Everything will work but it will always rebuild the project thinking inc.h is
dirty.
Then map a drive to machine\\share and change the include directory to
your newly mapped drive, ex. H:\\test
Then ninja will correctly determine that your project has nothing to do.
I know that it is probably a pain to setup this test, thank you for taking the
time to do it.
-Kris
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Bill Hoffman
Sent: Wednesday, August 15, 2012 4:36 PM
To: cmake@cmake.org
Subject: Re: [CMake] Ninja on windows ( latest ninja from git, cmake 2.8.9 )
On 8/15/2012 2:48 PM, Malfettone, Kris wrote:
So I think I found the issue. When the include directories are
specified via the network path ( \\machine\dir\ ) vs. a drive letter ( N:\dir )
ninja always thinks they are out of date. This is a pretty big hurdle for us
since our toolchain files can be mapped to different drives for different users
so our builds reference the network paths.
This seems like a bug in ninja, but it could also be a problem with
the Windows APIs used to get the information. Any thoughts?
If you could create a really small example of this and then send the binary
tree to me that would be helpful. It might be cmake might be ninja...
-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
IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the sender
immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of this
message or any attachment by an unintended recipient is strictly prohibited.
Neither this message nor any attachment is intended as or should be construed
as an offer, solicitation or recommendation to buy or sell any security or
other financial instrument. Neither the sender, his or her employer nor any of
their respective affiliates makes any warranties as to the completeness or
accuracy of any of the information contained herein or that this message or any
of its attachments is free of viruses.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Ninja on windows ( latest ninja from git, cmake 2.8.9 )
I am trying to use ninja on windows. Everything seems to work correctly ( compilation, linking, install rules, etc... ) except for testing whether or not a file has changed. No matter the state of the tree, ninja always builds the entire project. I tried searching the bug tracker and mailing list but did not see this noted before. I am doing an out of source build with visual studio 2010 64 bit. Is this a known issue? -Kris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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] Ninja on windows ( latest ninja from git, cmake 2.8.9 )
Nothing special in my opinion. I am trying to reproduce it with something simpler than my code base. With an ultra trivial CMake setup it works fine. Is there some sort of debugging I can enable to see why it thinks the files are changed? -Kris From: David Cole [mailto:david.c...@kitware.com] Sent: Tuesday, August 14, 2012 12:58 PM To: Malfettone, Kris Cc: cmake@cmake.org Subject: Re: [CMake] Ninja on windows ( latest ninja from git, cmake 2.8.9 ) Definitely not known. In fact, the opposite is true here on my ninja build trees for CMake itself. A no-op build results in a no work to do message from ninja. Is there anything unusual about your CMakeLists.txt files? Are your source files accidentally dated in the future? (Did you just return from a different time zone, or have a clock setting mishap of some sort?) On Tue, Aug 14, 2012 at 12:07 PM, Malfettone, Kris kris.malfett...@sig.commailto:kris.malfett...@sig.com wrote: I am trying to use ninja on windows. Everything seems to work correctly ( compilation, linking, install rules, etc... ) except for testing whether or not a file has changed. No matter the state of the tree, ninja always builds the entire project. I tried searching the bug tracker and mailing list but did not see this noted before. I am doing an out of source build with visual studio 2010 64 bit. Is this a known issue? -Kris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- Powered by www.kitware.comhttp://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 IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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] Ninja on windows ( latest ninja from git, cmake 2.8.9 )
So I found the -d explain option of ninja and it says that it thinks my boost libraries / other library includes are dirty. The only think I can think of here is that they are on a network drive and not on my local machine. Any thoughts on that? -Kris From: Malfettone, Kris [mailto:kris.malfett...@sig.com] Sent: Tuesday, August 14, 2012 2:23 PM To: David Cole; Malfettone, Kris Cc: cmake@cmake.org Subject: RE: [CMake] Ninja on windows ( latest ninja from git, cmake 2.8.9 ) Nothing special in my opinion. I am trying to reproduce it with something simpler than my code base. With an ultra trivial CMake setup it works fine. Is there some sort of debugging I can enable to see why it thinks the files are changed? -Kris From: David Cole [mailto:david.c...@kitware.com]mailto:[mailto:david.c...@kitware.com] Sent: Tuesday, August 14, 2012 12:58 PM To: Malfettone, Kris Cc: cmake@cmake.orgmailto:cmake@cmake.org Subject: Re: [CMake] Ninja on windows ( latest ninja from git, cmake 2.8.9 ) Definitely not known. In fact, the opposite is true here on my ninja build trees for CMake itself. A no-op build results in a no work to do message from ninja. Is there anything unusual about your CMakeLists.txt files? Are your source files accidentally dated in the future? (Did you just return from a different time zone, or have a clock setting mishap of some sort?) On Tue, Aug 14, 2012 at 12:07 PM, Malfettone, Kris kris.malfett...@sig.commailto:kris.malfett...@sig.com wrote: I am trying to use ninja on windows. Everything seems to work correctly ( compilation, linking, install rules, etc... ) except for testing whether or not a file has changed. No matter the state of the tree, ninja always builds the entire project. I tried searching the bug tracker and mailing list but did not see this noted before. I am doing an out of source build with visual studio 2010 64 bit. Is this a known issue? -Kris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- Powered by www.kitware.comhttp://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 IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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
Re: [CMake] CMake + Ninja
Nico, Thank you for your response. -Kris -Original Message- From: Nicolas Desprès [mailto:nicolas.desp...@gmail.com] Sent: Wednesday, April 11, 2012 2:49 PM To: Malfettone, Kris Cc: Peter Collingbourne; Clifford Yapp; CMake List Subject: Re: [CMake] CMake + Ninja It is in my todo list to try to find out a way to add this feature to Ninja. I'll let you know once I have something. Meanwhile, I haven't seen any post about this on the ninja-build mailing list so far. Cheers, -Nico On Tue, Apr 10, 2012 at 7:16 PM, Malfettone, Kris kris.malfett...@sig.com wrote: Just checking in to see if anyone has any insight into this since I have not heard back a response. -Kris -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Malfettone, Kris Sent: Wednesday, February 22, 2012 6:45 PM To: Peter Collingbourne; Clifford Yapp Cc: CMake List Subject: Re: [CMake] CMake + Ninja I was wondering if there was any plans to add the feature mentioned below? That said, a way of saying build every target in this subdirectory (for example, by specifying that subdirectory as a target on the command line) would be a nice feature to have. This would be very useful to me and I haven't heard any more mentions about it here on the mailing list. -Kris -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Peter Collingbourne Sent: Tuesday, January 10, 2012 12:03 AM To: Clifford Yapp Cc: CMake List Subject: Re: [CMake] CMake + Ninja On Fri, Jan 06, 2012 at 02:08:24PM -0500, Clifford Yapp wrote: Peter, FYI, I'm seeing a problem with the BRL-CAD build on the Mac with CMake + ninja using the latest git versions - when I try to run tclsh, I + get a problem with it trying to link TARGET_INSTALLNAME_DIRlibtcl.8.5.dylib instead of the local libtcl.8.5.dylib in the build directory. This doesn't seem to happen on Linux. Hi Clifford, The attached patch should add support for TARGET_INSTALLNAME_DIR. Please let me know if it works -- it's untested, as I don't have easy access to a Mac. Also, a question - is it in the plans longer term to add build.ninja files in subdirectories, so I can cd into a subdirectory and build just what's required for that directory (i.e. like make)? Or is ninja a toplevel-only setup? Ninja doesn't work that way. You can of course list specific targets to build on the command line. That said, a way of saying build every target in this subdirectory (for example, by specifying that subdirectory as a target on the command line) would be a nice feature to have. Thanks, -- Peter IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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 IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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
Re: [CMake] CMake + Ninja
Just checking in to see if anyone has any insight into this since I have not heard back a response. -Kris -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Malfettone, Kris Sent: Wednesday, February 22, 2012 6:45 PM To: Peter Collingbourne; Clifford Yapp Cc: CMake List Subject: Re: [CMake] CMake + Ninja I was wondering if there was any plans to add the feature mentioned below? That said, a way of saying build every target in this subdirectory (for example, by specifying that subdirectory as a target on the command line) would be a nice feature to have. This would be very useful to me and I haven't heard any more mentions about it here on the mailing list. -Kris -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Peter Collingbourne Sent: Tuesday, January 10, 2012 12:03 AM To: Clifford Yapp Cc: CMake List Subject: Re: [CMake] CMake + Ninja On Fri, Jan 06, 2012 at 02:08:24PM -0500, Clifford Yapp wrote: Peter, FYI, I'm seeing a problem with the BRL-CAD build on the Mac with CMake + ninja using the latest git versions - when I try to run tclsh, I get a problem with it trying to link TARGET_INSTALLNAME_DIRlibtcl.8.5.dylib instead of the local libtcl.8.5.dylib in the build directory. This doesn't seem to happen on Linux. Hi Clifford, The attached patch should add support for TARGET_INSTALLNAME_DIR. Please let me know if it works -- it's untested, as I don't have easy access to a Mac. Also, a question - is it in the plans longer term to add build.ninja files in subdirectories, so I can cd into a subdirectory and build just what's required for that directory (i.e. like make)? Or is ninja a toplevel-only setup? Ninja doesn't work that way. You can of course list specific targets to build on the command line. That said, a way of saying build every target in this subdirectory (for example, by specifying that subdirectory as a target on the command line) would be a nice feature to have. Thanks, -- Peter IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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 IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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] Running tests only on modified projects....
Just checking in if anyone has any ideas for this either yay or nay. It would be useful at least to know that it is impossible. -Kris From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Malfettone, Kris Sent: Tuesday, March 27, 2012 10:11 AM To: cmake@cmake.org Subject: [CMake] Running tests only on modified projects I've been looking through the ctest documentation and online for a while now and can't seem to find a way to run tests only from projects that have changed. Basically what I have is a very large build tree consisting of many projects. When someone submits code to just one of the projects I would like to only run the tests associated with that project or projects that the project is a dependency of. Is this possible? -Kris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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] Running tests only on modified projects....
David, Thank you for your response. -Kris -Original Message- From: David Cole [mailto:david.c...@kitware.com] Sent: Tuesday, April 10, 2012 1:28 PM To: Malfettone, Kris Cc: cmake@cmake.org Subject: Re: [CMake] Running tests only on modified projects It is presently not possible because there is no connection (other than the full path to the executable and the arguments you pass to it) between a test executed by ctest and the build products produced by CMake and the native build system. What is necessary is a way to connect a test and its inputs back to the build products that lead into it such that it's part of the build-time dependency analysis that takes place when an incremental build is performed. It's very much a non-trivial set of tasks that need to occur before this becomes possible in a reliable manner. HTH, David On Tue, Apr 10, 2012 at 1:16 PM, Malfettone, Kris kris.malfett...@sig.com wrote: Just checking in if anyone has any ideas for this either yay or nay. It would be useful at least to know that it is impossible. -Kris From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Malfettone, Kris Sent: Tuesday, March 27, 2012 10:11 AM To: cmake@cmake.org Subject: [CMake] Running tests only on modified projects I've been looking through the ctest documentation and online for a while now and can't seem to find a way to run tests only from projects that have changed. Basically what I have is a very large build tree consisting of many projects. When someone submits code to just one of the projects I would like to only run the tests associated with that project or projects that the project is a dependency of. Is this possible? -Kris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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 IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Running tests only on modified projects....
I've been looking through the ctest documentation and online for a while now and can't seem to find a way to run tests only from projects that have changed. Basically what I have is a very large build tree consisting of many projects. When someone submits code to just one of the projects I would like to only run the tests associated with that project or projects that the project is a dependency of. Is this possible? -Kris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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] Skipping dependency checking... aka an all/fast target
Hi all, I never got a response about this and figured I would try replying to the question to hopefully catch someone's attention. Any response on this question would be much appreciated. -Kris From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Malfettone, Kris Sent: Wednesday, August 31, 2011 6:05 PM To: cmake@cmake.org Subject: [CMake] Skipping dependency checking... aka an all/fast target I am looking for a target similar to target/fast for the entire tree, possibly all/fast. I have seen in the past this feature has been requested and from what I could understand from the archives it looked as though the feature was supposed to be implemented. However, I cannot seem to find it. I was able to find this ticket in the issue tracker: http://public.kitware.com/Bug/view.php?id=2389 The ticket marks the feature as fixed however I can only find target/fast and no all equivalent. Does anyone know the final standing of this feature? -Kris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. ___ 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] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
Peter, I am very interested in the ninja generator and gave it a try for one of my very large projects. Unfortunately, I have approximately 100 targets all with the same output name(simple) but in CMake I give them all unique target names(dot separated name built from their place in the directory tree). This works fine for Makefiles however the ninja generator seems to be adding: # Shortcut target for the output name. build simple: phony MD/MDF/Parsers/BX/BLS/v1_1/utils/simple/simple # Shortcut target for the target name. build BX.BLS.v1_1.simple: phony simple Which then causes the following from ninja: ninja: WARNING: multiple rules generate simple. build will not be correct; continuing anyway Is there a way to disable these shortcut targets? Even changing my target names to a different format is a possibility if that is necessary. -Kris -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Peter Collingbourne Sent: Thursday, September 08, 2011 2:55 PM To: Jean-Christophe Fillion-Robin Cc: CMake ML Subject: Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules On Wed, Sep 07, 2011 at 11:04:42PM -0400, Jean-Christophe Fillion-Robin wrote: -- Forwarded message -- From: Peter Collingbourne pe...@pcc.me.uk Date: Wed, Sep 7, 2011 at 9:17 PM Subject: Proposal: restat rules To: ninja-bu...@googlegroups.com FWIW, the Ninja generator I have been working on is based on work by Nicolas Despres, and has been successfully used to compile a number of large open source projects, including CMake itself, LLVM/Clang, OpenCV and Bullet Physics. I am planning to submit the Ninja generator as a patch to CMake upstream once it has been put through more exhaustive testing and certain known issues have been resolved (my post to ninja-build being one of them). Anyone who is interested in trying the Ninja generator with their own projects is welcome to clone my repository at: https://github.com/pcc/CMake/tree/ninja-generator and to report any issues encountered. Note that the generator is currently only known to work on Linux. To select the Ninja generator you can pass the option -G Ninja on the cmake command line. Thanks, -- Peter ___ 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 IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Skipping dependency checking... aka an all/fast target
I am looking for a target similar to target/fast for the entire tree, possibly all/fast. I have seen in the past this feature has been requested and from what I could understand from the archives it looked as though the feature was supposed to be implemented. However, I cannot seem to find it. I was able to find this ticket in the issue tracker: http://public.kitware.com/Bug/view.php?id=2389 The ticket marks the feature as fixed however I can only find target/fast and no all equivalent. Does anyone know the final standing of this feature? -Kris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. ___ 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
