[CMake] ExternalProject, BundleUtilities, CPack, and RPath management
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
[CMake] Getting at the final compiler/linker string for a given library
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] Problem with CMake 3.3.0-rc3
On Sat, Jul 11, 2015 at 5:07 AM, Stephen Kelly 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] Is there any way to set a build-type specific install path for multiconfig tools?
On Mon, Jul 13, 2015 at 12:05 PM, David Cole 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
[CMake] Is there any way to set a build-type specific install path for multiconfig tools?
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- for release builds and
/parent_dirs/dev- 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] Problem with CMake 3.3.0-rc3
On Mon, Jul 6, 2015 at 11:53 AM, Brad King 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
[CMake] Problem with CMake 3.3.0-rc3
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
That got it - thank you!
For future reference, anyone wanting to run ctest from a CMake target
in msvc needs to have the -C $ option specified:
add_custom_target(check COMMAND ${CMAKE_CTEST_COMMAND} -C $ -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
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
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.
On Thu, Feb 6, 2014 at 1:14 AM, PCMan 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
S
Re: [CMake] AStyle or similar code beautifier
On Fri, Jan 31, 2014 at 2:01 AM, Rob McDonald 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...
On Tue, Oct 15, 2013 at 10:16 AM, Malfettone, Kris 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
On Thu, Sep 26, 2013 at 4:39 PM, Jacky Alciné 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
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
On Mon, Aug 26, 2013 at 9:49 PM, Clifford Yapp 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
On Mon, Aug 26, 2013 at 12:32 PM, Robert Maynard 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
On Mon, Aug 26, 2013 at 9:28 PM, Clifford Yapp 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
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...
http://public.kitware.com/Bug/view.php?id=11575 On Wed, Nov 7, 2012 at 2:40 PM, David Cole 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
On Sun, Nov 4, 2012 at 4:45 AM, lzprgmr 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?
On Mon, Sep 3, 2012 at 3:59 PM, Rui Maciel 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
On Tue, Aug 21, 2012 at 2:38 PM, Randolph M. Fritz 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
On Fri, Aug 17, 2012 at 8:52 PM, Randolph M. Fritz wrote: > Meantime, what would it take to get some Apple-specific support added to > FindX11.cmake? If I did a version with some changes, would Kitware be > interested in picking it up? It seems to me that I'm not the only one > having problems. Not sure who's maintaining FindX11.cmake at Kitware - they may be looking for a maintainer. If your changes can be under the same license as CMake itself you could post patches - I suspect a number of people besides BRL-CAD customize FindX11.cmake and would be interested. 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
On Fri, Aug 17, 2012 at 3:36 PM, Randolph M. Fritz 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...
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!
On Fri, Jun 22, 2012 at 3:34 PM, David Cole 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
On Thu, Jun 7, 2012 at 12:27 PM, Bill Hoffman 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
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?
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?
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?
On Tue, Apr 17, 2012 at 4:59 PM, David Cole 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
On Thu, Apr 12, 2012 at 8:47 AM, hendrik 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] Cross-compilation on Linux targeting Windows
Having done a little investigation into cross-compilation (after blowing away my Windows partition more or less unintentionally) it looks like our build is Not a Good Candidate - we do a truckload of introspection, as well as using custom commands and targets based off of binaries we build during compilation. While this problem (executables generated for a different platform during build testing) is of course not solvable in the general case, on Linux there is actually a glimmer of hope that binaries built for Windows *could* be run as part of the build process - i.e. using Wine when running each binary that is an output of the current build process. Has anyone ever looked into this? Would it be possible to have TRY_RUN, execute_process and add_custom_command (plus any others I missed) use wine "under the hood" to execute WIN32 compiled build targets? 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] CMake 2.8.8-rc1, Ninja generator, and clean target
On Mon, Apr 2, 2012 at 8:21 AM, Nicolas Desprès wrote: > Hi, > > It looks like an issue in the generator. The symlink is created as a > side effect of a rule and not mentioned in the output files. That's > why it does not get removed. I have pushed a patch on my CMake's > github clone that should fix the issue without breaking cmake's test > suite. My machine is out of commission at the moment, but I'll give it a try as soon as I can. It would be nice to have this fix in 2.8.8, but I notice rc2 doesn't seem to have it? > Although it seems to works for your case, I'm not sure it is > the right way to fix this issue. I think you should open a ticket on > the bug tracker. > I'll try to once my machine is back up... one other thing I notice with ninja -t clean - it doesn't seem to be removing files added to the ADDITIONAL_MAKE_CLEAN_FILES directory property. Is this variable make specific, and if so is there a generic variable I can use instead to tell ALL build tools to clean the file(s) in question? 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] CMake 2.8.8-rc1, Ninja generator, and clean target
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?
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] CMake configuration times with Microsoft Visual C++
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
[CMake] Running executables - local targets vs. system binaries
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
Re: [CMake] Ninja + CMake on a dashboard?
> > > We *could*, if popular demand is high enough, merge it in anyway and > > call it "experimental" to start with, or we could get it right all > the > > way before we merge to 'master' and put it out in an official CMake > > release. > What would be involved with fixing the remaining OSX issues? Do we need CMake changes, ninja changes, both...? Obviously full support would be preferable, unless it won't be happening for quite some time - I would agree that if non-GUI apps won't work on OSX it would be better to limit an activation of Ninja to those platforms where it will Work As Expected. 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] simplest possible NSIS package
I'd be up for testing CMake/WiX integration - Windows installers are an ongoing need for BRL-CAD, and WiX looks like an interesting tool. Cheers, Cliff On Fri, Feb 24, 2012 at 11:18 AM, Eric Noulard wrote: > > WiX has been proposed (including a patch) > http://public.kitware.com/Bug/view.php?id=11575 > I think the bug has been "backloged" because of lack of manpower to work > on it > and the lack of test in the proposed patch. > > May be you can try to resume this work? > I may help for understanding CPack internals, but I may not be of great > help for testing since I'm not using Windows very often. > > -- > Erk > Membre de l'April - « promouvoir et défendre le logiciel libre » - > http://www.april.org > -- > -- 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
On Thu, Feb 2, 2012 at 11:59 AM, Alexander Neundorf 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
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 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
On Wed, Feb 1, 2012 at 2:35 AM, Rolf Eike Beer 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
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
Re: [CMake] RUNTIME_OUTPUT_DIRECTORY and Visual Studio Express
On Fri, Jan 27, 2012 at 3:17 PM, Clifford Yapp wrote: Ah hah! That was it - we're not just overriding CMAKE_RUNTIME_OUTPUT_DIRECTORY, but CMAKE_RUNTIME_OUTPUT_DIRECTORY_ variables too. Consequently, we need to locally define not just RUNTIME_OUTPUT_DIRECTORY but also RUNTIME_OUTPUT_DIRECTORY_ target properties. Doing so got the desired result: Generating Code... Creating library C:/Users/User/brlcad/brlcad-build/lib/regex.lib and object C:/Users/User/brlcad/brlcad-build/lib/regex.exp regex.vcxproj -> C:\Users\User\brlcad\brlcad-build\lib\regex.dll Sorry for the noise - thanks! 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] RUNTIME_OUTPUT_DIRECTORY and Visual Studio Express
Looks like that was it - removing all setting of CMAKE_RUNTIME_OUTPUT_DIRECTORY ended up putting it in: C:\Users\User\brlcad\brlcad-build\lib\Debug\regex.dll Not sure where the Debug subdirectory came from though... Is there any way to make a per-target RUNTIME_OUTPUT_DIRECTORY setting override the various CMAKE_RUNTIME_OUTPUT_DIRECTORY* variables? It's rather surprising that the specifically-set local target option isn't overriding the globals. Cheers, CY On Fri, Jan 27, 2012 at 3:08 PM, Clifford Yapp wrote: > > 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 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] RUNTIME_OUTPUT_DIRECTORY and Visual Studio Express
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 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
[CMake] RUNTIME_OUTPUT_DIRECTORY and Visual Studio Express
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] CMake + Ninja
Confirmed - working now on Mac building BRL-CAD - thanks! Cliff On Sat, Jan 14, 2012 at 3:25 PM, Peter Collingbourne 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
On Tue, Jan 10, 2012 at 12:03 AM, Peter Collingbourne 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
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 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
Re: [CMake] Some issues with visual studio
On Sun, Jan 8, 2012 at 4:59 PM, Renato Utsch 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
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 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 -- 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
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 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
[CMake] CMake + Ninja
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] Eclipse and CMake...
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 wrote: > On Fri, Dec 9, 2011 at 9:39 AM, Clifford Yapp wrote: >> On Fri, Dec 9, 2011 at 6:41 AM, David Cole 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...
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
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=45989&view=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 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
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 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 > 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 > > > > 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
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 wrote: > 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
On Tue, Oct 4, 2011 at 7:20 AM, Daniel Dekkers wrote: > 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?
On Thu, Sep 29, 2011 at 3:22 AM, Hendrik Sattler wrote: > 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?
On Thu, Sep 29, 2011 at 2:59 AM, Michael Wild 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?
On Wed, Sep 28, 2011 at 8:52 PM, Michael Hertling wrote: 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
Re: [CMake] Does find_library check that a found library does in fact link?
On Wed, Sep 28, 2011 at 2:47 AM, Michael Wild 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?
On Wed, Sep 28, 2011 at 12:13 AM, Michael Wild 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
[CMake] Does find_library check that a found library does in fact link?
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] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
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 wrote: > > 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] Diff output from CMake?
Eric -
Excellent! That looks like it will do the trick.
Thank you!
CY
On Tue, Sep 13, 2011 at 4:53 PM, Eric Noulard wrote:
>
> 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
Re: [CMake] Diff output from CMake?
On Tue, Sep 13, 2011 at 3:52 PM, Clifford Yapp 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?
On Tue, Sep 13, 2011 at 1:58 PM, David Cole wrote:
> On Tue, Sep 13, 2011 at 1:39 PM, Alexander Neundorf
> 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::vector, 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
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Sun, Sep 11, 2011 at 11:01 PM, Peter Collingbourne wrote: > > > 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
[CMake] Diff output from CMake?
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?
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 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] Deferred CPU count variable in CMake for Makefile generator?
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 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] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Thu, Sep 8, 2011 at 2:54 PM, Peter Collingbourne 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
[CMake] Deferred CPU count variable in CMake for Makefile generator?
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] Adding a custom line to CMake's makefiles?
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 wrote:
> 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 , 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
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Thu, Sep 8, 2011 at 2:54 PM, Peter Collingbourne 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] CMake --debug-trycompile option breaking tests
On Wed, Aug 31, 2011 at 2:14 PM, Bill Hoffman 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
Re: [CMake] Problem and proposed solution with cmake -E rename across devices
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 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 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
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
[CMake] Problem and proposed solution with cmake -E rename across devices
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
[CMake] CMake --debug-trycompile option breaking tests
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
Re: [CMake] append command
On Mon, Aug 15, 2011 at 7:59 AM, David Cole 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. 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
Re: [CMake] append command
On Sat, Aug 13, 2011 at 5:14 AM, Glenn Coombs wrote: > I haven't seen any discussion yet of my 2nd alternative of getting cmake to > automatically convert lists to space separated strings for certain variables > like CMAKE_EXE_LINKER_FLAGS_RELEASE. If cmake did this then there would be > less need for the concat version of set() as one could just use the existing > list(APPEND) functionality. Is this a realistic possibility, or are there > implementation issues with this suggestion ? This surprised me as well - if you want to assemble a list of flags "on the fly" (I needed to assemble lists of lists of flags - we pass a lot of them) you have to take some care to either do the set trick correctly or convert the list to a string at the "end" (if you can be sure of where that is). Do I understand correctly that the main concern is the ability to pass args with ";' characters in these cases? Then the question becomes whether quoting ";" characters as needed in user-specified options is tricker than navigating the current behavior. To be honest, I can see where trying to specify an argument with a quoted ";" character from the command line would get a bit messy (in a "ok, how do I quote this from this enviornment" sort of way) - how common are ";" characters as components of variable values? 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] Generating C++ code from Idl language with variable number of files as output
On Mon, Jul 18, 2011 at 8:42 AM, Valentin-Daniel Boca
wrote:
> gen_code xxx.idl -> xxxIdl.h, xxxIdl.cc, xWrappers.h and xxxWData.h
>
> So for every "keyword struct" there is one more file generated. The first
> three files are always the same.
>
> Given this, I can't know the list of output files to put it in the list of
> add_custom_command output section.
>
> I need somehow to be able to tell to add_custom_command that the content of
> OUTPUT files should be somehow taken from the result of running the COMMAND
> (which I know it's impossible).
What about this: a two stage process, where the first stage runs a
stand-alone CMake script that runs all of the idl commands ahead of
time, outputting the contents into a custom directory. For each idl
file, do the following steps in the stand-alone script:
1) run the idl gen_code on the file
2) use CMakes glob routines to capture what files were generated in
the temporary directory as a result of that command
3) write the results of that glob to an xxx_idl.out file
4) clear out the generated idl files in the temporary directory.
Once you have all the idl.out files, in the main CMake logic you can
write a macro for doing the add_custom_command routine that
incorporates reading in the xxx_idl.out file contents into a
variable/list. You might need to generate per-idl-file .cmake files
to run, based on a template and using configure_file
Look into commands like:
execute_process(COMMAND ${CMAKE_COMMAND} ...)
FILE(GLOB IDL_OUTFILES tmpdir/*)
FILE(WRITE ${xxx}_idl.out ${IDL_OUTFILES}
Once you have your xxx_idl.out files, you can incorporate them into a
wrapper macro in the main file and use that macro to add your idl
files:
MACRO(add_idl xxx)
FILE(READ ${xxx}_idl.out IDL_OUTFILES)
add_custom_command(
OUTPUT ${IDL_OUTFILES}
COMMAND gen_code xxx.idl
DEPENDS ${xxx}_idl.out ${xxx}.idl
)
add_custom_target(${xxx}_idl ALL DEPENDS ${IDL_OUTFILES})
ENDMACRO(add_idl)
This achieves the effect of per-file custom OUTPUT files in principle.
This is a more or less "off the cuff" response, so it may not be
quite the approach you will need, but it's how I would start
experimenting in such a case. I should note that the drawback is any
change to the idl files will require re-running CMake, not just
running make - I'm not sure if there is a way to enforce that that
actually happens when an idl file changes but I'm also not sure if
there's any way around it, since you're essentially faking dynamic
OUTPUT lists in custom commands and that actually does require
re-generation of the Makefiles (or whatever) whenever the idl contents
change (as far as I know).
CMake devs, is there any way to tell CMake that it needs to re-run
itself when a user-specified file changes? (e.g. trigger the same
behavior for idl files that gets triggered when a CMakeLists.txt file
is updated?)
Hope that helps, and good luck.
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] test linker flags?
Is there a way to test flags supplied to the linker (CMAKE_SHARED_LINKER_FLAGS) in the same way we can test compiler flags with CHECK_C_COMPILER_FLAG? I'd like to check if -Wl,--no-undefined works or not before using it. 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] Wiki: version compatibility matrix
On Tue, Jul 12, 2011 at 4:58 PM, Alexander Neundorf wrote: > now cmake 2.8.5 has been released, could you please if you find the time > update that page ? > It's really useful :-) Second that motion - it just helped me figure out another 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] umask settings?
I'm noticing that a make install done with CMake is not respecting umask settings on Linux - is there some setting I need to tweak to get it to do so? 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] Forcing CMake to never search install path
Michael,
At first glance those would be what I need (although it is not clear
if I need to specify bin/lib/include for CMAKE_SYSTEM_IGNORE_PATH as
well as CMAKE_IGNORE_PATH.) I have tested both out, and unfortunately
they do not seem to exclude the CMAKE_INSTALL_PREFIX path when I
supply it - I still get find results even after appending the install
path to CMAKE_SYSTEM_IGNORE_PATH. I also tried
get_filename_component(PATH_NORMALIZED ${CMAKE_INSTALL_PREFIX}/lib ABSOLUTE)
to make it easier for Find to ignore the path, but that didn't seem to
help. I've tried forcing the results into the Cache as well. Is
there something else I need to do?
Thanks,
CY
On Thu, May 19, 2011 at 7:47 AM, Michael Hertling wrote:
>
> Have you already tried the CMAKE_[SYSTEM_]IGNORE_PATH variables? At
> the first glance, they provide exactly the functionality you need.
___
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] Forcing CMake to never search install path
On Mon, May 16, 2011 at 4:00 PM, Alexander Neundorf wrote: > So you basically want an opposite to HINTS and PATHS, like e.g. EXCLUDE ? > Doesn't sound too bad. Yes, that would work - ideally though I'd like to EXCLUDE the path from ALL finds by defining it once in the CMakeLists.txt file, instead of per-find-command. > If you know where your stuff will be, you could also use NO_DEFAULT_PATH and > the add all the valid options for your case yourself. Unfortunately, it's not that restricted. I do need to search "normally", but I need to do so WITHOUT returning the stale results in an old install directory. 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] Forcing CMake to never search install path
I could probably "work around" the problem by making my own custom Find* modules that checked the paths of results against the CMAKE_INSTALL_PREFIX path, or (eek) maybe even do find_library/_find_library wrapping to filter results globally, but that seems like an awful hack - wouldn't it make more sense to just add a switch to enable/disable the use of those paths in the FIND systems? Is there some policy on this from the Kitware guys? On a related note, is there any debugging option that will let me see what paths a FIND_LIBRARY command is searching in? I'm willing to expand my "strip the install path out of the internal variables" approach (which does (mostly) work, despite altering variables which are apparently supposed to be internal) if I can just figure out what's causing Windows in particular to search more aggressively... 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] Forcing CMake to never search install path
I've been struggling to find a way to prevent CMake from using CMAKE_INSTALL_PREFIX in any of its FIND_* routines. Generally speaking, stripping it out of CMAKE_SYSTEM_PREFIX_PATH seems to work, but we're still getting situations on Windows where it is finding old libraries from previous program installs. I've tried ensuring all of the CMAKE_SYSTEM_*_PATH variables are stripped, but that doesn't seem to make a difference. Is there a mechanism I can use to specify to CMake to NEVER search in a given path, excluding it from all FIND_* routine searches? It is very typical in our development process to have older builds installed and be building newer versions at the same time, so we really need a good solid way to make sure previously built libraries aren't picked up by FIND routines. Thanks for any assistance, 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] Generating archives and binaries with different PREFIX settings using CPack
Eric, Thanks - that looks like it will do the trick, testing now. Is there a bug report somewhere proposing using CMake-level per-generator variables to control these things? 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] Generating archives and binaries with different PREFIX settings using CPack
I'm trying to generate both source tarballs and binary packages using CPack, and I'm at something of a loss as to how to achieve the following: I want the binaries (RPM, DEB, etc.) to respect the CMAKE_INSTALL_PREFIX. I want the source tarballs to expand into their directory like a standard tarball, without any prefix directories. As far as I can tell, both source and binary packaging structure is governed by CPACK_PACKAGING_INSTALL_PREFIX - am I missing something that will let me specify one setting for binary archives and another for source archives? (Ideal would be per-generator settings, so I could generate a binary tar.gz bundle that would expand locally as well, but the really important one is source tarballs.) 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: a small build system closest in spirit to Make
We could start with the CMakeLists.txt file :-).
It doesn't want to do an out of source dir build either, have to see why...
On Fri, Feb 11, 2011 at 9:58 AM, David Cole wrote:
>
> I tried compiling it on Windows yesterday with just the following
> CMakeLists.txt file, and there were a bunch of compile errors. It shouldn't
> be too hard to make it work on Windows, though, if Mr. Martin will accept
> some patches for it... :-)
>
>
> cmake_minimum_required(VERSION 2.8)
> project(ninja)
>
> set(ninja_lib_sources
> src/build.cc
> src/build_log.cc
> src/eval_env.cc
> src/graph.cc
> src/parsers.cc
> src/subprocess.cc
> src/util.cc
> src/ninja_jumble.cc
> )
> add_library(ninjaLib STATIC ${ninja_lib_sources})
>
> add_executable(ninja src/ninja.cc)
> target_link_libraries(ninja ninjaLib)
>
>
> Cheers,
> 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
Re: [CMake] add_custom_target and output file dependencies
Yep, that looks like it will work - thanks!
CY
On Thu, Feb 10, 2011 at 11:21 AM, David Cole wrote:
> Sorry. Correction here... Make that:
>
> COMMAND ${CMAKE_COMMAND} -E touch
> ${CMAKE_CURRENT_BINARY_DIR}/${targetprefix}.sentinel
>
> (The "touch" is the rather important part of that command line)
___
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: a small build system closest in spirit to Make
That does indeed look interesting. If you can get a generator working I'd be very interested to see what its performance numbers look like and would be glad to test it out - faster building would be great :-). How much work is involved to make a new generator? Cheers, CY 2011/2/10 Nicolas Desprès : > He speaks about it in its blog here: > > http://neugierig.org/software/chromium/notes/2011/02/ninja.html > > You can find the source code here: > > https://github.com/martine/ninja > > and the manual here: > > http://martine.github.com/ninja/manual.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
