[cmake-developers] A type for static plugins?
Hello, In CMake, the MODULE_LIBRARY type is quite like a shared library which is not linked to. In Qt, there is a concept of a static plugin. This is essentially just a static library, but there is buildsystem awareness of the difference. When building a static library using Qt, the QT_STATICPLUGIN preprocessor macro must be defined: http://doc-snapshot.qt-project.org/qt5-stable/qtcore/plugins-howto.html#static-plugins This affects the compilation of moc generated files (In Qt 5 plugin information is generated by moc). If CMake had a STATIC_MODULE library type, I would be able to add: $$STREQUAL:$TARGET_PROPERTY:TYPE,STATIC_MODULE:QT_STATICPLUGIN to the INTERFACE_COMPILE_DEFINITIONS of Qt5::Core, and all consumers wishing to create a static library would use add_library(mystatic_library STATIC_MODULE foo.cpp) target_link_libraries(mystatic_library Qt5::Core) and automatically get the correct definition set. Any comments on adding a new STATIC_MODULE type to CMake? Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A type for static plugins?
On 09/20/2013 08:14 AM, Stephen Kelly wrote: Any comments on adding a new STATIC_MODULE type to CMake? Other than the TYPE being a different name, how would CMake treat this target type differently? -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A type for static plugins?
Brad King wrote: On 09/20/2013 08:14 AM, Stephen Kelly wrote: Any comments on adding a new STATIC_MODULE type to CMake? Other than the TYPE being a different name, how would CMake treat this target type differently? In the case of Qt, I don't see much else relevantly different between static libraries and static plugins. So the answer is, 'probably nothing'. The other thing Qt does with static plugins is generate a file with Q_IMPORT_PLUGIN calls. That part relates to the INTERFACE_SOURCES concept: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7082 I could imagine it being useful for any project which can build shared or static and has a plugin interface with a similar need for a PP define though. Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A type for static plugins?
On 09/20/2013 08:54 AM, Stephen Kelly wrote: Brad King wrote: Other than the TYPE being a different name, how would CMake treat this target type differently? So the answer is, 'probably nothing'. In that case I do not think we can justify a special CMake target type for it. All the special cases for STATIC_LIBRARY targets will have to be updated to also account for the new type with no difference in logic. Can't this work with a simple explicit property? Just put $$BOOL:$TARGET_PROPERTY:QT_STATICPLUGIN:QT_STATICPLUGIN in Qt5::Core's INTERFACE_COMPILE_DEFINITIONS and then add_library(mystatic_library STATIC foo.cpp) set_property(TARGET mystatic_library PROPERTY QT_STATICPLUGIN 1) target_link_libraries(mystatic_library Qt5::Core) -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A type for static plugins?
On 09/20/2013 09:10 AM, Stephen Kelly wrote: Brad King wrote: add_library(mystatic_library STATIC foo.cpp) set_property(TARGET mystatic_library PROPERTY QT_STATICPLUGIN 1) target_link_libraries(mystatic_library Qt5::Core) Yes, but I don't think that's better than add_library(mystatic_library STATIC foo.cpp) target_compile_definitions(mystatic_library PRIVATE QT_STATICPLUGIN) target_link_libraries(mystatic_library Qt5::Core) If Qt adds some other usage requirement for static modules in the future then the declarative property is better than a user spelling out the specific compile definitions requirement. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A type for static plugins?
Brad King wrote: So the answer is, 'probably nothing'. In that case I do not think we can justify a special CMake target type for it. All the special cases for STATIC_LIBRARY targets will have to be updated to also account for the new type with no difference in logic. Another alternative would be for add_library(myplugin STATIC_MODULE foo.cpp) be exactly equivalent to add_library(myplugin STATIC foo.cpp) set_property(TARGET myplugin PROPERTY STATICPLUGIN 1) and document the STATICPLUGIN target property. Then I can use that in the Qt5::Core INTERFACE_COMPILE_DEFINITIONS, and no handling of static libraries in CMake would need to be extended for the new type. The cmAddLibraryCommand would set the property. Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A type for static plugins?
On 09/20/2013 09:59 AM, Stephen Kelly wrote: Another alternative would be for add_library(myplugin STATIC_MODULE foo.cpp) be exactly equivalent to add_library(myplugin STATIC foo.cpp) set_property(TARGET myplugin PROPERTY STATICPLUGIN 1) IMO that's too special-purpose. However, since it is so common to add a library and then set properties on it, perhaps there should be a syntax in add_library and add_executable to inline property settings. For example, we could add a keyword signature to declare SOURCES and PROPERTIES in one call: add_library(myplugin STATIC SOURCES foo.cpp PROPERTIES QT_STATICPLUGIN 1 ) -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CPack BAR package generator
2013/9/20 Stephen Kelly steve...@gmail.com:
Stephen Kelly steveire@... writes:
https://gitorious.org/~steveire/cmake/steveires-cmake
It is the start of a CPack generator for BlackBerry BAR packages, required
for deployment to those devices. I haven't worked much with CPack before, so
I'd appreciate some feedback even at this early point.
Eric, and response to this?
I'm looking at it right now.
1) You lack at least a CPackBAR.cmake in which you should put
the documentation for each CPACK_BAR_xx specific variable usage.
Have a look at CPackWIX.cmake or CPackRPM.cmake etc
You can check if it's working with:
cpack --help-variable CPACK_BAR_xx
2) You shouldn't do
add_custom_target(bbpackage
COMMAND ${CMAKE_CPACK_COMMAND} -G BAR
)
but
set(CPACK_GENERATOR BAR)
then make package or cpack with no args in the build tree should
biuld a BAR package.
see cpack --help-variable CPACK_GENERATOR
3) Depending on how much flexibility you want you may chose to do
some of the work
inside a CMake script like CPackRPM.cmake does or do all you want to do
inside the C++ code (cmCPackBARGenerator::PackageFiles) like
NSIS or DEB does.
Offering some trap in your CPackBAR.cmake may ease
4) You should obviously have some tests for it. (CMakeSource/Tests/CPack*)
4.1) ensure that CPackTestAllGenerators/ works
and may be CPackComponents/
CPackComponentsForAll/ as well.
4.2) develop BAR specific test like for CPackWiXGenerator/
I do not have the time to do a test build yet, but I'll try.
Thanks,
Steve.
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--
Erk
L'élection n'est pas la démocratie -- http://www.le-message.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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Please review CXXFeatures.cmake
On 09/20/2013 03:42 PM, Rolf Eike Beer wrote: Having the interface in a full-featured C++11 way is step 2 or 3 on the way. I would like to solve the first step first. The problem is that the solution to the later steps cannot be built directly on top of your proposal for the first step. Steve's proposal elsewhere in this thread will cover everything needed. I don't think it is actually very complicated either. You two just need to shuffle the logic you (Eike) have already constructed to compute available features into the right places. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Please review CXXFeatures.cmake
Am Donnerstag, 15. August 2013, 14:37:42 schrieb Stephen Kelly: Stephen Kelly wrote: Stephen Kelly wrote: I still think you should revisit my review mail on point 2 too. Something that becomes possible when thinking about the above and target properties is interface requirements. I've implemented a prototype which has better API than your module. In my concept: * Applying the -std=c++11 flag is the responsibility of CMake, not the user. * CMake determines the -std= flag to use (GCC 4.9 has -std=c++1y by now). It won't add '-std=c++11 -std=c++14', but just '-std=c++14' * Required compiler features are scoped to targets. Can I get this globally? So I define once that all targets in my project get this? [Reading further] I assume I can set a global or directory property that will then propagate to all targets below. * Target properties are set, exported and transitively evaluated track the compiler features required. * Compiler requirements can be optional, in which case -D defines are generated in the (PUBLIC) COMPILE_DEFINITIONS * The -D defines are for scoping or replacement, depending on what the feature calls for. * Required compiler features are listed in the INTERFACE of exported targets. CMake evaluates whether the compiler is capable of using the IMPORTED targets it is supposed to use transitively, in a similar way to the POSITION_INDEPENDENT_CODE feature. * A new command target_compiler_feature is introduced with two signatures: target_compiler_feature(target PUBLIC|PRIVATE REQUIRED feature1 [feature2 ...]) target_compiler_feature(target PUBLIC|PRIVATE OPTIONAL feature DEFINE define_name) * Another non-target-scoped command could be introduced, similar to target_compile_options - add_compile_options. This is better in many noteworthy ways to the cxx11 topic in the stage. It solves an entirely different problem. My topic makes CMake detect which C++ features the compiler supports. Your topic is about how to get this to the targets and propagate it to the targets that use them. Eike signature.asc Description: This is a digitally signed message part. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Please review CXXFeatures.cmake
On 09/20/2013 04:32 PM, Rolf Eike Beer wrote: It solves an entirely different problem. My topic makes CMake detect which C++ features the compiler supports. Your topic is about how to get this to the targets and propagate it to the targets that use them. See the thread that split off from this one here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7795 titled c++ feature detection and usage requirements. The proposal covers both report of available features and propagation of requirements. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] External library dependency
We have a similar situation and the following works well enough for us:
ExternalProject_Add(
big_external_project
...
)
set(OUTPUT_FILES files generated by the external build here)
set_source_files_properties(${OUTPUT_FILES} PROPERTIES GENERATED true)
add_library(internal_library ${OUTPUT_FILES} and whatever else it
depends on)
add_dependencies(internal_library big_external_project)
Once it has been built, the big_external_project rarely gets rebuilt
unless we do a rm -rf * in the build tree.
Magnus
On 09/19/2013 07:31 PM, Weatherby,Gerard wrote:
We have an external library which is not easily cmakeable and takes
a long time to compile. We have a static copy of the source in our
SCCS, so we don't need to fetch etc.
What we'd like to have happen is have the code compile if and only if
the output libraries are not present. The best I've come up with is:
add_custom_command(OUTPUT ${CHOMBO_LIBS_2D}
PRE_BUILD
COMMAND ${CHOMBO_BUILD_CMD}
#DEPENDS don't add depends line ... causes
recompiling of Chombo every time
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}/Chombo/lib
)
# include the Chombo libraries as source file to
trigger building them via add_custom_command
# if they don't exist
add_executable(${EXE_2D} ${CHOMBO_LIBS_2D} ${SRC_FILES})
where CHOMBO_LIBS_2D are the libraries generated by CHOMBO_BUILD_CMD.
The libraries link in the source tree.
This works, mostly. It doesn't work with parallel builds (make --j9)
I tried looking at ExternalProject_Add but didn't seem how to tell it
what output is generated by the command (and hence I'm not sure how /
if it can be used to only make if the libraries are missing).
Gerard Weatherby
Appllication Architect
Virtual Cell, Center for Cell Analysis and Modeling (CCAM)
University of Connecticut Health Center
860-679-2065
--
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
--
Magnus Johansson
Developer, Fox Technologies
--
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] try_run or similar to find available Fortran integer kinds
Hi Zaak,
Based on the test for fortran compilers, couldn't you do something similar?
As I am no fortran expert I am not really sure which types you are
looking for, but I would suspect you could get what you want based on
the attached example?
Cheers,
Yngve
Den 19. sep. 2013 22:03, skrev Zaak Beekman:
Caveat: I am somewhat new to CMake.
I am programming a library to compute diagnostic statistics on VERY
large data sets. (Possibly in parallel too.) The algorithm is
numerically stable and online/streaming. The Fortran standard makes no
guarantee of what (signed) integer types are available on a given
system, but provides a means of requesting integers of different sizes
and will let you know at run time whether or not they exist. However,
kind (type) specification of variables must occur at compile time.
(This isn't strictly true in F03/F08 but compiler support is limited
ATM.) Since the algorithm is designed for extremely large data sets
(9TB!) and the number of elements visited in the set so far appears in
the algorithm, I would like to use the largest available integer kind
to keep track of this quantity so that it doesn't overflow.
I think what I need to do is create a test program and use try_run()
and then configure_file(), which leads me to my questions:
1. Can I have a multiple source file program and pass it to
try_run()? It seems like the answer is no.
2. Since Fortran has no concept of a return value (not formally as
far as the standard is concerned) it looks like I need to pass the
information about available kind types in the RUN_OUTPUT_VARIABLE
back to CMake and manipulate it there. Does this variable just get
populated with a string which is whatever your code (that you
try_ran) outputs to stdout?
3. Has someone written a module to diagnose available Fortran kind
types? That they're willing to share?
4. If not, where do I look for advice and best practices to write one
myself?
TIA,
Izaak Beekman
===
(301)244-9367
Princeton University Doctoral Candidate
Mechanical and Aerospace Engineering
ibeek...@princeton.edu mailto:ibeek...@princeton.edu
UMD-CP Visiting Graduate Student
Aerospace Engineering
ibeek...@umiacs.umd.edu mailto:ibeek...@umiacs.umd.edu
ibeek...@umd.edu mailto:ibeek...@umd.edu
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
cmake_minimum_required(VERSION 2.8)
project(test_fortran_integers Fortran)
macro(test_integer i)
message(Checking for integer*${i}..)
set(filename ${CMAKE_BINARY_DIR}/test_integer_${i}.f)
file(WRITE ${filename} program main\n)
file(APPEND ${filename} integer*${i} myinteger\n)
file(APPEND ${filename} end program main\n)
try_compile(HAVE_INTEGER_${i} ${CMAKE_BINARY_DIR}
${filename})
message(Checking for integer*${i}.. ${HAVE_INTEGER_${i}})
endmacro()
test_integer(2)
test_integer(4)
test_integer(6)
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Generating Visual Studio 2008 solution with specified toolset in command-line
Hello, I partially ported our project from Visual Studio vcproj files to cmake. I'm successful when I use cmake-gui and I select generator Visual Studio 9 2008 Windows Mobile 5.0 Smartphone SDK (ARMV4I). Correct solution file is generated and I can compile. Now I'm trying to generate solution file using command line for our intergeration server and right now running: mkdir build cd build cmake .. -G Visual Studio 9 2008 generates Visual Studio 9 2008 solution and I would like to specify somehow, not sure if toolset, but that Windows Mobile 5.0 Smartphone SDK (ARMV4I) part. I'm able to select it in the list of generators in cmake-gui. How can I do that in console? I see that there is toolset -T,but it is supported by Visual Studio 2010 generator and later, but then how cmake-gui is doing the trick? Regards, Lukas -- 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] try_run or similar to find available Fortran integer kinds
On 09/19/2013 04:03 PM, Zaak Beekman wrote: I think what I need to do is create a test program and use try_run() and then configure_file() If a runtime check is really necessary then something like this will be needed. However, see Yngve's sibling response. Is your original message saying that a Fortran compiler might compile integer*8 myinteger but fail at runtime? 1. Can I have a multiple source file program and pass it to try_run()? No, but try_compile does allow an entire test project source tree to be built, and that can have multiple sources. CMake's FortranCInterface module uses this to do mangling detection: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FortranCInterface/Detect.cmake;hb=v2.8.11.2#l37 The try_run command in CMake has not kept up with try_compile's features because the former is not useful for cross-compiling so it is seldom used. 2. Since Fortran has no concept of a return value (not formally as far as the standard is concerned) it looks like I need to pass the information about available kind types in the RUN_OUTPUT_VARIABLE back to CMake and manipulate it there. Does this variable just get populated with a string which is whatever your code (that you try_ran) outputs to stdout? Yes, but with the above suggestion using try_compile to build the test case you'll have to find the executable and use the execute_process command to run it. That has options to capture the output too. -Brad -- 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] try_run or similar to find available Fortran integer kinds
On Fri, Sep 20, 2013 at 12:00 PM, cmake-requ...@cmake.org wrote: Is your original message saying that a Fortran compiler might compile integer*8 myinteger but fail at runtime? No, my point is that there is no guarantee that integer*8 or integer*16 exist at all (at compile time) but you can query whether or not they exist at run time. However, you cannot dynamically pick the integer type of a variable at run time. For example, you can write code to request progressively larger integer kinds and return their kind if they exist, at run time. If they don't exist an error value is returned instead. However, the integer kind of a variable must be specified at compile time, so there is (currently) no viable way to dynamically select a variable's integer type. (Unlimited polymorphic variables and parameterized derived types fix these issues, but compiler support is spotty for the former and non-existent for the latter, and will take a long time to change.) To summarize the issue: Variable's integer kind type must be a compile time constant (currently) AND checks to determine what integer types are supported are run time only. It seems the array variable integer_kinds supplied in ISO_FORTRAN_ENV by the F2008 standard partially circumvents this issue, but, to my knowledge, there is no guarantee in the standard that the array holds the available integer kinds in a sorted order with the smallest integer kind as integer_kinds(1) and the largest as integer_kinds(size(integer_kinds)), but this would seem to be a reasonable assumption. I still am determining compiler support/compliance for this F2008 feature. Izaak Beekman === (301)244-9367 Princeton University Doctoral Candidate Mechanical and Aerospace Engineering ibeek...@princeton.edu UMD-CP Visiting Graduate Student Aerospace Engineering ibeek...@umiacs.umd.edu ibeek...@umd.edu -- 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] ExternalProject_Add - Automatic Incremental Rebuilds + Add Sources to IDE
You can structure the app CMakeLists such that it can reference the libs as part of a big build everything tree like this, or as something that has to be found with find_package, or as something you just point to with CMake variables. Was the parent CMakeLists.txt an example of only how to combine the sources, or should it be reasonably possible to do step-building? For example, I attempted the following... I've setup a parent CMakeLists.txt for the apps and libs as you described with subdirectories for apps and libs. I build the libs first, and have it set a variable of where the library will be installed to, named apps_lib_path. apps_lib_path is set with PARENT_SCOPE so it is passed into the apps/ directory. Now, in the apps folder I must reference to the library that libs will build. This seems to create a chicken-egg issue as I am trying to reference a library that isn't yet created. I am using find_package(libs) which checks several possible locations for the library, the first being apps_lib_path for the library libApps. Since no libApps is present (hasn't been built yet, still in the cmake stage) it is set to NOTFOUND and cmake returns an error. The best approach I've seen for this sort of thing so far is being used in the Open Cheimstry projects. They build and install everything as part of a super build into a known installation prefix in the super build build tree. Then, they use CMAKE_PREFIX_PATH and find_package to find *previously* built/installed sub-projects in subsequent sub-projects. Everything is built via ExternalProject there, but none of the individual projects build anything with ExternalProject -- they find everything with find_package. ( See their repos here: https://github.com/OpenChemistry -- the super build is in: https://github.com/OpenChemistry/openchemistry ) This is a great example, so they install into a common place where each project can use find_project(other_project) and link correctly. They force incremental rebuilds by using ExternalProject_Add_Step. Thanks for the help, - Aaron On Wed, Sep 18, 2013 at 8:51 AM, David Cole dlrd...@aol.com wrote: Ideally, for these rapid co-development phases I would like to a) Be able to rebuild a project using ExternalProject_Add whenever any source file changes. ExternalProject is not well suited for handling source level changes. b) Provide the mechanism for an IDE project to include all the sources from another project specified by ExternalProject_Add. Because of my answer for (a), I still don't think it's a good idea. For b) there was a bug open and closed here, http://www.cmake.org/Bug/view.**php?id=12322http://www.cmake.org/Bug/view.php?id=12322 I understand David's point about making bad assumptions, but I would find it extremely useful if I was able to include the sources and force a rebuild as I'm describing. I understand, and many others would also find it useful, but I doubt it can be done reliably. If somebody would like to prove me wrong, (on Windows with all supported versions of Visual Studio, and on the Mac with all versions of Xcode, and with Eclipse, and ...), I will gladly reverse my opinion. Does anyone have any ideas? We're currently doing a lot of refactoring on both repositories so removing as much development overhead will really help. When things get stable we will be using ExternalProject_Add on tagged revisions. The best solution for rapid co-development of multiple repositories is NOT to use ExternalProject. ExternalProject, as recently discussed in another mailing list thread here, is best suited for building static snapshots of repositories that do not change frequently. Does everything build with CMake? Good. Then you can make something like this work: # CMakeLists.txt cmake_minimum_required(VERSION 2.8.11) project(GlueLibsAndApp) add_subdirectory(libs) add_subdirectory(app) # Then, checkout the two separate repositories in libs and app and boom: all your sources for everything are all in the generated IDE project You can structure the app CMakeLists such that it can reference the libs as part of a big build everything tree like this, or as something that has to be found with find_package, or as something you just point to with CMake variables. Then later on, you can create a super build that builds both libs and app separately using ExternalProject, and have that app refer to the libs built in that manner, rather than as targets in the same CMakeLists directory structure. The best approach I've seen for this sort of thing so far is being used in the Open Cheimstry projects. They build and install everything as part of a super build into a known installation prefix in the super build build tree. Then, they use CMAKE_PREFIX_PATH and find_package to find *previously* built/installed sub-projects in subsequent sub-projects. Everything is built via ExternalProject there, but none of
[Cmake-commits] CMake branch, master, updated. v2.8.11.2-855-gd2cf4e9
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via d2cf4e990c3c9abc3b2036dfb78771c4eda2abe8 (commit) via 0f05961f03b2735b32e9da54b32287fb3631e76b (commit) from 45b182180c4203c909a31bee5da7c8bf713fbb14 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d2cf4e990c3c9abc3b2036dfb78771c4eda2abe8 commit d2cf4e990c3c9abc3b2036dfb78771c4eda2abe8 Merge: 45b1821 0f05961 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Sep 20 08:10:22 2013 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Sep 20 08:10:22 2013 -0400 Merge topic 'FindHDF5-fix-lib-selection' 0f05961 FindHDF5: Fix regression in per-configuration library selection --- Summary of changes: Modules/FindHDF5.cmake | 38 ++ 1 files changed, 2 insertions(+), 36 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.11.2-4257-g1824e60
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 1824e60717c7c679a56623957291f1de2190b5ee (commit) via d2cf4e990c3c9abc3b2036dfb78771c4eda2abe8 (commit) via 45b182180c4203c909a31bee5da7c8bf713fbb14 (commit) from 49f428046ce0ba1a2729afe0b2d1045e765aaccc (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1824e60717c7c679a56623957291f1de2190b5ee commit 1824e60717c7c679a56623957291f1de2190b5ee Merge: 49f4280 d2cf4e9 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Sep 20 08:09:25 2013 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Sep 20 08:09:25 2013 -0400 Merge branch 'master' into next --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.11.2-4263-g3fbf948
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 3fbf9485b8fa7786f36da56a86801bf4385457f1 (commit)
via 6a47c37ccf7049d5ac3fa6224def8d17ee82c7f5 (commit)
via d331292c121269ccfceee302a0f9bbb960b9f02d (commit)
via 6fe5c4afc0a8363927ecd48bea4cc822894f97db (commit)
from f8c114ea5689f2efd3aa59a29a891210009e6537 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3fbf9485b8fa7786f36da56a86801bf4385457f1
commit 3fbf9485b8fa7786f36da56a86801bf4385457f1
Merge: f8c114e 6a47c37
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Sep 20 08:21:27 2013 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Sep 20 08:21:27 2013 -0400
Merge topic 'test-property-genex' into next
6a47c37 add_test: Mention generator expressions in old-style add_test docs
d331292 cmTestGenerator: Evaluate generator expressions in test properties
6fe5c4a cmTestGenerator: Separate test properties for each configuration
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6a47c37ccf7049d5ac3fa6224def8d17ee82c7f5
commit 6a47c37ccf7049d5ac3fa6224def8d17ee82c7f5
Author: Ben Boeckel maths...@gmail.com
AuthorDate: Wed Aug 7 18:08:54 2013 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Sep 20 08:18:22 2013 -0400
add_test: Mention generator expressions in old-style add_test docs
The old-style add_test() call does not support generator expressions at
all. This also applies to the properties for the test, but it is not
mentioned at all.
diff --git a/Source/cmAddTestCommand.h b/Source/cmAddTestCommand.h
index ec7fda3..ce98aaa 100644
--- a/Source/cmAddTestCommand.h
+++ b/Source/cmAddTestCommand.h
@@ -66,7 +66,8 @@ public:
built by this project or an arbitrary executable on the
system (like tclsh). The test will be run with the current working
directory set to the CMakeList.txt files corresponding directory
- in the binary tree.\n
+ in the binary tree. Tests added using this signature do not support
+ generator expressions.\n
\n
add_test(NAME name [CONFIGURATIONS [Debug|Release|...]]\n
[WORKING_DIRECTORY dir]\n
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d331292c121269ccfceee302a0f9bbb960b9f02d
commit d331292c121269ccfceee302a0f9bbb960b9f02d
Author: Ben Boeckel maths...@gmail.com
AuthorDate: Wed Aug 7 17:07:30 2013 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Sep 20 08:18:22 2013 -0400
cmTestGenerator: Evaluate generator expressions in test properties
This is useful for cases like:
add_test(NAME mytest COMMAND mydriver $TARGET_FILE:myexe)
set_tests_properties(mytest PROPERTIES
REQUIRED_FILES $TARGET_FILE:myexe
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/$CONFIGURATION
)
In this example we require the actual test executable to exist to
run the test in addition to the test driver at argv[0]. Also the
$CONFIGURATION expression improves over \${CTEST_CONFIGURATION_TYPE}
because the latter is not normalized for case-sensitive filesystems.
diff --git a/Source/cmSetTestsPropertiesCommand.h
b/Source/cmSetTestsPropertiesCommand.h
index 3a59218..f2f2611 100644
--- a/Source/cmSetTestsPropertiesCommand.h
+++ b/Source/cmSetTestsPropertiesCommand.h
@@ -51,7 +51,8 @@ public:
set_tests_properties(test1 [test2...] PROPERTIES prop1 value1 prop2
value2)\n
Set a property for the tests. If the property is not found, CMake
- will report an error. The properties include:\n
+ will report an error. Generator expressions will be expanded the same
+ as supported by the test's add_test call. The properties include:\n
WILL_FAIL: If set to true, this will invert the pass/fail flag of the
test.\n
PASS_REGULAR_EXPRESSION: If set, the test output will be checked
diff --git a/Source/cmTestGenerator.cxx b/Source/cmTestGenerator.cxx
index 3167362..e5984a8 100644
--- a/Source/cmTestGenerator.cxx
+++ b/Source/cmTestGenerator.cxx
@@ -117,7 +117,8 @@ void cmTestGenerator::GenerateScriptForConfig(std::ostream
os,
i != pm.end(); ++i)
{
os i-first
- lg-EscapeForCMake(i-second.GetValue());
+ lg-EscapeForCMake(
+ ge.Parse(i-second.GetValue())-Evaluate(mf, config));
}
os ) std::endl;
}
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 9c3ed59..a5ad58c 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -604,6 +604,7 @@
[Cmake-commits] CMake branch, next, updated. v2.8.11.2-4265-g5081283
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 50812834abca50370338b8a86bdcf956406ad370 (commit) via 027a0201b270e582d76c1de94a60c19a2a8e505c (commit) from 3fbf9485b8fa7786f36da56a86801bf4385457f1 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=50812834abca50370338b8a86bdcf956406ad370 commit 50812834abca50370338b8a86bdcf956406ad370 Merge: 3fbf948 027a020 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Sep 20 08:23:04 2013 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Sep 20 08:23:04 2013 -0400 Merge topic 'generate-modern-style' into next 027a020 Merge branch 'test-property-genex' into generate-modern-style http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=027a0201b270e582d76c1de94a60c19a2a8e505c commit 027a0201b270e582d76c1de94a60c19a2a8e505c Merge: 33055c4 6a47c37 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Sep 18 14:05:30 2013 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Sep 20 08:20:01 2013 -0400 Merge branch 'test-property-genex' into generate-modern-style Resolve conflict in Source/cmTestGenerator.cxx by taking their side (test-property-genex). It already accounts for the lower-case change in our side (generate-modern-style). --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.11.2-4267-gfb9821f
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via fb9821f70dd959c377458ac15a0f9a8e35321c73 (commit)
via 4cc5c46ba26682dba9c800fe0963be2fab5a5734 (commit)
from 50812834abca50370338b8a86bdcf956406ad370 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fb9821f70dd959c377458ac15a0f9a8e35321c73
commit fb9821f70dd959c377458ac15a0f9a8e35321c73
Merge: 5081283 4cc5c46
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Fri Sep 20 17:53:21 2013 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Sep 20 17:53:21 2013 -0400
Merge topic 'add_cache_options_to_ccmake' into next
4cc5c46 Teach ccmake to understand cache option strings.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4cc5c46ba26682dba9c800fe0963be2fab5a5734
commit 4cc5c46ba26682dba9c800fe0963be2fab5a5734
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Fri Sep 20 17:47:38 2013 -0400
Commit: Bill Hoffman bill.hoff...@kitware.com
CommitDate: Fri Sep 20 17:47:38 2013 -0400
Teach ccmake to understand cache option strings.
This commit adds the ability to ccmake of cycling through cache options.
This uses the STRINGS property of the cache entry. The enter key will cycle
forward, and the right and left arrows will go up and down in the list.
diff --git a/Source/CursesDialog/CMakeLists.txt
b/Source/CursesDialog/CMakeLists.txt
index 5efc2fb..548f5a5 100644
--- a/Source/CursesDialog/CMakeLists.txt
+++ b/Source/CursesDialog/CMakeLists.txt
@@ -11,6 +11,7 @@
#=
set( CURSES_SRCS
+ CursesDialog/cmCursesOptionsWidget
CursesDialog/cmCursesBoolWidget
CursesDialog/cmCursesCacheEntryComposite
CursesDialog/cmCursesDummyWidget
diff --git a/Source/CursesDialog/cmCursesCacheEntryComposite.cxx
b/Source/CursesDialog/cmCursesCacheEntryComposite.cxx
index c58d037..249137f 100644
--- a/Source/CursesDialog/cmCursesCacheEntryComposite.cxx
+++ b/Source/CursesDialog/cmCursesCacheEntryComposite.cxx
@@ -10,6 +10,7 @@
See the License for more information.
*/
#include cmCursesCacheEntryComposite.h
+#include cmCursesOptionsWidget.h
#include cmCursesStringWidget.h
#include cmCursesLabelWidget.h
#include cmCursesBoolWidget.h
@@ -69,9 +70,27 @@ cmCursesCacheEntryComposite::cmCursesCacheEntryComposite(
it.GetValue());
break;
case cmCacheManager::STRING:
- this-Entry = new cmCursesStringWidget(this-EntryWidth, 1, 1, 1);
- static_castcmCursesStringWidget*(this-Entry)-SetString(
-it.GetValue());
+ if(it.PropertyExists(STRINGS))
+{
+cmCursesOptionsWidget* ow =
+ new cmCursesOptionsWidget(this-EntryWidth, 1, 1, 1);
+this-Entry = ow;
+std::vectorstd::string options;
+cmSystemTools::ExpandListArgument(
+ std::string(it.GetProperty(STRINGS)), options);
+for(std::vectorstd::string::iterator
+ si = options.begin(); si != options.end(); ++si)
+ {
+ ow-AddOption(*si);
+ }
+ow-SetOption(it.GetValue());
+}
+ else
+{
+this-Entry = new cmCursesStringWidget(this-EntryWidth, 1, 1, 1);
+static_castcmCursesStringWidget*(this-Entry)-SetString(
+ it.GetValue());
+}
break;
case cmCacheManager::UNINITIALIZED:
cmSystemTools::Error(Found an undefined variable: , it.GetName());
diff --git a/Source/CursesDialog/cmCursesOptionsWidget.cxx
b/Source/CursesDialog/cmCursesOptionsWidget.cxx
new file mode 100644
index 000..652b2df
--- /dev/null
+++ b/Source/CursesDialog/cmCursesOptionsWidget.cxx
@@ -0,0 +1,106 @@
+/*
+ CMake - Cross Platform Makefile Generator
+ Copyright 2000-2009 Kitware, Inc., Insight Software Consortium
+
+ Distributed under the OSI-approved BSD License (the License);
+ see accompanying file Copyright.txt for details.
+
+ This software is distributed WITHOUT ANY WARRANTY; without even the
+ implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ See the License for more information.
+*/
+#include cmCursesOptionsWidget.h
+#include cmCursesMainForm.h
+
+inline int ctrl(int z)
+{
+return (z037);
+}
+
+cmCursesOptionsWidget::cmCursesOptionsWidget(int width, int height,
+
