[CMake] ExternalProject, BundleUtilities, CPack, and RPath management

[Clifford Yapp]

I am contemplating attempting to use ExternalProject_Add and
fixup_bundle to improve the long term maintainability of a large
software product, but there are some implications that are potentially
involved and I'd like to ask if anyone in the CMake community can
offer insight.  The design constraints to satisfy (that are satisfied
by our current "build everything wth CMake" approach):

1.  We need to be able to install our bundled dependencies seamlessly
with the rest of the project when doing either a "make install" or
"make package" - from the standpoint of the main software project, the
external projects' outputs are handled exactly as if they were created
by the "main" build (right now that's because they *are* part of the
main build, but it's a property we want to preserve regardless.)

2.  Our "build" directory is laid out such that it mimics the
installed layout (including any external dependencies we will be
bundling) and CMake's RPath management settings are defined such that
the build directory is fully functional without requiring any
installation steps, LD_LIBRARY_PATH fiddling, or other user
intervention.  Except for the presence of the ancillary files from
configuration and building, structurally the build directory could be
an install directory.

3.  At no point in the configure, build, or package creation process
should it be necessary to place anything in the final
CMAKE_INSTALL_PREFIX install location - someone without access to the
CMAKE_INSTALL_PREFIX directory should still be able to create a
proper, working package.

4.  Works seamlessly across Windows+MSVC, Linux, MacOSX and the BSDs.
(In years past this was a challenge with ExternalProject_Add and
Windows - trying to mix an nmake external build with an MSVC parent
build on Windows didn't work, if I recall correctly.  Hopefully things
are better nowadays...)

Right now we are achieving these goals by creating CMake build files
for all projects we need to manage as bundled dependencies, but
writing those build systems when they don't already exist is a lot of
work and doesn't scale long term (for example, not even I am crazy
enough to want to write and maintain a separate CMake build for all of
Qt).  I would like to be able to define an "external dependencies"
repository with a build system which simply encodes the necessary
rules to trigger the native build logic from the projects in question,
builds a "deps_install" directory that the primary project's CMake
build can be pointed to for build purposes, and then use the primary
project's RPath settings from then on to manage the deps_install
executable and library files as if they were outputs from build
targets in the primary project.

It feels like some combination of CPack, ExternalProject and
BundleUtilties should be able to make this work as long as the
deps_install binaries have RPaths defined that are suitable for
manipulation by CMake, but unless I'm missing something (hopefully I
am) this looks like a sufficiently obscure corner of the CMake toolbox
that there isn't a lot to be found documenting the nitty-gritty of how
to do it.  Can anyone direct me to a tutorial or a project that
demonstrates how to make the combination of
ExternalProject_Add+BundleUtilities+CPack work in a cross platform
manner?

Thanks,
CY
-- 

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-developers] Future of ccmake and cmake-gui and internationalization

[Clifford Yapp]

On Thu, Aug 17, 2017 at 2:27 AM, Eric Wing  wrote:
>> Hi Eric:
>>
>> My opinion is your point about size is weak because IUP normally depends on
>> a big suite of graphical libraries in the GTK+ case or a big set of
>> system libraries such as GDI/GDI+/Uniscribe or Direct2D/DirectWrite in
>> the Windows case.
>
> On systems the provide first class native GUIs, I would disagree with
> this point because the system libraries are typically already loaded
> by everything. Furthermore, even non-native frameworks like Qt need to
> link into the native frameworks even though they may not be using much
> from it. So you take a double hit because you get both the system
> frameworks and the non-native implementation. This is very apparent on
> Mac, where everything links to Foundation and AppKit as a baseline.
>
> I do cede that GTK is not small. However, almost all the distros I see
> today ship at least GTK2, with a lot of forks UI forks in protest of
> GTK3 and Gnome, and intentionally kept GTK2 alive because it was much
> smaller than GTK3. So there is probably something already on your
> system using it. But if you really need something smaller, Motif is
> always an option. (Also, somebody is experimenting with my Cocoa
> backend and has a prototype working in GNUStep on Linux though I
> wouldn't necessarily consider that small either and few systems
> install it.)

If small and self-reliant are the criteria, how does FLTK
(http://www.fltk.org/index.php) stack up?  For something like
cmake-gui it would probably work just fine, and AFAIK it doesn't
require GTK...  it uses LGPLv2 with a static linking exception, so
it's probably as good/better than the current Qt requirement in that
department.
-- 

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-developers

Re: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test?

[Clifford Yapp]

On Mon, Oct 3, 2016 at 2:25 PM, Brad King <brad.k...@kitware.com> wrote:
> On 10/03/2016 12:14 PM, Clifford Yapp wrote:
>> so what we need is not actually the test names themselves,
>> but a list of the executables used to run tests that are also defined
>> as build targets.
> [snip]
>> The list we need would thus be built up to contain all COMMAND
>> arguments to add_test that are also build targets in CMake.
>
> The list would also need to include targets mentioned in generator
> expressions such as `$`.  This will almost certainly
> be better done as a CMake feature implemented in C++.  This was actually
> an early design philosophy: do the hard stuff in C++ so that complex
> logic is not needed in CMake-language code.

Sounds like a plan.  I must confess I'm not familiar with the use of
generator expressions yet (we've been holding off requiring CMake 3,
but I see Debian stable has now updated so it's probably time) but
I'll start catching up on my homework since I think they'll be needed
to "modernize" some of our features that are still using the LOCATION
property.

>> dependency of the custom target "check".  Then, when the custom target
>> "check" executes, it will first make sure all of the test executables
>> (and their dependencies) have  been built.
>
> Why do you need a "check" target instead of the CMake-defined "test"
> target?

Primarily because we have experimental CTest targets that are in
various stages of development, and not ready for prime time.  check is
the target we use when the test is ready to be used as a determining
factor in whether something has broken.

> One could teach cmGlobalGenerator::AddGlobalTarget_Test an option to add
> a dependency on the "all" target from "test".  Most projects do not have
> so many non-test targets that they cannot afford to build "all" before
> testing.

While we could "afford" to, we have quite a large number of doc
targets (for example) that aren't needed for make test so it would be
a noticeable increase.

> Alternatively the implementation could directly add dependencies
> on targets referenced by tests.  That may be a bit trickier though.

That would be ideal, if it can be done.

Cheers,
CY
-- 

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-developers

Re: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test?

[Clifford Yapp]

On Mon, Oct 3, 2016 at 11:21 AM, Brad King <brad.k...@kitware.com> wrote:
> On 10/03/2016 11:17 AM, Clifford Yapp wrote:
>> One of the functions we are wrapping in our build with CMake's "_"
>> prefix debugging mechanism is add_test.  Looking at why we do that, it
>> should be possible to avoid wrapping if we can get access in CMake to
>> the list of all test build targets defined with add_test.
>> Essentially, we need to add them to some custom target dependencies,
>> and it should be OK to do that after all tests are added if we can get
>> access to the list of targets within CMake.
>>
>> Is there a property somewhere that exposes this list?
>
> I don't recall one off the top of my head.  Even if there were,
> the `set_property(TEST ...)` only works on tests in the invoking
> directory.  There is no global scope for test names.

Hmm.  OK, so what we need is not actually the test names themselves,
but a list of the executables used to run tests that are also defined
as build targets.  So, for example, we have a test that is named
bu_basename_usr that runs the executable test_bu_basename.  What we
actually need is for the build target test_bu_basename to be a
dependency of the custom target "check".  Then, when the custom target
"check" executes, it will first make sure all of the text executables
(and their dependencies) have  been built.

The list we need would thus be built up to contain all COMMAND
arguments to add_test that are also build targets in CMake.  Does that
make sense?

> Some projects use a `myproj_add_test()` wrapper around their
> `add_test()` calls specifically to provide customizations.

I suspect that would run into issues similar to those we're seeing now
trying to pass empty strings from the wrapper to the children, unless
perhaps a macro wrapper would work where a function wrapper would
not...:  https://gitlab.kitware.com/cmake/cmake/issues/16341

Cheers,
CY
-- 

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-developers

[cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test?

[Clifford Yapp]

One of the functions we are wrapping in our build with CMake's "_"
prefix debugging mechanism is add_test.  Looking at why we do that, it
should be possible to avoid wrapping if we can get access in CMake to
the list of all test build targets defined with add_test.
Essentially, we need to add them to some custom target dependencies,
and it should be OK to do that after all tests are added if we can get
access to the list of targets within CMake.

Is there a property somewhere that exposes this list?

Thanks,
CY
-- 

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-developers

[CMake] Getting at the final compiler/linker string for a given library

[Clifford Yapp]

Does anyone know if there's a way, given the full path find_package result:

/usr/lib/libfoo.so

to have CMake report what the eventual "-lfoo" entry will be on the
compiler/linker line?  I need to report out that information into a
file independent of CMake's logic, and so far I haven't been able to
zero in on how to get at it.

Thanks,
CY
-- 

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-developers] Listing all targets

[Clifford Yapp]

On Mon, Sep 14, 2015 at 1:47 PM, Stephen Kelly  wrote:
> Brad King wrote:
>
>> On 09/14/2015 11:46 AM, David Cole wrote:
>>> (1) I see how I can easily move "COMPONENTS" from
>>> cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty
>>> because I can access the global generator from cmState as well...
>>
>> Yes.
>
> I assume you're thinking of getting the global generator from the cmake
> instance?
>
> That's not appropriate. [...]

> Making the target names available through properties via cmState is also
> trivial after targets become first-class parts of cmState (cmState::Target
> like cmState::Directory).
>
> That can happen sooner (it's on my plate), but required refactoring is also
> on hold until after CMake 3.4.


Does anyone recall where the "list all targets" feature ended up?  Is
it still on hold?  (I apologize if I missed any subsequent discussion
- just now getting back to this...)

Cheers,
CY
-- 

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-developers

Re: [cmake-developers] Listing source-tree files encountered

[Clifford Yapp]

On Mon, Jul 20, 2015 at 4:42 PM, Ben Boeckel ben.boec...@kitware.com wrote:

 For testing these properties, what would you suggest?  They're
 intended to report local configure-time absolute paths, which can't be
 hard coded... is it enough to check them to make sure they're not
 empty or is there something more robust that could be devised?

 They should end with the path under the CMake source tree at least (I
 assume they are absolute?). Try matching this regex:

 .*/Testing/RunCMake/get_property

 possibly? You can also put the test under an add_subdirectory() call as
 well.

The attached patch seems to work - Brad, should I submit this to the
issue tracker?  If it needs any more tweaking let me know.

Looking at the target properties test, should there also be a test for
the SOURCES property?  The SOURCE_DIR property in particular is
intended to work with the current behavior (relative path lists unless
original target specifier is a full path) from SOURCES, so IMHO it
might be a good idea to put a test in for that as well...

Cheers,
CY
diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index 1d27a64..ac893c2 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -114,6 +114,7 @@ Properties on Targets
/prop_tgt/AUTOUIC_OPTIONS
/prop_tgt/AUTORCC
/prop_tgt/AUTORCC_OPTIONS
+   /prop_tgt/BINARY_DIR
/prop_tgt/BUILD_WITH_INSTALL_RPATH
/prop_tgt/BUNDLE_EXTENSION
/prop_tgt/BUNDLE
@@ -244,6 +245,7 @@ Properties on Targets
/prop_tgt/RUNTIME_OUTPUT_NAME_CONFIG
/prop_tgt/RUNTIME_OUTPUT_NAME
/prop_tgt/SKIP_BUILD_RPATH
+   /prop_tgt/SOURCE_DIR
/prop_tgt/SOURCES
/prop_tgt/SOVERSION
/prop_tgt/STATIC_LIBRARY_FLAGS_CONFIG
diff --git a/Help/prop_tgt/BINARY_DIR.rst b/Help/prop_tgt/BINARY_DIR.rst
new file mode 100644
index 000..a6c1c12
--- /dev/null
+++ b/Help/prop_tgt/BINARY_DIR.rst
@@ -0,0 +1,4 @@
+BINARY_DIR
+--
+
+Reports the value of CMAKE_CURRENT_BINARY_DIR in the directory in which the 
target was defined.
diff --git a/Help/prop_tgt/SOURCE_DIR.rst b/Help/prop_tgt/SOURCE_DIR.rst
new file mode 100644
index 000..de93f29
--- /dev/null
+++ b/Help/prop_tgt/SOURCE_DIR.rst
@@ -0,0 +1,4 @@
+SOURCE_DIR
+--
+
+Reports the value of CMAKE_CURRENT_SOURCE_DIR in the directory in which the 
target was defined.
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 0303f1e..ff4f161 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2959,6 +2959,8 @@ const char *cmTarget::GetProperty(const std::string prop,
   MAKE_STATIC_PROP(COMPILE_DEFINITIONS);
   MAKE_STATIC_PROP(IMPORTED);
   MAKE_STATIC_PROP(NAME);
+  MAKE_STATIC_PROP(BINARY_DIR);
+  MAKE_STATIC_PROP(SOURCE_DIR);
   MAKE_STATIC_PROP(SOURCES);
 #undef MAKE_STATIC_PROP
   if(specialProps.empty())
@@ -2971,6 +2973,8 @@ const char *cmTarget::GetProperty(const std::string prop,
 specialProps.insert(propCOMPILE_DEFINITIONS);
 specialProps.insert(propIMPORTED);
 specialProps.insert(propNAME);
+specialProps.insert(propBINARY_DIR);
+specialProps.insert(propSOURCE_DIR);
 specialProps.insert(propSOURCES);
 }
   if(specialProps.count(prop))
@@ -3053,6 +3057,14 @@ const char *cmTarget::GetProperty(const std::string 
prop,
   {
   return this-GetName().c_str();
   }
+else if (prop == propBINARY_DIR)
+  {
+  return this-GetMakefile()-GetCurrentBinaryDirectory();
+  }
+else if (prop == propSOURCE_DIR)
+  {
+  return this-GetMakefile()-GetCurrentSourceDirectory();
+  }
 else if(prop == propSOURCES)
   {
   if (this-Internal-SourceEntries.empty())
diff --git a/Tests/RunCMake/get_property/target_properties-stderr.txt 
b/Tests/RunCMake/get_property/target_properties-stderr.txt
index d0981ac..8a06b38 100644
--- a/Tests/RunCMake/get_property/target_properties-stderr.txt
+++ b/Tests/RunCMake/get_property/target_properties-stderr.txt
@@ -3,4 +3,9 @@ get_property: 
 get_target_property: --value--
 get_property: --value--
 get_target_property: --gtp_val-NOTFOUND--
-get_property: $
+get_property: 
+get_target_property: --(.*)Tests/RunCMake/get_property--
+get_property: --(.*)Tests/RunCMake/get_property--
+get_target_property: 
--(.*)Tests/RunCMake/get_property/target_properties-build--
+get_property: --(.*)Tests/RunCMake/get_property/target_properties-build--$
+
diff --git a/Tests/RunCMake/get_property/target_properties.cmake 
b/Tests/RunCMake/get_property/target_properties.cmake
index c5a141d..9ff833a 100644
--- a/Tests/RunCMake/get_property/target_properties.cmake
+++ b/Tests/RunCMake/get_property/target_properties.cmake
@@ -14,3 +14,5 @@ set_target_properties(tgt PROPERTIES empty  custom value)
 check_target_property(tgt empty)
 check_target_property(tgt custom)
 check_target_property(tgt noexist)
+check_target_property(tgt SOURCE_DIR)
+check_target_property(tgt BINARY_DIR)
-- 

Powered by www.kitware.com

Please keep messages on-topic and 

Re: [cmake-developers] Capturing messages to log files

[Clifford Yapp]

On Mon, Jul 20, 2015 at 9:36 AM, Brad King brad.k...@kitware.com wrote:
 On 07/18/2015 03:45 PM, Clifford Yapp wrote:
 Am I correct that cmSystemTools::Message is the gateway through which
 all of the console output from CMake exits?  If so, perhaps the
 simplest thing to do is simply allow copying to a log file at that
 point?  It would be nice to have files containing only errors, only
 warnings, etc. but it's not immediately clear to me how to set
 something like that up...

 Look at Source/QtDialog/QCMake.cxx for use of SetStdoutCallback,
 SetStderrCallback, SetMessageCallback, and SetProgressCallback.
 The cmake-gui uses those to capture everything for display in
 the dialog.

 -Brad

Ah - thanks for the pointer.  Working on understanding how the various
overrides work - cmakemainProgressCallback et. al. and how Qt is
handling the various bits.

Cheers,
CY
-- 

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-developers

Re: [cmake-developers] Listing source-tree files encountered

[Clifford Yapp]

On Mon, Jul 20, 2015 at 9:33 AM, Brad King brad.k...@kitware.com wrote:

 That looks good to me.  Please extend the patch to also do BINARY_DIR
 for completeness and also to update the documentation to cover the new
 properties.  The Tests/RunCMake/get_property test should be updated
 to cover both too.

I've put both in and added the man pages - progress so far attached.
Are there any other docs that list target properties, or are the rst
files the canonical sources for property docs?

For testing these properties, what would you suggest?  They're
intended to report local configure-time absolute paths, which can't be
hard coded... is it enough to check them to make sure they're not
empty or is there something more robust that could be devised?

Thanks,
CY
diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index 1d27a64..ac893c2 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -114,6 +114,7 @@ Properties on Targets
/prop_tgt/AUTOUIC_OPTIONS
/prop_tgt/AUTORCC
/prop_tgt/AUTORCC_OPTIONS
+   /prop_tgt/BINARY_DIR
/prop_tgt/BUILD_WITH_INSTALL_RPATH
/prop_tgt/BUNDLE_EXTENSION
/prop_tgt/BUNDLE
@@ -244,6 +245,7 @@ Properties on Targets
/prop_tgt/RUNTIME_OUTPUT_NAME_CONFIG
/prop_tgt/RUNTIME_OUTPUT_NAME
/prop_tgt/SKIP_BUILD_RPATH
+   /prop_tgt/SOURCE_DIR
/prop_tgt/SOURCES
/prop_tgt/SOVERSION
/prop_tgt/STATIC_LIBRARY_FLAGS_CONFIG
diff --git a/Help/prop_tgt/BINARY_DIR.rst b/Help/prop_tgt/BINARY_DIR.rst
new file mode 100644
index 000..a6c1c12
--- /dev/null
+++ b/Help/prop_tgt/BINARY_DIR.rst
@@ -0,0 +1,4 @@
+BINARY_DIR
+--
+
+Reports the value of CMAKE_CURRENT_BINARY_DIR in the directory in which the 
target was defined.
diff --git a/Help/prop_tgt/SOURCE_DIR.rst b/Help/prop_tgt/SOURCE_DIR.rst
new file mode 100644
index 000..de93f29
--- /dev/null
+++ b/Help/prop_tgt/SOURCE_DIR.rst
@@ -0,0 +1,4 @@
+SOURCE_DIR
+--
+
+Reports the value of CMAKE_CURRENT_SOURCE_DIR in the directory in which the 
target was defined.
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 0303f1e..ff4f161 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2959,6 +2959,8 @@ const char *cmTarget::GetProperty(const std::string prop,
   MAKE_STATIC_PROP(COMPILE_DEFINITIONS);
   MAKE_STATIC_PROP(IMPORTED);
   MAKE_STATIC_PROP(NAME);
+  MAKE_STATIC_PROP(BINARY_DIR);
+  MAKE_STATIC_PROP(SOURCE_DIR);
   MAKE_STATIC_PROP(SOURCES);
 #undef MAKE_STATIC_PROP
   if(specialProps.empty())
@@ -2971,6 +2973,8 @@ const char *cmTarget::GetProperty(const std::string prop,
 specialProps.insert(propCOMPILE_DEFINITIONS);
 specialProps.insert(propIMPORTED);
 specialProps.insert(propNAME);
+specialProps.insert(propBINARY_DIR);
+specialProps.insert(propSOURCE_DIR);
 specialProps.insert(propSOURCES);
 }
   if(specialProps.count(prop))
@@ -3053,6 +3057,14 @@ const char *cmTarget::GetProperty(const std::string 
prop,
   {
   return this-GetName().c_str();
   }
+else if (prop == propBINARY_DIR)
+  {
+  return this-GetMakefile()-GetCurrentBinaryDirectory();
+  }
+else if (prop == propSOURCE_DIR)
+  {
+  return this-GetMakefile()-GetCurrentSourceDirectory();
+  }
 else if(prop == propSOURCES)
   {
   if (this-Internal-SourceEntries.empty())
-- 

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-developers

Re: [cmake-developers] Listing source-tree files encountered

[Clifford Yapp]

With David's patch and the above SOURCE_DIR property, it looks like
the necessary pieces are now present for target + source processing.
A quick test:

get_cmake_property(target_list TARGETS)
list(SORT target_list)
foreach(targ ${target_list})
  get_target_property(ttype ${targ} TYPE)
  if (NOT ${ttype} STREQUAL UTILITY)
message(checking files of ${targ}(${ttype}): )
get_target_property(tdir ${targ} SOURCE_DIR)
get_target_property(tsrcs ${targ} SOURCES)
foreach(fsrc ${tsrcs})
  if(NOT EXISTS ${tdir}/${fsrc})
message(NOT PRESENT: ${tdir}/${fsrc})
  else(NOT EXISTS ${tdir}/${fsrc})
message(found: ${tdir}/${fsrc})
  endif(NOT EXISTS ${tdir}/${fsrc})
endforeach(fsrc ${tsrcs})
  endif (NOT ${ttype} STREQUAL UTILITY)
endforeach(targ ${target_list})

returns the expected results, finding files that are present in the
source directories and listed in the target definition with a relative
path.  Very nice!  I believe this combination of abilities will also
allow me to avoid the add_subdirectory wrapping, since the set of
directories from all targets should be pretty close to the set of
directories added via add_subdirectory (warrants a quick test, but
probably close enough.)

CY
-- 

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-developers

Re: [cmake-developers] Listing source-tree files encountered

[Clifford Yapp]

On Sat, Jul 18, 2015 at 5:30 AM, Florent Castelli
florent.caste...@gmail.com wrote:
 I've used that once and you end up with the relative path to the sources
 from the CMakeLists.txt.
 If you're in another CMakeLists.txt, then you can't use the paths directly.
 I tried a few properties but I couldn't find any property to get the folder
 where the target was defined.

 How do you get the full path?

That's a very good point - using the command override approach, the
CMAKE_CURRENT_SOURCE_DIR is always the directory of the target in
question, and looking at our current code I see we do make use of that
assumption.  We would need a way to find out what
CMAKE_CURRENT_SOURCE_DIR was when the target was defined if we're
going to build up a list after the fact - maybe something like
get_target_property(TDIR targetname SOURCE_DIR) to get the source
directory in which the target was defined.  In combination with the
SOURCES property it would allow for full path reconstruction.

CY
-- 

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-developers

Re: [cmake-developers] Capturing messages to log files (was: Wrapping functions in CMake)

[Clifford Yapp]

On Wed, Jul 15, 2015 at 9:10 AM, Brad King brad.k...@kitware.com wrote:
 On 07/09/2015 01:53 PM, Clifford Yapp wrote:
 Actually, thinking about that, what's really needed is not an
 in-memory log but a way to specify log files, since an unexpected
 crash or exit is not a situation under which such in-memory logs could
 be reliably written to disk.  So it would instead need to be
 CMAKE_STATUS_MESSAGE_LOG, CMAKE_ERROR_MESSAGES_LOG, etc. which would
 hold paths to which messages would be copied before being written to
 stdout/stderr.

 These could be defined as GLOBAL properties since there can only
 be one.  Internally we already have callback infrastructure to
 dispatch where these messages go.  Hooks could be added to check
 these properties too.  Or, the property setting logic could have
 special handling for these properties to install the needed
 callbacks internally.  This approach would avoid opening/closing
 the log files over and over.  We could just keep them open all
 the time and flush after each write.

Brad,

Am I correct that cmSystemTools::Message is the gateway through which
all of the console output from CMake exits?  If so, perhaps the
simplest thing to do is simply allow copying to a log file at that
point?  It would be nice to have files containing only errors, only
warnings, etc. but it's not immediately clear to me how to set
something like that up...

CY
-- 

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-developers

Re: [cmake-developers] Listing source-tree files encountered

[Clifford Yapp]

On Sat, Jul 18, 2015 at 1:49 PM, Clifford Yapp cliffy...@gmail.com wrote:
 On Sat, Jul 18, 2015 at 5:30 AM, Florent Castelli
 florent.caste...@gmail.com wrote:
 I've used that once and you end up with the relative path to the sources
 from the CMakeLists.txt.
 If you're in another CMakeLists.txt, then you can't use the paths directly.
 I tried a few properties but I couldn't find any property to get the folder
 where the target was defined.

 How do you get the full path?

 That's a very good point - using the command override approach, the
 CMAKE_CURRENT_SOURCE_DIR is always the directory of the target in
 question, and looking at our current code I see we do make use of that
 assumption.  We would need a way to find out what
 CMAKE_CURRENT_SOURCE_DIR was when the target was defined if we're
 going to build up a list after the fact - maybe something like
 get_target_property(TDIR targetname SOURCE_DIR) to get the source
 directory in which the target was defined.  In combination with the
 SOURCES property it would allow for full path reconstruction.

 CY


A quick experiment suggests that this will work for associating and
exposing a source directory with each target - not sure if this dots
all the i's an crosses all the t's though:


diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 2b73e6f..c9281b7 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2945,6 +2945,7 @@ const char *cmTarget::GetProperty(const std::string prop,
   MAKE_STATIC_PROP(COMPILE_DEFINITIONS);
   MAKE_STATIC_PROP(IMPORTED);
   MAKE_STATIC_PROP(NAME);
+  MAKE_STATIC_PROP(SOURCE_DIR);
   MAKE_STATIC_PROP(SOURCES);
 #undef MAKE_STATIC_PROP
   if(specialProps.empty())
@@ -2957,6 +2958,7 @@ const char *cmTarget::GetProperty(const std::string prop,
 specialProps.insert(propCOMPILE_DEFINITIONS);
 specialProps.insert(propIMPORTED);
 specialProps.insert(propNAME);
+specialProps.insert(propSOURCE_DIR);
 specialProps.insert(propSOURCES);
 }
   if(specialProps.count(prop))
@@ -3039,6 +3041,10 @@ const char *cmTarget::GetProperty(const
std::string prop,
   {
   return this-GetName().c_str();
   }
+else if (prop == propSOURCE_DIR)
+  {
+  return this-GetMakefile()-GetCurrentSourceDirectory();
+  }
 else if(prop == propSOURCES)
   {
   if (this-Internal-SourceEntries.empty())
-- 

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-developers

Re: [cmake-developers] Listing all targets (was: Wrapping functions in CMake)

[Clifford Yapp]

On Fri, Jul 17, 2015 at 6:05 PM, David Cole dlrd...@aol.com wrote:
 Attached is a patch file of my first attempt. I can iterate some more
 on this (better testing, add docs, clarify existing docs, address
 anybody's comments, submit to stage) next week. Attached now in case
 anybody wants to try it out over the weekend.

David,

Awesome - thank you for doing that! (Way faster than I would have been
able to set it up).

It may be Monday before I can put it through it's paces, but I'll
definitely give this a go and also see if I can combine it with the
SOURCES target property Brad pointed out to kill two problems with one
patch.

I'll try to get at figuring out how to set up GLOBAL properties for
collecting various types of message outputs and prepare a patch for
that on Monday as well, unless someone else gets to it sooner.

Cheers,
CY
-- 

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-developers

Re: [cmake-developers] Listing source-tree files encountered

[Clifford Yapp]

On Fri, Jul 17, 2015 at 11:50 AM, Brad King brad.k...@kitware.com wrote:
 On 07/15/2015 10:38 PM, Clifford Yapp wrote:
 Lists that contains a verbatim collection of all path specifiers,
 regardless of form, that are passed to the various add_* targets would
 be enough, I think - it'd then be up to our own CMake logic to make
 sense of it all.  I'm not hoping to push our whole
 in-src-dir/distcheck system into mainstream CMake, just looking for a
 way to achieve the current result without requiring the
 built-in-command overrides - I think collecting raw lists of paths
 supplied to targets is the key piece that is currently driving the
 command overrides.

 Once the list of all targets is available in a global property as
 discussed in another branch of this thread, then you could loop
 over that and check the SOURCES target property to get the list
 of original path specifiers.  That would handle almost everything.
 What would be left for your use case?

That sounds like it should work - I hadn't considered the
possibilities of the SOURCES target property.  Is that property
available for custom targets as well?

Thanks,
CY
-- 

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-developers

Re: [cmake-developers] Listing all targets (was: Wrapping functions in CMake)

[Clifford Yapp]

On Wed, Jul 15, 2015 at 9:10 AM, Brad King brad.k...@kitware.com wrote:
 On 07/10/2015 03:42 PM, Clifford Yapp wrote:
 On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp cliffy...@gmail.com wrote:

 2.  Provide similar lists of all defined targets for the various types
 (e.g. CMAKE_EXECUTABLE_TARGETS, CMAKE_LIBRARY_TARGETS,
 CMAKE_CUSTOM_TARGETS).

 Looking into the CMake sources, it seems like this information is
 stored already in the global target map - what would be the correct
 way to expose that information in variables in CMake script space?

 We shouldn't need separate lists for each because one can check
 the TYPE target property given the target name.

Ah, good point.

 The list of globally-scoped (non-imported) targets could be made available
 through a (read-only) global property whose implementation
 computes the list on the fly.

Sounds workable - are there any pre-existing properties like that that
can serve as a guide for implementation?

Thanks,
CY
-- 

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-developers

Re: [cmake-developers] Capturing messages to log files (was: Wrapping functions in CMake)

[Clifford Yapp]

On Wed, Jul 15, 2015 at 9:10 AM, Brad King brad.k...@kitware.com wrote:
 On 07/09/2015 01:53 PM, Clifford Yapp wrote:
 Actually, thinking about that, what's really needed is not an
 in-memory log but a way to specify log files, since an unexpected
 crash or exit is not a situation under which such in-memory logs could
 be reliably written to disk.  So it would instead need to be
 CMAKE_STATUS_MESSAGE_LOG, CMAKE_ERROR_MESSAGES_LOG, etc. which would
 hold paths to which messages would be copied before being written to
 stdout/stderr.

 These could be defined as GLOBAL properties since there can only
 be one.

Makes sense.

 Internally we already have callback infrastructure to
 dispatch where these messages go.  Hooks could be added to check
 these properties too.  Or, the property setting logic could have
 special handling for these properties to install the needed
 callbacks internally.  This approach would avoid opening/closing
 the log files over and over.  We could just keep them open all
 the time and flush after each write.

Sounds good!  (Always in favor of less filesystem hits, especially on
Windows...)

In hopes of writing an acceptable patch, is there an approach that
would be preferred?

Cheers,
CY
-- 

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-developers

Re: [cmake-developers] Listing source-tree files encountered (was: Wrapping functions in CMake)

[Clifford Yapp]

On Wed, Jul 15, 2015 at 9:10 AM, Brad King brad.k...@kitware.com wrote:
 On 07/09/2015 01:35 PM, Clifford Yapp wrote:
 1.  First, we need to maintain a list of all files in the source
 repository that are known to the build system.  To do this we maintain
 a global list of files, define a custom CMAKEFILES command to allow us
 to manually specify miscellaneous files as known, and override all
 of the primary target creating commands to add their files to the list
 (for example, add_executable is passed a list of source files, and all
 of those files are automatically added to the known files list by
 the function override of add_executable.)  This list is used for both
 our make-clean-in-src-dir feature and our distcheck build target
 (which does a number of verification steps using the version control
 system, the build system and the files-on-filesystem information to
 make sure the build logic is current.)

 These days it is the job of version control tools to know what files
 are part of the source and what files are not.  Commands like git clean
 are then responsible for cleaning out a source tree, not the build system.

Maybe we're a bit retro, but we've got a system set up which uses
the VCS (subversion, in our case) to cross check the build system's
awareness of files.  We have a number of reasons for this approach,
which I can go into if anyone's interested, but the punchline is we've
implemented our own distcheck system which has a number of (for our
project, at least) important features.

 CMake is mainly designed for out-of-source builds where nothing in the
 source tree is touched at all.  This makes distclean unnecessary.
 We support in-source builds for end-user convenience when installing
 a project from a source tarball, but in general development should
 always be done with out-of-source builds to keep the source pristine.

Agreed, but since historically we've allowed in-src-dir builds (in the
dark old days that's actually the only way things worked for us, but
that's another story) the decision was made to continue support for
them.  It just so happened that the system we implemented to support
distcheck was also the primary piece needed to make in-src-dir
practical, so in the end we opted to support it and one of our
distcheck test targets is set up specifically to ensure it keeps
working.

 1.  Have CMake internally maintain a list (or maybe per-command lists
 for more flexibility) of all files with paths relative to the root
 source directory that have been observed by add_executable,
 add_library, add_custom_target, add_subdirectory, and configure_file
 that can be accessed via CMake variables

 Many of the source file locations are not actually determined until
 generate time, so a configuration-time list is not possible to
 implement reliably in general.  Maintaining the list would force
 source file locations to be finalized too early.

Lists that contains a verbatim collection of all path specifiers,
regardless of form, that are passed to the various add_* targets would
be enough, I think - it'd then be up to our own CMake logic to make
sense of it all.  I'm not hoping to push our whole
in-src-dir/distcheck system into mainstream CMake, just looking for a
way to achieve the current result without requiring the
built-in-command overrides - I think collecting raw lists of paths
supplied to targets is the key piece that is currently driving the
command overrides.

Would such verbatim transcription lists (un-resolved path specifiers
and all) be something that could be provided?

Thanks,
CY
-- 

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-developers

Re: [CMake] Problem with CMake 3.3.0-rc3

[Clifford Yapp]

On Sat, Jul 11, 2015 at 5:07 AM, Stephen Kelly steve...@gmail.com wrote:
 Brad King wrote:

 Steve, please take a look.  It looks like the cmState methods
 RemoveUserDefinedCommands and RenameCommand need to work better
 together.  This needs to be fixed for 3.3.

 Fixed with

  http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f2ee169d
  cmState: Restore renamed commands on cleanup

Confirmed in rc4 - thanks!

CY
-- 

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-developers] [CMake] Problem with CMake 3.3.0-rc3

[Clifford Yapp]

On Sat, Jul 11, 2015 at 5:07 AM, Stephen Kelly steve...@gmail.com wrote:
 Brad King wrote:

 Steve, please take a look.  It looks like the cmState methods
 RemoveUserDefinedCommands and RenameCommand need to work better
 together.  This needs to be fixed for 3.3.

 Fixed with

  http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f2ee169d
  cmState: Restore renamed commands on cleanup

Confirmed in rc4 - thanks!

CY
-- 

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-developers

[CMake] Is there any way to set a build-type specific install path for multiconfig tools?

[Clifford Yapp]

One challenge we've experienced with CMake is properly controlling the
installation path when using multi-config tools like Visual Studio or
Xcode.  Since I'm in the middle of re-examining our more gnarly CMake
logic anyway, I thought I'd raise this one and see if anybody knows of
a good solution.

The problem is as follows - for multi-config build tools, the build
profile (Release, Debug, etc.) is selected at build time, not CMake
configure time.  Consequently, if one wishes to change the
CMAKE_INSTALL_PREFIX based on the current build configuration (our
convention for default install paths is to use
/parent_dirs/rel-version for release builds and
/parent_dirs/dev-version for development builds) that change has to
happen at build time.

To the best of my knowledge there is no good way to do this in CMake
currently.  The closest I could come when I tried originally was to
insert a variable into the CMAKE_INSTALL_PREFIX path that evaluated to
the current build configuration (IIRC) but that wasn't quite correct
per our convention.  I finally settled on a rather scary trick where I
created a custom build target that would manually rewrite all of the
generated CMake build files (via running a CMake script) to use the
desired path, and that build target becomes flagged for a re-run every
time the build configuration in the build tool is changed.  In
essence, I'm post processing the CMake generated build files.

The preferred solution to this (I think) would be to have
CMAKE_${CFG_TYPE}_INSTALL_PREFIX variables that could be set the same
way the C/CXX flag variables have per-configuration versions.  That
way the CMakeLists.txt file could simply specify the target install
paths for each configuration and have then written directly to the
appropriate output build files.  However, to the best of my knowledge
there is no existing CMake feature that currently supports this.

Has anyone else encountered the problem?  If not, would the devs
consider adding a per-config CMAKE_INSTALL_PREFIX feature for the
multi-config tools?

Thanks,
CY
-- 

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] Is there any way to set a build-type specific install path for multiconfig tools?

[Clifford Yapp]

On Mon, Jul 13, 2015 at 12:05 PM, David Cole dlrd...@aol.com wrote:
 I think this should be achievable somehow with CMAKE_INSTALL_PREFIX
 set to /parent_dirs and then using appropriate DESTINATION and
 CONFIGURATIONS arguments to the CMake install commands.

 Have you tried using the CONFIGURATIONS args to the install command?

We haven't tried altering the install commands, but there's a
difficulty there - we don't always control all the CMake code in our
build.  We include some 3rd party libraries and try to keep their code
as close to vanilla as possible, which means it would be vastly
preferable not to need to track down and redo all the install commands
in that code whenever we needed to re-sync.

Thanks,
CY
-- 

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-developers] Wrapping functions in CMake

[Clifford Yapp]

On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp cliffy...@gmail.com wrote:

 2.  Provide similar lists of all defined targets for the various types
 (e.g. CMAKE_EXECUTABLE_TARGETS, CMAKE_LIBRARY_TARGETS,
 CMAKE_CUSTOM_TARGETS).

Looking into the CMake sources, it seems like this information is
stored already in the global target map - what would be the correct
way to expose that information in variables in CMake script space?

Thanks,
Cliff
-- 

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-developers

Re: [CMake] Problem with CMake 3.3.0-rc3

[Clifford Yapp]

On Mon, Jul 6, 2015 at 11:53 AM, Brad King brad.k...@kitware.com wrote:

 Still, if we can easily fix 3.3 to not regress existing BRL-CAD
 releases then we should do so.  Can you use the above information
 to strip it down to a minimal example showing the problem?

OK, more info - it looks like the problem is limited to the CMake GUI
configure (although I haven't been able to test ccmake, the basic
cmake works) and the test file is pretty simple:

# Minimum required version of CMake
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

# Set CMake project name
project(TEST)

configure_file(test test1)

function(configure_file file targetfile)
  _configure_file(${file} ${targetfile} ${ARGN})
endfunction(configure_file)

configure_file(test test2)

Having the first configure_file before the redefinition and the second
after it seems to do it in the GUI, but only on the second configure
pass.

Cheers,
CY
-- 

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-developers] Wrapping functions in CMake

[Clifford Yapp]

On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp cliffy...@gmail.com wrote:

 3.  Have one or a number of variables that will hold in memory all the
 text written out by message (CMAKE_MESSAGES, CMAKE_STATUS_MESSAGES,
 CMAKE_ERROR_MESSAGES, etc.) so the CMakeLists.txt file can create log
 files reflecting what the user is seeing on the console window.

Actually, thinking about that, what's really needed is not an
in-memory log but a way to specify log files, since an unexpected
crash or exit is not a situation under which such in-memory logs could
be reliably written to disk.  So it would instead need to be
CMAKE_STATUS_MESSAGE_LOG, CMAKE_ERROR_MESSAGES_LOG, etc. which would
hold paths to which messages would be copied before being written to
stdout/stderr.

Cheers,
Cliff
-- 

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-developers

[cmake-developers] Wrapping functions in CMake

[Clifford Yapp]

A problem has arisen with CMake and BRL-CAD in 3.3, and it looks like
it may relate to some command overriding BRL-CAD does in order to
support some of our more advanced build features.  The feature we are
using to do this is an unsupported debug feature, and Brad King
suggested moving over to cmake-developers list to discuss why we are
doing what we're doing and how it might be supported.  (The initial
context of the discussion can be found here:
http://public.kitware.com/pipermail/cmake/2015-July/061026.html)

Our use of function overrides of basic CMake commands is driven by
four primary needs:

1.  First, we need to maintain a list of all files in the source
repository that are known to the build system.  To do this we maintain
a global list of files, define a custom CMAKEFILES command to allow us
to manually specify miscellaneous files as known, and override all
of the primary target creating commands to add their files to the list
(for example, add_executable is passed a list of source files, and all
of those files are automatically added to the known files list by
the function override of add_executable.)  This list is used for both
our make-clean-in-src-dir feature and our distcheck build target
(which does a number of verification steps using the version control
system, the build system and the files-on-filesystem information to
make sure the build logic is current.)

2.  Second we maintain global lists of all exec, library, and custom
targets.  This allows us to run timestamping build targets that run at
the very beginning and very end of the build process, by setting up
target dependences for the beginning and ending timestamp targets.
The ending time stamp target must depend on every other build target,
and the beginning timestamp is depended on by every other build
target.  To do this, as far as I know, we need lists of all build
targets so we can set this up with the add_dependencies command.

3.  Third, we override the message function to append all messages
written to the console to a log file.  This is to allow users to send
us a complete record of what they saw on the console during a
configure process.

Normally this sort of thing is handled by custom wrapper functions or
macros, rather than overriding the CMake defaults.  For our own build
targets, we actually do have our own custom wrappers where we do much
more than the above three steps.  The reason these three steps must be
done for vanilla CMake commands is that we need this information
from our src/other build dependencies as well.  These dependencies are
separate build logic that does not rely on BRL-CAD macros, and we try
to change the upstream logic as little as possible.  For a number of
reasons, we have found that the best way to handle these src/other
sub-projects is to add them to our overall project build directly.
However, this means we need a way to override the behaviour of their
target generating functions and message outputs to fit into the
overall BRL-CAD system without changing the logic of the src/other
sub-builds.

My ideal CMake features to accomplish each of the above would be:

1.  Have CMake internally maintain a list (or maybe per-command lists
for more flexibility) of all files with paths relative to the root
source directory that have been observed by add_executable,
add_library, add_custom_target, add_subdirectory, and configure_file
that can be accessed via CMake variables (e.g.
CMAKE_EXECUTABLE_SOURCE_FILES, CMAKE_LIBRARY_SOURCE_FILES, etc.)  This
is essentially the bookkeeping we are doing manually now, and a CMake
provided global variable set would make it unnecessary to override the
commands to get it.  Files marked as GENERATED are not counted in
these lists, as they are considered build output.

2.  Provide similar lists of all defined targets for the various types
(e.g. CMAKE_EXECUTABLE_TARGETS, CMAKE_LIBRARY_TARGETS,
CMAKE_CUSTOM_TARGETS).

3.  Have one or a number of variables that will hold in memory all the
text written out by message (CMAKE_MESSAGES, CMAKE_STATUS_MESSAGES,
CMAKE_ERROR_MESSAGES, etc.) so the CMakeLists.txt file can create log
files reflecting what the user is seeing on the console window.

It's possible some of these features have been added over the years
and I missed the announcements, so if they already exist I'd be
grateful for any pointers.  If they don't exist, would it be practical
to add them?

Thanks,
Cliff
-- 

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:

[CMake] Problem with CMake 3.3.0-rc3

[Clifford Yapp]

When running the BRL-CAD configure process with the latest CMake
release candidate, the first configure pass completes successfully.
The second pass fails almost immediately with the error:

CMake Error at CMakeLists.txt:120 (configure_file):
Unknown CMake command configure_file.

Configuring incomplete, errors occurred!

Has anyone else seen this?

Cheers,
CY
-- 

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] CTest location of executables on Windows

[Clifford Yapp]

That got it - thank you!

For future reference, anyone wanting to run ctest from a CMake target
in msvc needs to have the -C $CONFIG option specified:

add_custom_target(check COMMAND ${CMAKE_CTEST_COMMAND} -C $CONFIG -E
check-tests)

CY
-- 

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] CTest location of executables on Windows

[Clifford Yapp]

We have a ctest setup in our software that runs a series of test
executables , and the setup works well on Linux.  When trying to run
the same setup on Windows, ctest reports the following:

Test project C:/Users/User/project-build
  Start   1: bu_test_1
Could not find executable tester_bu_test_1
Looked in the following places:
tester_bu_test_1
tester_bu_test_1.exe
Debug/tester_bu_test_1
Debug/tester_bu_test_1.exe
Release/tester_bu_test_1
Release/tester_bu_test_1.exe
Unable to find executable: tester_bu_test_1

The executable is actually located at Debug/bin/tester_bu_test_1.exe
(all of our binaries are put in that subdirectory) but I can't figure
out how to let CTest know to search there.  Does anyone know how to
specify search directories for CTest to look in?

Thanks,
CY
-- 

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] Default selected build configuration when opening Visual Studio project

[Clifford Yapp]

We have a large project defined in CMake that we generate Visual
Studio solution files for, and we've noticed that even if the default
build type is set to Release in CMake, the Visual Studio project still
opens in Debug mode by default.  Is there some setting we can enable
that would make Visual Studio open up the project by default with the
same configuration specified as default by CMake?

Cheers,
CY
-- 

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] Using a toplevel CMakeList.txt to build all sub projects at once.

[Clifford Yapp]

On Thu, Feb 6, 2014 at 1:14 AM, PCMan pcman...@gmail.com wrote:

 libqtxdg - a base lib required by others
 liblxqt - a library depends on libqtxdg
 lxqt-config - a tool depends on liblxqt and libqtxdg.

 To build lxqt-config, liblxqt and libqtxdg need to be installed first.

The key is whether you can avoid the need to actually have these
installed.  The first step is to use CMake's RPATH support so things
work both from the build directory and the install directory:

http://www.cmake.org/Wiki/CMake_RPATH_handling

The settings BRL-CAD has been using for this purpose are:

# use, i.e. don't skip the full RPATH for the build tree
set(CMAKE_SKIP_BUILD_RPATH FALSE)

# when building, don't use the install RPATH already
# (but later on when installing)
set(CMAKE_BUILD_WITH_INSTALL_
RPATH FALSE)

# the RPATH/INSTALL_NAME_DIR to be used when installing
if (NOT APPLE)
  set(CMAKE_INSTALL_RPATH
${CMAKE_INSTALL_PREFIX}/${LIB_DIR}:\$ORIGIN/../${LIB_DIR})
endif(NOT APPLE)
# On OSX, we need to set INSTALL_NAME_DIR instead of RPATH
# 
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_INSTALL_NAME_DIR
set(CMAKE_INSTALL_NAME_DIR ${CMAKE_INSTALL_PREFIX}/${LIB_DIR})

# add the automatically determined parts of the RPATH which point to
# directories outside the build tree to the install RPATH
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

 So simply adding them using add_subdirectoy() won't work.

The second step (after the above) is to populate the *LIBNAME*_LIBRARY
and related variables that the Find*LIBNAME*.cmake (or whatever your
sub-projects are using to find their needed libraries) with the build
target names of the libraries instead of the paths.  CMake will
successfully interpret the build targets in place of the installed
library paths if those libraries are part of the current CMake build.

 When configuring lxqt-config, liblxqt needs to be installed first.
 To configure and compile liblxqt, cmake modules and headers from
 libqtxdg are required so libqtxdg needs to be installed first.

Using the above steps, lxqt-config's configure step should see the
build target location for liblxqt.  The question now becomes a matter
of whether there is anything in the libraries or lxqt-config that
assumes absolute placement of resource files in install paths during
compilation.  If you don't have anything making such assumptions, the
above two steps may be enough.

 Is it possible to use CMake to build them all at once since one
 component requires that the other is installed first.

Building them all at once shouldn't be necessary, barring other
issues...  Since you're building libraries and then an executable, I'd
be fairly surprised if you encounter major difficulties - the
meta-project including the others with add_subdirectory should sort
out the build dependencies.

The *real* challenge is if you need to not just build lxqt-config but
also *run* it from the build directory without installing it.  If
lxqt-config or its libraries make assumptions about the location of
resource files that involve install paths, those assumptions will
naturally fail in the build directory.  BRL-CAD encountered a number
of these issues (Tcl packages were especially entertaining) but in the
end all of them proved solvable and today you can run all of BRL-CAD
from the build directory.  If you *don't* need to run programs in the
build directory as part of your build and/or testing process, things
are much simpler.

 Even worse, two of our components are still automake-based.
 The cmake ExternalProject_Add() command did not solve the problem that
 some of them needs to be installed first before others can be
 compiled.

Ah.  This is probably the fly in the soup.  There may be other
solutions, but in the end I wound up creating several CMake build
systems for third party components simply to make everything work
without requiring the install step as part of the CMake build step.
This proved worthwhile for several other reasons, not the least of
which was that at least some of the autotools projects we were using
would have needed new build system work anyway to function with Visual
Studio, but if you're not interested in Windows/MSVC it's a bit more
of a dilemma.  How come two of the components have remained with
Autotools?  Is the plan to eventually migrate them?

 I tried to google and read the existing docs but remain clueless.
 We're stuck! Any help is really appreciated.
 Thank you very much!

You can take a look at what BRL-CAD does since we do solve this
problem or at least a very similar one, but unfortunately our
third-party logic is rather complicated - we have a system that allows
for using system or bundled components in a variety of combinations
based on user settings and autodetection, which may prove to be
overkill for your situation:

http://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/src/other/CMakeLists.txt
http://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/misc/CMake/ThirdParty.cmake

See 

Re: [CMake] AStyle or similar code beautifier

[Clifford Yapp]

On Fri, Jan 31, 2014 at 2:01 AM, Rob McDonald rob.a.mcdon...@gmail.com wrote:
 All,

 I'm interested in adding a code beautifier to my project.  I'm looking at
 AStyle, but am open to others.

 Implementing a FindAStyle.cmake is pretty trivial.  Likewise, implementing
 custom targets is pretty straightforward in the simple case.

 However, I thought there might be some canonical/idiomatic examples of this
 sort of thing.  Any pointers to projects that do this particularly well?
 Are there any other code beautifiers that already have CMake support?

I don't know of any canonical way of doing this - it's going to
pretty similar to targets that run doxygen or otherwise trigger custom
action, assuming the idea is to have make astyle-format or something
similar that runs astyle on all your source files.

BRL-CAD has implemented (working but not yet activated for default
use) an integration of astyle that makes incorrect styling of source
code files a compile-time error when building the system.  It's both
more elaborate and more invasive than a run astyle build target, but
does compel developers to take styling rules seriously.  Sort of like
-Werror for code formatting.  There's also the option of print
noisy warnings but keep building for a less draconian approach that's
still hard to ignore.

Cheers,
CY
-- 

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] Correct way to make an arbitrary file trigger a reconfigure...

[Clifford Yapp]

On Tue, Oct 15, 2013 at 10:16 AM, Malfettone, Kris
kris.malfett...@sig.com wrote:

 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.

+1 nice idea

I too have had the issue of wanting to trigger a cmake re-configure
based on the timestamp of a file that is not (normally) part of the
configure process, and ended up using similar work-arounds.

Cheers,
CY
--

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] CMake in Vim

[Clifford Yapp]

On Thu, Sep 26, 2013 at 4:39 PM, Jacky Alciné jackyalc...@gmail.com wrote:
 Hey all,

 I’ve been working on a Vim plug-in for Cmake. It provides a bit of support but
 it’s on the rise and I’d love to hear from the Vim + Cmake users about it.

 http://jalcine.github.io/cmake.vim/

 Cheers!

So we can put this in context, how does the functionality of this
plugin relate to the functionality from these files?

http://www.cmake.org/CMakeDocs/cmake-syntax.vim
http://www.cmake.org/CMakeDocs/cmake-indent.vim

I.e. is it complementary, is it intended to replace the above two files, etc.

Thanks,
CY
--

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] CMake 2.8.12-rc1 Released

[Clifford Yapp]

On Mon, Aug 26, 2013 at 9:49 PM, Clifford Yapp cliffy...@gmail.com wrote:

 After turning off all the src and doc subdirectories, I can still
 trigger the rebuild - here's the diff between the CMake outputs in the
 4a6397a70c2b467b1285be4c0bae7533eb16f5e0 and
 ad502502dfee281e5b0ad8ac57057d72220b4380 generated build outputs:
 http://brlcad.org/~starseeker/before-and-after.diff

I can try stripping things down further, but it won't be until this
evening at the earliest before I get a chance - let me know if you
need me to keep going.

CY
--

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] CMake 2.8.12-rc1 Released

[Clifford Yapp]

I finally got it boiled down to a relatively simple test case - see

http://brlcad.org/~starseeker/Ninja-Problem-CMakeLists.txt

This is what I'm seeing here with that test:

user@machine:~/brlcad/build$ rm -rf *  cmake .. -G Ninja
-- The C compiler identification is GNU 4.7.3
-- The CXX compiler identification is GNU 4.7.3
-- Check for working C compiler using: Ninja
-- Check for working C compiler using: Ninja -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of socklen_t
-- Check size of socklen_t - failed
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/brlcad/build
user@machine:~/brlcad/build$ ninja
[1/1] Re-running CMake...
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/brlcad/build
ninja: no work to do.
user@machine:~/brlcad/build$
--

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] CMake 2.8.12-rc1 Released

[Clifford Yapp]

On Mon, Aug 26, 2013 at 9:28 PM, Clifford Yapp cliffy...@gmail.com wrote:

 I'll see if I can dig any deeper.

After turning off all the src and doc subdirectories, I can still
trigger the rebuild - here's the diff between the CMake outputs in the
4a6397a70c2b467b1285be4c0bae7533eb16f5e0 and
ad502502dfee281e5b0ad8ac57057d72220b4380 generated build outputs:
http://brlcad.org/~starseeker/before-and-after.diff
--

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] CMake 2.8.12-rc1 Released

[Clifford Yapp]

On Mon, Aug 26, 2013 at 12:32 PM, Robert Maynard
robert.mayn...@kitware.com wrote:
 I am able to replicate this problem with the 2.8.12rc1. Are you able
 to construct a minimal test case so I can dig into why this is
 happening?

Robert,

So far I haven't had much luck creating a minimal test case, but I
think I've pinpointed the change that introduce the observed
behaviour:

cmMakefile: Track configured files so we can regenerate them (#13582)
ad502502dfee281e5b0ad8ac57057d72220b4380

It's parent, 4a6397a70c2b467b1285be4c0bae7533eb16f5e0, does not re-run ninja.

I'll see if I can dig any deeper.
--

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] CMake 2.8.12-rc1 Released

[Clifford Yapp]

Just as a datapoint, the Ninja build of BRL-CAD when performed with
this version of CMake results in Ninja re-running CMake every time
before building.  Is anyone else seeing this behaviour?  I don't see
it with the 2.8.11.2 release.  Upgraded ninja to the latest github
build just to be sure I wasn't missing a Ninja feature, but seeing the
same behaviour - 2.8.11.2 doesn't re-run CMake, 2.8.12rc1 does.
Platform is Ubuntu Linux.

CY
--

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] Bug fix requests for the *next* release of CMake...

[Clifford Yapp]

http://public.kitware.com/Bug/view.php?id=11575


On Wed, Nov 7, 2012 at 2:40 PM, David Cole david.c...@kitware.com wrote:

 Hi all,

 Replies requested. Short replies only. Read on. Just a short reply
 with bug numbers or links to the bugs is all we need here.

 Example one-line reply:

   http://public.kitware.com/Bug/view.php?id=13571

 Please move specific discussions into the bugs themselves or start a
 new thread to talk about it... Replies on this thread should just be a
 collector for bug numbers.

 We are aiming for approximately quarterly releases from now on,
 scheduling them every 3 to 4 months. The next release of CMake will
 likely be version 2.8.11, scheduled to have an rc1 release candidate
 on Wed. January 9, 2013 -- just 9 weeks from today.

 If you have a particular issue that you think should be fixed for
 inclusion in 2.8.11, please bring it up within the next two weeks.
 Ideally, each issue will be discussed as needed on the mailing list to
 come to any consensus about what should be done to fix it, and then an
 entry in the bug tracker may be used to keep it on the radar screen,
 and to track activity related to it. You can see what's already on the
 roadmap for this release here:

   http://public.kitware.com/Bug/roadmap_page.php?version_id=103

 Patches are always welcome. Patches that include testing of any new
 features, or tests that prove a bug is really fixed on the dashboards,
 (basically any patch with testing) is preferred over a patch with no
 testing. Also, if you are *adding* code, then you also probably need
 to add *tests* of that code, so that the coverage percentage stays as
 is or rises.

 Please discuss issues here as needed, and add notes to existing issues
 in the bug tracker that you are interested in seeing fixed -- we will
 be looking at the mailing list and activity in the bug tracker to help
 prioritize the bug fixes that will occur in the near future.


 Thanks,
 David Cole
 Kitware, Inc.


 P.S. - as a nice summary of what we accomplished in the CMake 2.8.10
 release, see here:
 http://public.kitware.com/Bug/changelog_page.php?version_id=100 -- it
 currently lists 58 issues that we resolved: nice job, everybody!

 (Many of those were specifically addressed because somebody asked for
 it right here on the mailing list... Don't be shy!)
 --

 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

--

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] How clean generated build system files

[Clifford Yapp]

On Sun, Nov 4, 2012 at 4:45 AM, lzprgmr baiyanhu...@gmail.com wrote:

 Thanks guys, so it is not supported currently in cmake for whatever
 reasons.


It's not supported as a direct feature, to the best of my knowledge.

That said, it is technically possible to do - it just requires you to
create your own system on top of CMake.  The BRL-CAD project implements
such a system. To see how, check out how we implement our distclean
target - that command restores the source directory to pristine condition.
Be warned - it's one of the more complex aspects of our build system and
depends on a number of other customizations.  If an out-of-source-dir
solution is sufficient, I wouldn't advise complicating your build logic -
we had most of the pieces in place for other reasons, so for us distclean
was a fairly minimal step on top of them.
--

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] Check if a command exists?

[Clifford Yapp]

On Mon, Sep 3, 2012 at 3:59 PM, Rui Maciel rui.mac...@gmail.com wrote:
 I have a small project which includes a couple of parsers whose lexers are
 generated by re2c.  I intended to set cmake so that it could check if re2c
 is present in the system, but after browsing through the docs I've ended up
 empty-handed.

Just an FYI - you may find the following CMake files helpful when
working with re2c:

http://brlcad.svn.sf.net/viewvc/brlcad/brlcad/trunk/misc/CMake/RE2C_Util.cmake
http://brlcad.svn.sf.net/viewvc/brlcad/brlcad/trunk/misc/CMake/FindRE2C.cmake

They could use some cleanup, but they may be a helpful starting point.

Cheers,
CY
--

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] FindX11 vs. Lion

[Clifford Yapp]

On Tue, Aug 21, 2012 at 2:38 PM, Randolph M. Fritz rfr...@lbl.gov wrote:

 What problems did your solutions address?  I've skimmed them, but am not
 sure I understand them.  I'd also be interested in hearing from anyone else
 who has done this, and even people who have done it on Windows systems.

In our specific case, the problem was we have a Mac with both a
system X11 and a MacPorts/Fink X11 - mixing and matching is Not Good,
so get FindX11 to avoid mixing them.

The basic idea is to forbid CMake from searching Fink/MacPorts paths
for libraries if they are disabled.  The broader problem of multiple
distinct X11 installations we do not address - that has lots of sharp
corners that would be a pain to deal with.  Our FindX11 will warn if
it sees X11 libraries coming from different prefixes, but sometimes
symlinking means it's finding the same libraries anyway...  In the
case of a MacPorts install that doesn't have everything we need but
has SOME of it, we don't avoid finding the System versions of those
libraries if we specify that we want MacPorts.  So the best we can do
at this point is warn - ideally it shouldn't return any non-MacPorts
X11 libs though.

To really avoid finding undesirable X11 components on a system with
multiple X11 installs, you'd probably have to do an individual,
directory constrained search through *all* the system search paths for
one of the core X11 libs and/or headers.  Once you have built up a set
of candidates, you would then have to run the full X11 search logic,
constrained to each candidate path, and build up search results for
each candidate.  Then, once you have built all of those candidate
sets, you'll have to decide which one satisfies the search criteria
and set all the final X11 variables used by programs.

I've tried something similar when searching for Tcl/Tk - it's very
easy to have search logic of that nature get crazy complex.  Since
excluding MacPorts and Fink paths from search results deals with (for
us) the most common case of multiple X11s, the considerable effort to
build a set enforcing X11 search hasn't been undertaken yet.

There's probably some sort of more general define a set of components
and return all available sets on the system functionality that could
be speced out for this stuff, but I haven't really thought too hard
about what it would look like generally - if its needed for X11
though, it's probably worth taking the time to do right.

Cheers,
CY
--

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] FindX11 vs. Lion

[Clifford Yapp]

On Fri, Aug 17, 2012 at 3:36 PM, Randolph M. Fritz rfr...@lbl.gov wrote:
 (well, the title was too good to pass up.)

 I am having problems with FindX11 on Mac OS 10.7 (Lion).  FindX11
 unpredictably finds libraries in /usr/X11R6/lib and symbolic links to
 libraries in /opt/local/lib (the MacPorts port library.)

BRL-CAD attempts to address this with a combination of a module for
managing Fink and MacPorts search paths and our own variation on
FindX11.cmake:

http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/misc/CMake/FindX11.cmake?revision=52113
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/misc/CMake/Fink_MacPorts.cmake?revision=52069

 On Lion, the Apple X server files always reside in /usr/X11; include files in 
 /usr/X11/include
 and libraries in /usr/X11/lib.  All other locations are symbolic links,
 except in the unusual case when a Lion system has a non-Apple X server.

 Is there any simple way to tell FindX11 to leave /opt/local (and probably
 also /sw and /usr/local) alone, unless I want it to pay attention to them?
 Or perhaps only use the Apple X11 server unless instructed otherwise?

The above two files may prove helpful, although I don't think we
currently exclude /opt/local - they're BSD licensed so feel free to
customize them for your needs.

 Then again, Apple has removed X11 support from Mountain Lion (10.8),
 referring X11 users to the open source XQuartz.  I have no idea what the
 XQuartz installation is like, though it may be similar to the older Apple
 server.

Not sure how this will impact things - I don't think I've tested
against an XQuartz install in a while.

Cheers,
CY
--

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] Bug fix requests for the *next* release of CMake...

[Clifford Yapp]

http://public.kitware.com/Bug/view.php?id=11575
--

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] CMake 2.8.9-rc1 ready for testing!

[Clifford Yapp]

On Fri, Jun 22, 2012 at 3:34 PM, David Cole david.c...@kitware.com wrote:
 I am happy to announce that CMake 2.8.9 has entered the release candidate 
 stage!

Awesome!  I tried 2.8.9-rc1 with the latest Ninja, and it looks like
this issue is still present:

http://public.kitware.com/Bug/view.php?id=13145

Not sure if that was on the fix it for 2.8.9 agenda, but figured I'd
mention it given all the other Ninja work visible in the changelogs.

Cheers,
CY
--

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] CMakeCache.txt, MSVC generator, and automatic re-configuration

[Clifford Yapp]

On Thu, Jun 7, 2012 at 12:27 PM, Bill Hoffman bill.hoff...@kitware.com wrote:

 What version of Visual studio?  And, do you have a small reproducible test
 case for this?

Oops - missed replying to the list.  Visual Studio 2010.  I can try to
create a small test case, but in the mean time we can avoid the issue
by setting CMAKE_SUPPRESS_REGENERATION to ON for Visual Studio
generators only.  As long as Visual Studio can't cleanly handle
re-loading everything quietly after a CMake re-run, there's no point
in allowing regeneration from Visual Studio at all.  Perhaps an
alternative would be to print a warning that the CMakeCache.txt file
looks newer than the generated build system - is there anything in
CMake that can provide that capability?

Thanks,
Cliff
--

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] CMakeCache.txt, MSVC generator, and automatic re-configuration

[Clifford Yapp]

I noticed when doing a recent test of our build with CMake 2.8.8 and
MSVC that the CMakeCache.txt file seems to be getting changes applied
to it during the generation step (primarily a lot of additions with
the comment Stored GUID, seemingly related to custom
commands/targets.)  One of the things I've noticed when doing Windows
builds is that it seems to be very important that the CMakeCache.txt
file after Configure/Generate not be in a state that triggers an
automatic re-running of CMake out of the box in MSVC - we have
hundreds of build targets and the interactive prompting is a killer
for usability.  From what I have seen previously, it looks like this
automatic re-run takes place whenever the CMakeCache.txt file changes
after the Configure step is complete.  That was previously happing
due to quirks with our build, but we had found ways to avoid the
problem and were getting a clean MSVC build with no CMake
re-running. I don't recall seeing this Stored GUID content appearing
in the generator step previously - is this new?

Any help appreciated.
CY
--

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] Overriding the toplevel directory name in a TGZ package?

[Clifford Yapp]

The CPack tool provides a variable CMAKE_INCLUDE_TOPLEVEL_DIRECTORY
option to control whether to set a toplevel directory in (say) a
tar.gz archive, but so far I have not been able to figure out if there
is a way to change this directory name to something not directly based
on the file name.  Trying to override CPACK_TOPLEVEL_DIRECTORY doesn't
seem to work.

Is there any way to get a tar.gz archive named (say)
NEW_PROJECT-3.1.1.tar.gz that unpacks into a toplevel directory simply
called PROJECT?

Thanks,
CY
--

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 generator is Linux-only?

[Clifford Yapp]

Taking a quick look around, here's what I'm seeing:

Current unresolved Ninja issues that are filed in the bug tracker:

http://public.kitware.com/Bug/view.php?id=13067
http://public.kitware.com/Bug/view.php?id=13073
http://public.kitware.com/Bug/view.php?id=13145
http://public.kitware.com/Bug/view.php?id=13158
http://public.kitware.com/Bug/view.php?id=13159
http://public.kitware.com/Bug/view.php?id=13105
http://public.kitware.com/Bug/view.php?id=13069

There also appears to be a lot of dev activity/discussion taking place:

http://public.kitware.com/pipermail/cmake-developers/2012-April/003782.html
http://public.kitware.com/pipermail/cmake-developers/2012-April/003787.html
http://public.kitware.com/pipermail/cmake-developers/2012-May/004011.html
http://public.kitware.com/pipermail/cmake-developers/2012-April/003878.html
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake Ninja generator issues: any showstoppers?

[Clifford Yapp]

On Tue, Apr 17, 2012 at 4:59 PM, David Cole david.c...@kitware.com wrote:
 Hello CMake Ninja fans,

 We are going to be creating the CMake 2.8.8 final release tomorrow. However,
 there are issues reported for the ninja generator. Does anybody consider
 them showstoppers ??

David,

Does the latest CMake 2.8.8 source tree have this fix?

http://www.cmake.org/pipermail/cmake/2012-April/049772.html

Even if it's not the ideal fix, I just tested it and it does seem to
address one of the ninja clean target issues I was seeing.  Not really
a show-stopper (definitely not worth another RC, if that's what would
be involved) but would be a nice-to-have.

CY

P.S. - Is it expected that Ninja respect the
ADDITIONAL_MAKE_CLEAN_FILES property, or is there a separate property
for each generator?  If the latter, is there some common property
that can be used to have all generators' clean rules remove the files?
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Cross-compilation on Linux targeting Windows

[Clifford Yapp]

On Thu, Apr 12, 2012 at 8:47 AM, hendrik hendrik@localhost wrote:

 Linux can automatically call wine for windows executables if you make them
 executable (+x).
 In Debian, it is enabled using this package:
 http://packages.debian.org/sid/binfmt-support

Interesting - I'll have to see if Gentoo offers something similar.

 OTOH, your tests may not show the desired result as you test the program
 behaviour in wine, not Windows.

True... but perhaps, with luck, wine + the mingw packages + a good
toolchain file would be close enough to get a compile that would
work on Windows.  A lot of what we need to do when we run programs is
generate source code, run tcl shell, and other things that (in
principle) shouldn't need to care what OS they are on.

The only other fully open source option I can think of would be to
try using ReactOS - has anyone ever successfully built binaries on
ReactOS and then deployed them on Windows?

Cheers,
CY
--

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] CMake 2.8.8-rc1, Ninja generator, and clean target

[Clifford Yapp]

Trying to run the clean target with the Ninja generator in the latest
CMake, I noticed that on targets with version properties set like (say):

set_target_properties(libbu PROPERTIES VERSION 19.0.1 SOVERSION 19)

the ninja -t clean command does not remove the libbu.so.19 link.

Has anyone else seen this issue?

Cheers,
CY
--

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] Warn on Macro re-definition?

[Clifford Yapp]

Is there any flag or setting I can turn on in CMake to have it print a
warning when in the course of a CMake configure a macro definition is being
re-defined?  Occasionally a sub-configure that I've tried to set up as
being independent will have an older copy of a macro that is missing
features and the symptoms can look like mysterious failures in the new
version I'm working on - an optional warning that a macro definition is
getting stomped on would be very helpful, if there is any way to do this in
CMake.

Thanks,
CY
--

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 executables - local targets vs. system binaries

[Clifford Yapp]

In a number of places in our build, we use compiled binaries via
add_custom_command and friends to perform work during the compilation.  For
the most part we are able to successfully specify the target name used with
add_executable in place of a full path to successfully tell CMake to run
the locally built binary, but there's a corner case that's causing a bit of
trouble.

We have locally built versions of several tools that might be found on some
systems, but cannot be relied upon to be there in all cases (Windows, in
particular, expands the set of can't always depend on it being available
significantly.)  In some build configurations we want to use our local
verisons of these tools even when system versions are present (testing,
making sure the version we use supports what we need, etc.).  This is where
we get into trouble - if the system version of our locally built tool is in
the path, and the executable name matches the CMake target name, it looks
as though the generated build files will use the system version in
preference to the locally built version.

Is this expected behavior, and if so is there a setting that can be set to
make CMake prefer the local target over the system version in cases where
both are present?  It doesn't matter much when using systems like Make
since I can supply the full path to the locally built target, but for
multi-configuration systems like Visual Studio this path changes at build
time, not CMake configure time.

Any insight appreciated!

CY
--

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] CMake configuration times with Microsoft Visual C++

[Clifford Yapp]

We use the same configuration tests on all platforms in an effort to avoid
having large chunks of platform-specific code in our build files, but we
pay a price for this on Windows - the same test process is more than an
order of magnitude slower with MSVC than (say) Linux.

Does CMake launch the MSVC C++ compiler each time it needs to do a
TRY_COMPILE or similar test?  If so, does anybody know of any techniques
for combining tests or some way to run a cl.exe instance as a daemon to
which multiple files can be fed without needing a full restart of cl.exe?

Cheers,
CY
--

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] Enhancement to CHECK_C_RUNS_SOURCE

[Clifford Yapp]

On Thu, Feb 2, 2012 at 11:59 AM, Alexander Neundorf a.neundorf-w...@gmx.net
 wrote:


 I think so.
 In this case, this should also be added to CheckCXXSourceRuns,
 CheckCSourceCompiles and CheckCXXSourceCompiles.

 Alex


http://cmake.org/Bug/view.php?id=12944

Patch changes all four files and addes a note to the documentation at the
beginning of each file.

Cheers,
Cliff
--

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] Enhancement to CHECK_C_RUNS_SOURCE

[Clifford Yapp]

OK - how should I proceed?  File a bug report and submit patches for
all of the files?

Cheers,
CY

On Thu, Feb 2, 2012 at 11:59 AM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:

 I think so.
 In this case, this should also be added to CheckCXXSourceRuns,
 CheckCSourceCompiles and CheckCXXSourceCompiles.

 Alex
--

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] Enhancement to CHECK_C_RUNS_SOURCE

[Clifford Yapp]

On Wed, Feb 1, 2012 at 2:35 AM, Rolf Eike Beer e...@sf-mail.de wrote:
 Am Dienstag, 31. Januar 2012, 19:27:22 schrieb Clifford Yapp:
 We currently have a minor local enhancement to CHECK_C_RUNS_SOURCE

 This is at least missing documentation ;)

 Eike

I can add that if there is any chance of it being accepted upstream.

Cheers,
CY
--

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] Enhancement to CHECK_C_RUNS_SOURCE

[Clifford Yapp]

We currently have a minor local enhancement to CHECK_C_RUNS_SOURCE
that I would like to contribute back to the main module, if it is
acceptable to the developers of CMake:

We often have our own .c file stored in our tree for TRY_RUN testing,
and it is convenient to be able to use CHECK_C_RUNS_SOURCE for testing
those .c files.  At the moment, CHECK_C_RUNS_SOURCE assumes the
incoming SOURCE  variable actually holds the source code - our
enhancement checks to see if SOURCE holds a valid file path first.  If
it DOES hold a valid file path, TRY_RUN then trys that .c file,
otherwise the existing CHECK_C_RUNS_SOURCE is preserved.  I don't know
of any sane pathname that would be valid C code or vice versa, so
there should be no danger of passing in a C source snippit and having
it mistaken for a file path.

The diff is below - would this be of interest for main-line CMake?

Thanks,
CY

--- ../../CheckCSourceRuns.cmake2012-01-31 19:19:58.0 -0500
+++ misc/CMake/CheckCSourceRuns.cmake   2012-01-31 19:16:05.0 -0500
@@ -86,13 +86,18 @@
 ELSE(CMAKE_REQUIRED_INCLUDES)
   SET(CHECK_C_SOURCE_COMPILES_ADD_INCLUDES)
 ENDIF(CMAKE_REQUIRED_INCLUDES)
-FILE(WRITE ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/src.c
-  ${SOURCE}\n)
-
+IF(EXISTS ${SOURCE})
+  SET(CHECK_SRC ${SOURCE})
+ELSE(EXISTS ${SOURCE})
+  FILE(WRITE ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/src.c
+${SOURCE}\n)
+  SET(CHECK_SRC
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/src.c)
+ENDIF(EXISTS ${SOURCE})
+
 MESSAGE(STATUS Performing Test ${VAR})
 TRY_RUN(${VAR}_EXITCODE ${VAR}_COMPILED
   ${CMAKE_BINARY_DIR}
-  ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/src.c
+  ${CHECK_SRC}
   COMPILE_DEFINITIONS ${CMAKE_REQUIRED_DEFINITIONS}
   CMAKE_FLAGS
-DCOMPILE_DEFINITIONS:STRING=${MACRO_CHECK_FUNCTION_DEFINITIONS}
   -DCMAKE_SKIP_RPATH:BOOL=${CMAKE_SKIP_RPATH}
--

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] RUNTIME_OUTPUT_DIRECTORY and Visual Studio Express

[Clifford Yapp]

I'm trying to use set_target_properties to override the Output
Directory for dlls generated by add_library calls when building with
MSVC, as discussed back in July:

http://www.cmake.org/pipermail/cmake/2011-July/045591.html

I'm trying to do so as part of a re-definition of add_library, but
when compiling with Visual Studio 2010 Express and CMake 2.8.6 I still
don't seem to be able to override Output Directory:

  set(LIB_DIR lib)
  function(add_library name)
_add_library(${name} ${ARGN})
set_target_properties(${name} PROPERTIES RUNTIME_OUTPUT_DIRECTORY
${LIB_DIR})
  endfunction(add_library)

Despite the set_target_properties line, the dlls end up in bin instead
of lib.  Am I missing something?

Thanks for any insight,
CY
--

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] RUNTIME_OUTPUT_DIRECTORY and Visual Studio Express

[Clifford Yapp]

OK, I have switched my assignment to a full path form, and using
get_target_property to pull the value of RUNTIME_OUTPUT_DIRECTORY
indicates that the value is correct:

target_runtime_output_dir: C:/Users/User/brlcad/brlcad-build/lib

The lib and exp files are going to the right place:
Creating library C:/Users/User/brlcad/brlcad-build/lib/regex.lib and
object C:/Users/User/brlcad/brlcad-build/lib/regex.exp

Despite this, I'm still seeing the dll output in bin:
regex.vcxproj - C:\Users\User\brlcad\brlcad-build\bin\regex.dll

Would a local RUNTIME_OUTPUT_DIRECTORY setting be overridden by
setting the toplevel CMAKE_RUNTIME_OUTPUT_DIRECTORY* variables?  We do
set those at the top level to define our overall layout.

Thanks,
CY

On Fri, Jan 27, 2012 at 11:03 AM, David Cole david.c...@kitware.com wrote:

 Use a full/absolute path name for the directory. lib is not
 well-defined unless you know what it's relative to.
--

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] CMake + Ninja

[Clifford Yapp]

Confirmed - working now on Mac building BRL-CAD - thanks!

Cliff

On Sat, Jan 14, 2012 at 3:25 PM, Peter Collingbourne pe...@pcc.me.uk wrote:

 I managed to test these changes on a Mac and it fixed all but 7
 test failures, so I rolled it into the ninja-generator-pr branch.
 In terms of applications I didn't have time to try building anything
 other than CMake itself and LLVM/Clang (both successfully), but please
 let me know if there are any other problems with BRL-CAD.

 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

Re: [CMake] CMake + Ninja

[Clifford Yapp]

On Tue, Jan 10, 2012 at 12:03 AM, Peter Collingbourne pe...@pcc.me.uk wrote:

 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.

Awesome - thank you!  It'll be a week or so before I have access to a
Mac myself, but I'll give it a go once I do.

Cheers,
CY
--

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] Some issues with visual studio

[Clifford Yapp]

I can say that in my particular case, in order to be able to
successfully run compiled binaries from the build directory it is
necessary to have a broad variety of files in a sane position relative
to the compiled binary.  So far as I know, the only way I can do this
in systems that like to have multiple binary output locations is to
copy the files in question to their proper locations ahead of time
*for each possible configuration*.  Ouch.  And even that may not quite
be enough, depending on the specifics of the layouts in question.

My current work-around is to peg all of the output directories for all
the active configurations to the same directory - that negates much of
the benefit of multiple-configuration IDE options, but does at least
result in the expected run-from-build-directory behavior.  (It works
for MSVC - we apparently have too many targets or something for
XCode...)  You have to switch configs and re-build just like with Make
files, but that's the tradeoff currently required for being able to
run in the build directory.

Cheers,
CY

On Sun, Jan 8, 2012 at 4:08 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
 This is going to sound either harsh or flame bait but is written in all 
 seriousness and with a lot of practical experience.

  When coming from a makefile based system like Unix and going to Visual 
 Studio there are a few things you need to give up on (In my opinion). 
 Visual Studio (And Xcode) both like to separate build types into 
 Debug/Release/Others and put those items compiled into those subfolders. If 
 you try to have your output files put anywhere else you are endlessly 
 fighting the system and in the you will waste more time trying to fight the 
 system rather then working on your code. Unless you have a very valid reason 
 why your built items MUST be in the binary folder then I wouldn't really 
 worry where they land. Let Visual Studio or Xcode put them where they want. 
 You only need to realize that there _are_ Debug and Release subfolders and it 
 is in there that you will find your executables and libraries. This is said 
 with about 3 or 4 years of working with Linux, OS X, Windows, Visual Studio, 
 Xcode, Makefiles. Don't fight the system, just adapt to it and move on.

  I guess that was harsh. Sorry. Having said that I am very interested in 
 knowing the specific reasons why you need your executables in the 
 CMAKE_BINARY_DIRECTORY and can not have them in a subfolder.
 --
 Mike Jackson www.bluequartz.net
--

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] Some issues with visual studio

[Clifford Yapp]

On Sun, Jan 8, 2012 at 4:59 PM, Renato Utsch renatout...@gmail.com wrote:

 Clifford, can you explain more what you said, I didn't understand...

 You said that you change the output directories for all the active
 configurations to the same directory? Well, how do you do that (if it
 is what you said)? This is exactly what I want...

I learned how to do it from this posting:

http://forum.openscenegraph.org/viewtopic.php?t=6926
--

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] Some issues with visual studio

[Clifford Yapp]

Hmm - that looks interesting.  I didn't know about
SUPPORTS_PARALLEL_BUILD_TYPE - I'll have to review my setup with that
in mind.

Thanks!

On Sun, Jan 8, 2012 at 4:52 PM, J Decker d3c...@gmail.com wrote:

      if( SUPPORTS_PARALLEL_BUILD_TYPE )  # will be set in visual
 studio type projects...
        INSTALL( FILES ... DESTINATION ...${CMAKE_INSTALL_CONFIG_NAME}
 ... ) #CMAKE_INSTALL_CONFIG_NAME will be set for the build type you're
 doing.
--

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] CMake + Ninja

[Clifford Yapp]

Peter Collingbourne's ongoing work with CMake support for ninja (and
vice versa) was recently announced as being able to build multiple
large projects:

http://public.kitware.com/pipermail/cmake-developers/2011-November/002490.html

BRL-CAD was on the list, and in trials last night I confirmed that it
does indeed build BRL-CAD - nice work Peter!

The no-op build was indeed extremely fast (less than a second, vs.
more than ten even with a parallel make), and the full build time was
8 minutes 43 seconds as opposed to 9 minutes 8 seconds for make
(considering this is a Gentoo box and my compilation toolchains tend
to be optimized, I was actually pretty impressed - I will be
especially curious to see what happens on a Mac.  It would be
interesting to figure out a way to identify the compiler time only
number and be able to characterize the actual make/ninja overhead, to
know how close ninja comes to the ultimate least-time-possible build.)

In case anybody else wants to give ninja a spin, here's what I did to
test it (using bash as a shell):

git clone git://github.com/martine/ninja.git
git clone -b ninja-generator-pr git://github.com/pcc/CMake.git
export PATH=/home/user/ninja:/home/user/cmake-install:$PATH
cd ninja
./bootstrap.py
cd ../CMake
./bootstrap --prefix=/home/user/cmake-install
gmake  gmake install

Then configure your projects as normal, but specify the Ninja generator:

cmake -G Ninja

and build with ninja instead of make:

ninja


You can also specify individual targets - for example, if I want to
build just the main editor of BRL-CAD I can do:

ninja mged
--

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] CMake + Ninja

[Clifford Yapp]

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.

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?

Cheers, and thanks,
CY

On Fri, Jan 6, 2012 at 9:11 AM, Clifford Yapp cliffy...@gmail.com wrote:
 Peter Collingbourne's ongoing work with CMake support for ninja (and
 vice versa) was recently announced as being able to build multiple
 large projects:

 http://public.kitware.com/pipermail/cmake-developers/2011-November/002490.html

 BRL-CAD was on the list, and in trials last night I confirmed that it
 does indeed build BRL-CAD - nice work 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

Re: [CMake] Eclipse and CMake...

[Clifford Yapp]

Let's try replying to the list this time...

Eclipse 3.7.1 (Indigo) Eclipse succeeded in importing.  I'm not sure how
to do a C/C++ project build with Eclipse (or that my build of Indigo
actually added everything it needed to) but it looks like the CMake
project import part of the equation succeeded.

Test done using CMake 2.8.7 release candidate.

CY

On Fri, Dec 9, 2011 at 10:01 AM, David Cole david.c...@kitware.com wrote:
 On Fri, Dec 9, 2011 at 9:39 AM, Clifford Yapp cliffy...@gmail.com wrote:
 On Fri, Dec 9, 2011 at 6:41 AM, David Cole david.c...@kitware.com wrote:

 Please try with CMake 2.8.7-rc1, released yesterday. There have been
 several Eclipse related changes since 2.8.6.
 Then report back whether it is still a problem or not.

 Still seeing the same error (repeated multiple times, now).  Should I
 upgrade my Eclipse to something newer than  and try again?  I wasn't
 sure if CDT4 corresponded to some particular version of Eclipse or
 just identified a component - I'm not familiar with their versioning
 scheme.

 Cheers,
 Cliff


 Honestly, I'm not familiar with their versioning scheme either... I
 just know that Alex has been working hard at making Eclipse support
 work well with their current version. I don't use Eclipse much for C++
 work. In fact, I haven't even installed it on the laptop that I got
 back in July yet... Maybe I should give it a whirl again.

 Sorry,
 David
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Eclipse and CMake...

[Clifford Yapp]

I decided to take a stab at using the Eclipse Unix Makefile generator
with my project - on import, I get the following error:

Error processing changed links in project description file.

No file system is defined for scheme: virtual

I'm not really sure what this means or what issue it's indicating -
has anyone else seen this?

Thanks,
CY
--

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] TCL modules

[Clifford Yapp]

FWIW, BRL-CAD has its own FindTCL.cmake module which is quite different
from the current one, in case that is helpful/of interest:

http://brlcad.svn.sf.net/viewvc/brlcad/brlcad/trunk/misc/CMake/FindTCL.cmake?revision=45989view=markup

We'd eventually like to fold all of our updates to various modules back
into CMake, but for a number of them that essentially means volunteering to
maintain them :-).  That probably makes sense (we'll be doing it anyway,
after all) but so far we haven't had the time to get organized about
volunteering to do so and formally proposing our changes/updates.

Cheers,
CY

On Wed, Nov 16, 2011 at 6:28 PM, Joe Brandt vonb...@gmail.com wrote:

 I have a couple issues, that I'd like to help fix, with the current
 FindTCL.cmake, FindTclsh.cmake, FindWish.cmake, and FindTclStub.cmake that
 make them unusable for me.  The first is they do not always find the
 various components from the same Tcl installation on the system.  The
 second being that you cannot specify the version of Tcl that you want to
 find via the find_package command.  I have systems that have multiple
 installations of Tcl and have programs that require different versions of
 Tcl.

 I have modified the current Tcl modules to solve these two issues.  My
 changes at this point were geared around changing as little as possible
 from the originals to get these two items to work.  I really needed to just
 get it working for my environment, but after thinking about it I would
 rather try and get these changes/ideas pushed upstream rather than have to
 maintain my own Tcl modules.

 I do not see a maintainer for these modules.  I also saw there was
 discussions around the Tcl modules a year ago, but don't know if that
 panned out into anything.  If there is no maintainer I am certainly willing
 to maintain these if it means these changes, in some form or another, can
 get incorporated back upstream.

 Joe


 --

 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

--

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] Workflow of a collaborative project in Visual Studio+CMake

[Clifford Yapp]

That's what we do to.

It basically comes down to the inconvenience of having to do that with
Visual Studio being outweighed (considerably!) by the cross-platform
benefits of CMake.  (It does help that none of our developers use Windows
as their primary development platform, so it only comes up when we make
sure things are working on Windows...)

I really wish Microsoft would integrate support for CMake projects into
Visual Studio the way KDevelop has, although I suppose that's right up
there probability wise with hoping they'll integrate clang...

Cheers,
CY

On Sat, Nov 12, 2011 at 7:39 AM, David Cole david.c...@kitware.com wrote:

 For reference, the bug Mike refers to is this one:

  http://public.kitware.com/Bug/view.php?id=11258

 I always use the manual technique of shutting down VS, running CMake,
 and then re-opening VS. It's really not that bad, once you get used to
 it.


 David C.


 On Fri, Nov 11, 2011 at 5:48 PM, Michael Jackson
 mike.jack...@bluequartz.net wrote:
  It is worse and better.
 
  1: CMake will generate the VS projects and solutions every time it needs
 to run. DO NOT EDIT the generated VS projects and solutions. Add the
 requirements to the CMake files.
 
  2: If you are on VS2007/VS2008 and you do a git pull and then switch
 to VS and click build a cmake check is run FIRST. If anything is different
 the new solution and project files are generated and then the build
 continues. You will get a dialog asking if you want to reload all of the
 projects. Things are pretty nice.
 
  3: If you are on VS2010 there is now a long standing bug that seems to
 have no solution where you basically have to do the following:
   Close the VS solution
   git pull
   run cmake to regenerate the solution and projects
   Open the Solution and Compile.
 
  Yep. Sucks. Purchased VS2010 last year and have yet to use it because of
 that bug. If we (the cmake community**) were to actually figure out how to
 solve the problem then VS2010 would be as seamless as VS2008. Here is
 hoping for the future.
 
  ** I have kept track of the bug. Kitware and others have put a lot of
 time into trying to fix the bug. It just seams to be one of those elusive
 fixes that there just may not be a solution to.
  --
  Mike Jackson www.bluequartz.net
 
  On Nov 11, 2011, at 5:30 PM, David Doria wrote:
 
  I typically work in KDevelop which has CMake support, so if another
  developer pushes some new files and changes to the CMakeLists.txt of
  my project, I simply 'git pull' the project and then click Build and
  it knows exactly what to do - it runs CMake and then builds the
  project.
 
  However, when working with Visual Studio, do I have to 'git pull',
  then go open cmake-gui from the VS2010E terminal, re-configure and
  re-generate the project, then reimport the VS2010E project, then
  build? This seems horribly awkward. And the reverse appears to have
  the same problem - if working inside VS I add a file to the VS
  project, how do I 'export' this addition back to the git repo?
 
  Thanks,
 
  David
  --
 
  --
 
  Powered by www.kitware.com
 
  Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html
 
  Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ
 
  Follow this link to subscribe/unsubscribe:
  http://www.cmake.org/mailman/listinfo/cmake
 
 --

 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

--

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] CMake 2.8.6 available for download

[Clifford Yapp]

Hmm.  Part of the problem might be the generators most of the folks who
follow CMake closely tend to use - I'm a command line + vim linux weenie
myself, so I'm only going to be testing a subset of the generators.  I
imagine others are Windows only, etc.

One idea that comes to mind might be to put up a table when the RC process
starts - one column per generator, and the rows listing various open source
projects using CMake that are known to work with various generators.  If
it's expected in advance that a particular project won't build, just black
out that cell so people know not to try, but otherwise people could fill in
the matrix with RC1 or RC4 as they test particular generators and
projects and they succeed.  That would give folks a place to check what has
and has not been looked at - Urk! nobody's tried the Eclipse generator yet
for this RC or It's been 3 RC bumps since anybody checked Visual Studio
8.  And if particular generators go untested for a while, the call could be
put out on the email lists - somebody please try generator X with project Y
before release

Would that help?

Cheers,
CY

On Wed, Oct 5, 2011 at 11:36 AM, Bill Hoffman bill.hoff...@kitware.comwrote:

 On 10/5/2011 11:17 AM, Clinton Stimpson wrote:

  Peter, is that your problem also?  Can you edit your .cbp to remove lines
 like
 that?  Or copy it to a file with a .xml extension then open it in a
 program
 that can check the xml (e.g. firefox).



 So, what can we do to get people to try the RC's?   This issue was in RC 1
 which went out on 8/26.


  Patch by Campbell Barton: puts definitions into C::B project file


 This is really frustrating for the CMake team.  We really need the help of
 the users to make sure we have most of the big issues worked out with the
 releases.  This issue has been around for over a month in the RC releases
 and no one notices.  Then less than 24 hours after the official release we
 get the bug report...  :(


 -Bill
--
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Incorporating third party libraries

[Clifford Yapp]

On Tue, Oct 4, 2011 at 7:20 AM, Daniel Dekkers d.dekk...@cthrough.nlwrote:

 Hi,

 Would really appreciate your advice on this.

 We are planning to use and maybe distribute a library (let's call it
 OurLib) that depends on third-party libraries, namely Boost, Glut, OpenGL,
 FreeType, Bullet, PNG, ...


You could take a look at what BRL-CAD does for this situation:

http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk  (look for
adding the src/other subdirectory in CMakeLists.txt)
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/other/

macros used are defined in:

http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/misc/CMake/

From a high level, our approach is to try to detect suitable installations
of libraries on the system.  If we find them, use them.  If not, build our
local copy.  Currently our approach requires that each third-party library
also have a functional CMake build, but in principle you could try adding
support for other systems with ExternalProject_Add as well.  We found it
simpler to just write CMake logic where needed, since in theory we need all
of our third-party deps to build in every situation BRL-CAD itself needs to
build in - rather than worry about whether the third-party library has
enough build systems defined to cover all those cases (and figuring out how
to trigger which one when) it proved simpler to write the CMake logic for
the library.  Eventually, we'd like to have upstream adopt the CMake logic
and we could just use their source archives unaltered, but we're a ways away
from that and some projects are pretty heavily invested in Autotools.

Cheers,
CY
--
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] Does find_library check that a found library does in fact link?

[Clifford Yapp]

On Thu, Sep 29, 2011 at 2:59 AM, Michael Wild them...@gmail.com wrote:


 Just a few of my thoughts on this:

 - There are several ways to handle dead symlinks:
  1. Don't check, let the linker complain (status quo)
  2. Check whether the found library is a symlink, and if not valid,
 remove it silently from the list of candidates. Can be very
 surprising and will likely result in quite a few bug reports
 about CMake not finding a certain library that is clearly there.
  3. Like 2, but warn about the issue. Possibly very annoying.
 I don't know which option to prefer (perhaps somebody finds another one
 that is better?). IMHO bogus symlinks to shared libraries constitute a
 real problem of the library installation, so CMake shouldn't just paper
 over it by silently skipping the dead link, proceeding to the next
 candidate which rules out option 2 for me. Also, option 3 can be
 troublesome in automated setups where no user actually reads the CMake
 output.


What about warning by default, but accepting a flag to be quiet about it if
the user specifically requests those warnings not be issued?

The issue may surprise people, but if they don't understand what a bad
symlink implies they'll be just as surprised (and confused) when their build
fails but the file is clearly there.  Better to know up front before
putting the extra time into running the compile, IMHO...



 - Concerning link-tests:
  1. Only possible with shared libraries


That's OK - we can still do it for those libraries.


  2. Some shared libraries require special linker flags which CMake
 would require the user to provide. Not so much of an issue, since
 the user needs to provide them anyways.


Right.  In fact, a linker failure because of flags not supplied is
information the dev needs in any case, so I don't really see that as a
problem.


  3. Some shared libraries on *NIX systems are under-linked, i.e. they
 require additional libraries to be specified on the link line.
 Again, CMake can't know about those (as with static libraries).


It might be worth looking at AC_CHECK_LIB and how it handles such cases.
One approach might be to support a flag to find_library to specifically skip
link checking for that particular test, if the dev knows in advance it
doesn't link in isolation.


  4. Last, but not least, linking can be a very expensive operation.


That's the tradeoff - better results or more time.  Perhaps a global
CMAKE_CHECK_SHARED_LIBRARY_LINKING variable could turn testing on or off
globally?


 All of these factors make it very hard to come up with a set of tests
 that produces no false negatives (i.e. *never* discards a library that
 is actually valid). I don't care about false positives so much, because
 the linker will complain loudly about those, but if CMake refuses to
 find a valid library, that is a *real* problem.


What about having the shared library checking variable off by default, but
allowing a project to enable it if they want to deal with the issues of
making sure the tests are valid?  Once the fundamental mechanisms to enable
such tests are in place, the burden then shifts to the project to make sure
they're feeding in the right linker flags and such to correctly test a valid
library.  Some of them will want to pay both the configure time costs and
the developer time costs to have those checks in place.

Cheers,
CY
--

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] Does find_library check that a found library does in fact link?

[Clifford Yapp]

On Thu, Sep 29, 2011 at 3:22 AM, Hendrik Sattler p...@hendrik-sattler.dewrote:


 People tend to misunderstand the purpose of build systems like CMake and
 autotools. They try to make the detection bullet-proof and most likely fail.
 You can see that this is wrong by looking at those auto* setups that take
 ages to detect all possible header files and use an ifdef hell to handle
 that in the code, run lots of link and symbol-finding tests, and still fail
 on conditions that the author simple didn't consider or know.


The problem is in real world situations the software developer often has
virtually zero control over system administration issues on systems their
users are working with, and when your trying to be very portable you have to
spot and handle as many as possible of the wide variety of situations that
exist in the wild.  The decision on how much effort to put into working
around the existing issues (or at the very least detecting them before
putting all the time and resources into a full compilation) is determined by
the goals of the project.  Knowing that *all* situations can't be handled is
not a reason (at least for some projects) to avoid handling as much as they
can - they keep improving their handling when they run into new issues.


 I prefer option 1. It's not CMake's duty to detect or paper over messed-up
 systems. That's the administrator's job!


Except there are cases where a software developer has to do their best to
make their program work with the system as it is.  Spotting results that
aren't valid libraries in configuration is a time saver under those
conditions.

Couldn't CMake provide the means to let developers turn on testing
mechanisms (just disable them by default)?  A project could explicitly
enable CMAKE_CHECK_SHARED_LIBRARY_LINKING if they wanted to run the tests,
and projects who don't want it could ignore the issue and never know the
difference.  As long as CMake provided the core mechanism and hooks needed
to perform the test and feed in options, each project could decide what to
do from there.

Cheers,
CY
--

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] Does find_library check that a found library does in fact link?

[Clifford Yapp]

On Wed, Sep 28, 2011 at 2:47 AM, Michael Wild them...@gmail.com wrote:


 Only if your installation is broken ;-) If the symlink is broken, I
 consider this to be a user-error. Period. OTOH, CMake /could/ check
 whether the library is a symlink, and if it is, check that it is valid.


Oh, no question the installation is broken.  I'd just expect find_library to
do whatever minimal validation it can easily do and not return invalid cases
it can spot - checking for symlink and whether it's valid would catch one
general class of error, and perhaps a quick check to see if the file is a
binary or a text file would be another.   Not perfect, but such tests should
be relatively simple and would improve the utility of find_library.


 But how do you test whether a library is linkable?


Not sure - autoconf has some sort of test that works in at least some cases
in their AC_CHECK_LIB macro, but I'm not really clear on what it does.  Even
if such a test wouldn't catch all cases, mightn't it be useful to fail when
available tests do detect a problem?

Cheers,
CY
--

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] Does find_library check that a found library does in fact link?

[Clifford Yapp]

On Wed, Sep 28, 2011 at 8:52 PM, Michael Hertling mhertl...@online.dewrote:

What do you do on systems which have no idea of symbolic links, e.g.
 previous Windows versions? Adding more platform-specific code to the
 sources of the FIND_LIBRARY() function?


If the problem isn't solved (or readily solvable) on some platforms, we can
just fall back to doing what we do now in those cases... we don't have to
solve the problem on all possible platforms to improve the results on
platforms that can be supported.  The point wouldn't be to *guarantee* the
result of find_library is a valid working library (it doesn't do that now),
just improve the results by doing what can be done to avoid returning
results that can be tagged as non-working (since a build trying to use such
results is guaranteed to fail anyway.)  Does cmake know (or can it tell)
when it is cross compiling?  If so, it could decide how much to test and not
test in those cases.


 Furthermore, the kernels of
 *nix systems hardly distinguish between binary files and text files;
 usually, they know just files with the limited exception of being
 able to recognize the native executable formats and the #! shebang.
 The detection of the diverse file types is typically implemented
 in utility programs, notably the file(1) utility.


A linker test when possible (non-cross-compilation scenarios) with a
fallback testing option using file introspection would handle a lot of
situations, if I'm understanding correctly how this works.  To the best of
my knowledge and that of one of our other devs (he knows a lot more than me)
there aren't any platforms where actual library files (as opposed to linker
scripts) consist solely of character values 128.  Checking a found file for
at least one character over 128 would avoid at least a few failure cases -
empty files, plain text files, and dead links.  Such a check would be
reliable, consist, and would be useful in eliminating files we might find
that are not actually library files.

Such a test  of course wouldn't pass linker scripts like ubuntu's libc.so,
but such a script *would* pass the actual linker test and would never get to
file introspection. Actually if the script failed the linker test, then
there is a real problem that should be a failure case.  This would also be
helpful in spotting early on the hypothetical case of a linker being tested
that doesn't understand the .so linker script.


  But how do you test whether a library is linkable?


If not cross-compiling, wouldn't it be possible to have find_library try the
link as part of its test?  Even in the case where linking isn't viable,
falling back on the check on file contents would still be helpful.


 What do you do if the library found by FIND_LIBRARY() has a non-native
 binary format, e.g. for cross-compiling purposes? How do you select the
 right set of tools to check the library in question without the user's
 ado? IMO, FIND_LIBRARY()'s job is to find library files, and a general
 check whether these files are valid/usable/linkable and not dangling
 symlinks or whatever is beyond the scope of this function; ensuring
 that is rather the realm of system administration.


I guess the question revolves around the expectation of find_library being
different from find_file - as a user, my expectation would be that
find_library is doing something to distinguish libraries from files (when
that's technically workable, of course - clearly solving that problem in
general is hard.)  If something tricky like cross-compiling is going on then
the simpler testing behavior is in order, but couldn't CMake scrub the
results looking for library validity as much as possible?

Cheers,
CY
--

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] Does find_library check that a found library does in fact link?

[Clifford Yapp]

I've run into a situation where find_library is returning a symlink:

/usr/lib/libblah.so - libblah.so.1

 but libblah.so.1 does not actually exist (e.g. the symlink is bad).

Is there an option I can set to have find_library ensure that a found
library file is valid and links?

Cheers,
CY
--

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] Does find_library check that a found library does in fact link?

[Clifford Yapp]

On Wed, Sep 28, 2011 at 12:13 AM, Michael Wild them...@gmail.com wrote:

 On 09/28/2011 02:44 AM, Clifford Yapp wrote:
  I've run into a situation where find_library is returning a symlink:
 
  /usr/lib/libblah.so - libblah.so.1
 
   but libblah.so.1 does not actually exist (e.g. the symlink is bad).
 
  Is there an option I can set to have find_library ensure that a found
  library file is valid and links?
 
  Cheers,
  CY
 

 Yes, but you need to do it yourself, e.g. use the CheckFunctionExists
 module.

 Michael


Urm.  That's surprising, and not so hot in that it leads to false
positives in find_library reports.  Has anyone wrapped find_library with a
generic linking test successfully?

CY
--

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

[Clifford Yapp]

Looks like that's working.  Running ninja again, I'm seeing another issue:

BRL-CAD uses dependency assignment to make sure our build time delta
calculator is the last target to be built (and hence actually times the
build).  With ninja, it doesn't seem to be respecting this, but instead
tries to run the delta target immediately.  Do custom targets respect
dependency information?

Cheers,
CY


On Tue, Sep 13, 2011 at 9:33 AM, Peter Collingbourne pe...@pcc.me.ukwrote:


 Try using this branch of Ninja:

 https://github.com/pcc/Ninja/tree/restat

 The 'restat' branch is still under development, so this requirement
 will go away once 'restat' is merged into the main branch of Ninja.

 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

Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules

[Clifford Yapp]

On Sun, Sep 11, 2011 at 11:01 PM, Peter Collingbourne pe...@pcc.me.ukwrote:


  It looks like various custom commands aren't running (some tcl related
  stuff, docbook documentation generation) - are custom commands currently
  supported?

 Yes, custom commands and targets are supported.  There was a bug (which
 is now fixed) that caused custom commands not be built by default.  Now
 all targets except those marked EXCLUDE_FROM_ALL are built by default.


With latest pull from this weekend, I'm currently getting:

ninja cmTryCompileExec

  ninja: error: loading 'build.ninja': line 21, col 9: in 'rules.ninja':
line
  38, col 3: unexpected variable 'restat'

Cheers,
CY
___
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] Diff output from CMake?

[Clifford Yapp]

On Tue, Sep 13, 2011 at 1:58 PM, David Cole david.c...@kitware.com wrote:

 On Tue, Sep 13, 2011 at 1:39 PM, Alexander Neundorf
 a.neundorf-w...@gmx.net wrote:
  On Tuesday, September 13, 2011 05:07:00 AM Clifford Yapp wrote:
  I am trying to compare two large lists of file paths (about 14,000 lines
  each) to identify which entries in each list are missing from the other,
  and while I can get CMake to do it I must be doing it the wrong way
  because the results are hideously slow.
 
  I currently generate two files with the paths and then read them in as
  lists, using LIST() commands to peform STREQUAL tests.  I was hoping to
 
  How do you do that ?
  Do you iterate over one list using foreach() and then list(FIND) to check
  whether it exists in the other list ?


I tried a couple of ways, most of them variations on that theme (BUILD_FILES
and SVN_FILES are two manifest lists, and I need items from each list that
are not in the other list)

FOREACH(ITEM ${BUILD_FILES})
 LIST(FIND ${ITEM} SVN_FILES POS)
 IF(NOT POS STREQUAL -1)
LIST(REMOVE_ITEM SVN_FILES ${ITEM})
LIST(REMOVE_ITEM BUILD_FILES ${ITEM})
 ENDIF()
ENDFOREACH()

In essence, the idea is BUILD_FILES will end  up holding items unique to
BUILD_FILES and SVN_FILES will end up holding items unique to SVN_FILES,
which are the two pieces of information I'm after.


  Internally, every cmake variable is stored as a plain std::string.
  When using a list() command, this string is converted to a
  std::vectorstd::string, and then cmake operates on this vector.
  So if you do this 14000 times, each time a 14000 std::strings are
 created,
  which makes this O(n^2) I think.
 
  Maybe something like this works ?
 
  set(uniqueItems ${list1} ${list2})
  list(REMOVE_DUPLICATES uniqueItems )


I thought about REMOVE_DUPLICATES, but if I understand correctly wouldn't
that give me the union of the two lists?  I need everything not present in
both lists.


 I realize this same technique will not be very useful with files
 14,000 lines long... but thought I'd mention it so you could look at
 it and perhaps draw inspiration from it.


Basically I'm currently trying a variation on that, except I'm trying to get
a cross-platform comparing tool working that I can guarantee will be there -
I'm trying comm at the moment but I'm not sure comm's notions of what
consistute a sorted file and CMake's LIST(SORT are compatible when it comes
to things like .file and ~file.


 If you could pass along the code that you're using, we might be able
 to suggest a better way to achieve the same thing within the CMake
 language if that's absolutely necessary.


Currently (using comm) I'm doing this (replacing /. with /tmpdot in an
attempt to let comm handle the sorted output):

STRING(REGEX REPLACE /\\. /tmpdot BUILD_FILES ${BUILD_FILES})
STRING(REGEX REPLACE /\\. /tmpdot SVN_FILES ${SVN_FILES})
LIST(SORT BUILD_FILES)
LIST(SORT SVN_FILES)
STRING(REGEX REPLACE ; \n BUILD_FILES ${BUILD_FILES})
STRING(REGEX REPLACE ; \n SVN_FILES ${SVN_FILES})
FILE(WRITE @CMAKE_BINARY_DIR@/build_files_list.txt ${BUILD_FILES})
FILE(WRITE @CMAKE_BINARY_DIR@/svn_files_list.txt ${SVN_FILES})
STRING(REGEX REPLACE \n ; BUILD_FILES ${BUILD_FILES})
STRING(REGEX REPLACE \n ; SVN_FILES ${SVN_FILES})

EXECUTE_PROCESS(COMMAND @CMAKE_BINARY_DIR@/@BIN_DIR@/comm -3
@CMAKE_BINARY_DIR@/build_files_list.txt @CMAKE_BINARY_DIR@/svn_files_list.txt
OUTPUT_VARIABLE COMM_RAWOUT)
STRING(REGEX REPLACE \n ; COMM_OUT ${COMM_RAWOUT})
STRING(REGEX REPLACE /tmpdot /. COMM_OUT ${COMM_OUT})
STRING(REGEX REPLACE   COMM_OUT ${COMM_OUT})

FOREACH(ITEM ${COMM_OUT})
   LIST(FIND BUILD_FILES ${ITEM} INBUILD)
   LIST(FIND SVN_FILES ${ITEM} INSVN)
   IF(INBUILD STREQUAL -1 AND NOT INSVN STREQUAL -1)
  LIST(APPEND SVN_FILES_NOT_IN_BUILD ${ITEM})
  LIST(REMOVE_ITEM COMM_OUT ${ITEM})
   ENDIF(INBUILD STREQUAL -1 AND NOT INSVN STREQUAL -1)
   IF(INSVN STREQUAL -1 AND NOT INBUILD STREQUAL -1)
  LIST(APPEND BUILD_FILES_NOT_IN_SVN ${ITEM})
  LIST(REMOVE_ITEM COMM_OUT ${ITEM})
   ENDIF(INSVN STREQUAL -1 AND NOT INBUILD STREQUAL -1)
ENDFOREACH(ITEM ${COMM_OUT})

I was hoping that CMake's diff ability might indicate lurking in there was
the ability to get actual diff style output from a cmake -E command that
could be parsed (if CMake had sucked in openbsd's diff to implement its diff
abilities, for example) but if not it looks like performance considerations
will require ensuring some sort of cross-platform tool is available.  Would
it perhaps make sense to  have a cmake -E diff the same way there is a cmake
-E tar?

The broader context is implementing a make distcheck rule for BRL-CAD
along the lines of the one previously implemented in autotools - the idea is
to have subversion tell us what files are in the repository (svn info), have
the build system report what files it knows about (via some custom CMake
function/macro logic that we have working to record that) and crank that
information back

Re: [CMake] Diff output from CMake?

[Clifford Yapp]

On Tue, Sep 13, 2011 at 3:52 PM, Clifford Yapp cliffy...@gmail.com wrote:

 (if CMake had sucked in openbsd's diff to implement its diff abilities, for
 example)


Ah, nevermind - I see the key file still has the advertising clause BSD.
Scratch that.
___
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] Diff output from CMake?

[Clifford Yapp]

Eric -

Excellent!  That looks like it will do the trick.

Thank you!

CY

On Tue, Sep 13, 2011 at 4:53 PM, Eric Noulard eric.noul...@gmail.comwrote:


 If  I understand it well you want to compute symmetric difference.

 Assuming BUILD_FILES and SVN_FILES initially contains  the whole list of
 names.
 Then could you try:

 set(BUILD_FILES_UNIQUE ${BUILD_FILES})
 set(SVN_FILES_UNIQUE ${SVN_FILES})
 list(REMOVE_ITEM BUILD_FILES_UNIQUE ${SVN_FILES})
 list(REMOVE_ITEM SVN_FILES_UNIQUE ${BUILD_FILES})

 I don't know about the performance of this with huge list but after that
 BUILD_FILES_UNIQUE and SVN_FILES_UNIQUE should contains what you want. at
 least it work on my small (attached) example.


___
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] Diff output from CMake?

[Clifford Yapp]

I am trying to compare two large lists of file paths (about 14,000 lines
each) to identify which entries in each list are missing from the other, and
while I can get CMake to do it I must be doing it the wrong way because the
results are hideously slow.

I currently generate two files with the paths and then read them in as
lists, using LIST() commands to peform STREQUAL tests.  I was hoping to just
run a cmake -E command to get a diff output and parse my results in from
that, but as far as I can tell CMake's compare_files command doesn't provide
diff style output?  I can just call diff on platforms that have it, but
that's not reliable on Windows.  Does CMake have any ability to rapidly
provide the results of a diff between two text files or large lists of
strings?

Cheers, and thanks.

CY
___
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] Adding a custom line to CMake's makefiles?

[Clifford Yapp]

I can finally give a good concrete case where I might need to do this (or
need some other very clever solution).

I have created a distcheck command for BRL-CAD that has a lot of
responsibilities, including doing a complete configure and build of BRL-CAD
from a source archive expanded from a CPack tarball.  The distcheck rule
uses cmake to fire off the build (this is to try and be future proof against
using other tools than Make to do a distcheck) but I need to pass the
parallel build setting -j from Make down to the ${CMAKE_COMMAND} build
launched by the distcheck rule, and there doesn't seem to be any way to do
it.

This is the subset of the distcheck rule (somewhat edited for clarity):

   ADD_CUSTOM_TARGET(distcheck
  COMMAND ${CMAKE_COMMAND} -E echo Stage 1:  Create source tgz, tbz2
and zip archives from toplevel archive.
  COMMAND cpack --config
${CMAKE_CURRENT_BINARY_DIR}/CPackSourceConfig.cmake
  COMMAND ${CMAKE_COMMAND} -E echo Stage 2:  Expand tgz archive and
prepare to build from archive sources.
  COMMAND ${CMAKE_COMMAND} -E tar xvzf
${CPACK_SOURCE_PACKAGE_FILE_NAME}.tar.gz
  COMMAND ${CMAKE_COMMAND} -E make_directory
_${CPACK_SOURCE_PACKAGE_FILE_NAME}-build
  COMMAND ${CMAKE_COMMAND} -E make_directory
_${CPACK_SOURCE_PACKAGE_FILE_NAME}-install
  COMMAND ${CMAKE_COMMAND} -E chdir
_${CPACK_SOURCE_PACKAGE_FILE_NAME}-build ${CMAKE_COMMAND}
../${CPACK_SOURCE_PACKAGE_FILE_NAME}
-DCMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/_${CPACK_SOURCE_PACKAGE_FILE_NAME}-install
  COMMAND ${CMAKE_COMMAND} -E echo Stage 3:  Compile using source from
tgz archive.
  COMMAND ${CMAKE_COMMAND} --build
_${CPACK_SOURCE_PACKAGE_FILE_NAME}-build
  )

This can be successfully fired off by make distcheck, which is the desired
behavior.  However, the --build option doesn't respect (naturally) any -jN
options fed to make, since they aren't specified at CMake time when the
distcheck Makefile target is being generated.

Perversely enough, if I'm understanding the issue correctly I won't be able
to use the -jN value itself in any case, even if the Makefile can be taught
to do something smart:
http://old.nabble.com/MAKEFLAGS-var-does-not-show-%22-j%22-param-td15983337.html

The best idea I can come up with so far is for the CMake generated Makefile
to write out a variable containing some CPU related variable (e.g. make
CPUS=8 and write the value of $(CPUS) to CMakeFiles/make_cpu_flag or some
such) and then convert the distcheck commands above into a series of
EXECUTE_PROCESS lines in a rundistcheck.cmake file that is launched by the
distcheck rule with a ${CMAKE_COMMAND}.  In rundistcheck.cmake, I can check
for the presence of the make_cpu_flag file and if found add the -j parallel
flag to the --build line before running it.  That will mean a parallel
distcheck will have to use a different make syntax than the standard make
-j, but at least it would be something.  Unfortunately, that means I still
need the Makefile to let me know what was passed in up front, which means
tweaking the CMake generated output somehow (not really sure how yet).

Does anybody else have a mechanism for passing parallel build instructions
from make down to child ${CMAKE_COMMAND} --build instances?

Cheers,
CY


On Wed, Feb 2, 2011 at 4:32 PM, Michael Hertling mhertl...@online.dewrote:

 On 02/02/2011 03:34 PM, Clifford Yapp wrote:
  Is there any way to customize the Makefile output from CMake to
  include user-defined lines (say, something like #include
  Makefile.inc) at the end of each Make file?


 [snip]


 However, this approach is neither portable nor clean
 nor your-expectation-here, so I would ask Eric's questions, too. ;)

 Regards,

 Michael

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Deferred CPU count variable in CMake for Makefile generator?

[Clifford Yapp]

Per the customizing Makefile email, I'd like to ask if a mechanism exists or
could be implemented to allow CMakeLists.txt files to define commands that
pass a CPU count to subcommands - e.g. something that allows the generators
to take a syntax along the lines of:

ADD_CUSTOM_TARGET(subbuild
 COMMAND ${CMAKE_COMMAND} --build ${TARGET_DIR} -- -j${PARENT_CPUS}
)

and generate makefiles that will take make JOBS=3 subbuild and have cmake
in turn launch make -j3 in the target directory - in other words,
${PARENT_CPUS} would be a cue for the backend generator to add logic to pass
down parallel make settings to the subbuild command.  (Ideally -j3 could be
passed down, but it looks like make itself precludes that so some other
variable would have to be used at the top level.)

Any insight is appreciated - this one has got me pretty stumped as to the
right way to achieve this effect.

Thanks,
CY
___
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

[Clifford Yapp]

On Thu, Sep 8, 2011 at 2:54 PM, Peter Collingbourne pe...@pcc.me.uk wrote:


 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.


Gave it a whirl with BRL-CAD.  You caught me out fair and square on one
unspecified dependency that no other build system has caught, which is kinda
cool.

It seems to mostly build, but it's not recognizing that it's done (if I
re-run ninja, it redoes most of the build).  This could be something I'm not
doing right or expected ninja behavior at this stage, but I thought I'd
mention it.

It looks like various custom commands aren't running (some tcl related
stuff, docbook documentation generation) - are custom commands currently
supported?

For the core program building though, looks like it succeeded quite handily
- very nice!  Unfortunately, my time delta calculation was one of the
targets not built (or at least I don't see its output) so I'm not sure what
the time difference is yet ;-).

Cheers, and nice work!

CY
___
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] Deferred CPU count variable in CMake for Makefile generator?

[Clifford Yapp]

Looks like $(MAKE) will do it, at least in testing so far - awesome!  Thanks
David.

Cliff.

On Fri, Sep 9, 2011 at 11:15 AM, David Cole david.c...@kitware.com wrote:


  if(${CMAKE_GENERATOR} MATCHES Make AND
 (${cmake_generator} MATCHES Make OR NOT cmake_generator))
# The project uses the same Makefile generator.  Use recursive make.
set(cmd $(MAKE))

 Would that be a sufficient solution, or do you really need to pass
 flags down for some of your custom targets based on some of the makes
 that you have to deal with?

 Let us know.


 Thanks,
 David

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Adding a custom line to CMake's makefiles?

[Clifford Yapp]

Thanks Mike, good to know!  David actually solved my problem for me with the
generator based conditional and the $(MAKE) variable, but that's a nifty
workaround to have tucked away.

Cheers,
CY

On Fri, Sep 9, 2011 at 3:37 PM, Mike Wittman m...@headwave.com wrote:

 **
 If you are building on Linux, try
 MAKEFLAGS=j8 make distcheck

 I have successfully used the MAKEFLAGS environment variable to propagate
 parallel build invocations through scripts that invoke make with fixed
 options.

 -Mike


___
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

[Clifford Yapp]

On Thu, Sep 8, 2011 at 2:54 PM, Peter Collingbourne pe...@pcc.me.uk wrote:


 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).


Very cool!  What differences (if any) have you seen incompilation speed?

Cheers,
CY
___
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] Problem and proposed solution with cmake -E rename across devices

[Clifford Yapp]

Fair enough - I think I've worked around it now.  Sorry for the noise,
I missed the save volume restriction on rename originally.

Cheers,
CY

On Wed, Aug 31, 2011 at 11:49 AM, David Cole david.c...@kitware.com wrote:
 The cmake -E rename command is documented to work only when src and
 dst are on the same volume:

 If you run cmake -E with no other args, the rename command is documented as:

  rename oldname newname    - rename a file or directory (on one volume)

 I think doing a copy as a fallback is a reasonable thing, but I think
 it's on your side of the fence. CMake properly returns an error and
 tells you can't do that rename operation and then it should be uo to
 you to make a copy if that's what you want.

 Others may want to do something else if rename cannot be done. I don't
 think we should add code that says CMake will do a copy if rename
 fails...


 On Tue, Aug 30, 2011 at 3:21 PM, Clifford Yapp cliffy...@gmail.com wrote:
 We've run into an issue with cmake -E rename where the rename fails
 due to rename() throwing EXDEV when done between devices (different
 partitions, nfs to local, etc).  Erik Greenwald has investigated and
 has proposed a fix to allow cmake -E rename to succeed across devices
 - if possible we'd like to get this or some related fix included,
 since this is a real-world build environment situation for us:

 http://public.kitware.com/Bug/view.php?id=12433

 Cheers, and thanks!

 CY
 ___
 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


___
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] CMake --debug-trycompile option breaking tests

[Clifford Yapp]

On Wed, Aug 31, 2011 at 2:14 PM, Bill Hoffman bill.hoff...@kitware.com wrote:

 It would make a mess if you created a sub-dir per test.  There would be lots
 and lots of sub-dirs in some projects.

Personally I would expect that, and be OK with it, as long as the
directory names corresponded to the test in question - is the creation
of large numbers of dirs a performance concern?

Cheers,
CY
___
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] CMake --debug-trycompile option breaking tests

[Clifford Yapp]

We're seeing a problem when trying to run a cmake configuration using
both the TestBigEndian.cmake macro and the --debug-trycompile command
line option for CMake:

Sometimes we're getting

CMake Error at TestBigEndian.cmake:44 (MESSAGE):
  no suitable type found

Oddly, if I copy the CheckTypeSize macro to our local CMake directory
in the build, we then progress further to:

CMake Error at TestBigEndian.cmake:97 (MESSAGE):
  TEST_BIG_ENDIAN found no result!


I'm seeing a few other indications that whatever --debug-trycompile is
doing, it is messing with the results of various tests - has anybody
else seen this problem?  It would be very handy for us to be able to
preserve the sources from functionality testing to make sure they're
doing what we think they're doing, but so far it looks like trying to
save them with --debug-trycompile is breaking things.

Any help appreciated.  Thanks,

CY
___
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] Problem and proposed solution with cmake -E rename across devices

[Clifford Yapp]

We've run into an issue with cmake -E rename where the rename fails
due to rename() throwing EXDEV when done between devices (different
partitions, nfs to local, etc).  Erik Greenwald has investigated and
has proposed a fix to allow cmake -E rename to succeed across devices
- if possible we'd like to get this or some related fix included,
since this is a real-world build environment situation for us:

http://public.kitware.com/Bug/view.php?id=12433

Cheers, and thanks!

CY
___
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] CMake --debug-trycompile option breaking tests

[Clifford Yapp]

Hmm.  What about changing that option to make one sub-directory per
test instead of doing each one in the same temp directory?  Or if
try_compile doesn't support that, moving the generated files to a
subdirectory after the try_compile proper has run?  That would allow
normal cmake building while still preserving the files - it's rather
unexpected behavior to have it do what it does now.  Is there a reason
not to have one directory per test in a try_compile subdirectory?

Cheers,
CY
___
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] append command

[Clifford Yapp]

On Mon, Aug 15, 2011 at 7:59 AM, David Cole david.c...@kitware.com wrote:

 Again, our main concern here will be backward compatibility, not difficulty 
 of encoding semi-colons...
 There are tons of real-world projects that already use all of these variables 
 and properties being discussed with their current semantics.

nods Understood and agreed.  I had in the back of my mind a
CMAKE_POLICY CMP00## rule of some sort but that would be quite
disruptive...  the other approach that comes to mind would be to have
CMAKE_* variables accept a property of their own telling CMake whether
to treat them as space-separated strings or semi-colon separated lists
with defaults set to the current behavior (although would have the
advantage of not changing behaviors unless the build logic
specifically asked for a different behavior.)

Cheers,
CY
___
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