Re: [cmake-developers] target_include_directories branch in stage
On 09.12.2011 22:23, Brad King wrote: On 12/9/2011 3:44 PM, Peter Kümmel wrote: Maybe this is a bit late, but wouldn't it be much simpler to get this feature with a namespace inspired approach: http://public.kitware.com/Bug/view.php?id=11793 I think the namespace approach will be more intrusive to implement, and it is complementary to the much-needed per-target feature anyway. All within a namespace has the same scope as an add_subdirectory added target. This way we get more than the 'target_include_directories' without adding multiple target_* functions (which maybe will come). We don't really need a target_include_directories command. It will be just a convenience on top of setting the INCLUDE_DIRECTORIES target property with the set_property command. Ah, I thought target_include_directories is the reason for the new target property. -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] Fwd: How to handle different cmake versions in extra-cmake-modules ?
On Tuesday 06 December 2011, Alexander Neundorf wrote:
> Hi,
>
> On Monday 07 November 2011, Brad King wrote:
> > On 11/6/2011 6:12 AM, Stephen Kelly wrote:
> > > ecm_copy_modules(${CMAKE_BINARY_DIR}/modules FindFoo.cmake
> > >
> > > FindBlub.cmake
> > > ECMDoSomething.cmake)
> > >
> > > set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
> > > ${CMAKE_BINARY_DIR}/modules} )
> > >
> > > This macro would copy just these needed files into the given directory,
> > > which can then be added to CMAKE_MODULE_PATH.
> >
> > See below for an idea that may solve cases 2 and 3 together.
> >
> > > Case 3. I don't really have an idea yet. Add some code at the top of
> > > each file which include()s the file from cmake if the version is
> > > bigger than some specified version ?
> > >
> > > Something like:
> > > FindBlub.cmake:
> > >
> > > if(CMAKE_VERSION> 2.8.12)
> > >
> > >include(${CMAKE_ROOT}/Modules/FindBlub.cmake)
> > >return()
> > >
> > > endif()
> >
> > We've done the following before:
> > if(EXISTS ${CMAKE_ROOT}/Modules/FindBlub.cmake)
> >
> > include(${CMAKE_ROOT}/Modules/FindBlub.cmake)
> > return()
> >
> > endif()
> >
> > That way you don't need to know when the module is added. It is also
> > forward-compatible for any module not yet in CMake but may be later.
> > OTOH the version of the module added to CMake may provide a slightly
> > different interface than the original version. That leads to the
> > unfortunate situation that a newer CMake breaks an existing build,
> > which looks like CMake's fault but isn't.
> >
> > Another option is to provide a function that generates forwarding
> > modules. Instead of ecm_copy_modules, create a similar API that
> > generates short modules that include either the ECM version or the
> > CMake version depending on some conditions. Do the inclusion by
> > full path so that the actual ECM module dir does not need to be in
> > the CMAKE_MODULE_PATH.
>
> yesterday in the train I found the time to do start with something on this.
>
> So, here is the idea:
>
> * the files containing macros/functions and the find-modules are put into
> two different directories, e.g. modules/macros/ and modules/find/.
>
> (Since the macros will all have the "ecm_" prefix, a clash with anything
> from cmake is not possible. So we only have to care about the
> Find-modules.) So when doing
> find_package(extra-cmake-modules)
> two variables will be defined, ECM_MACROS_DIR and ECM_FIND_MODULES_DIR.
>
> If somebody wants everything, he does
>
> set(CMAKE_MODULES_PATH ${ECM_MACROS_DIR} ${ECM_FIND_MODULES_DIR} )
>
> If he wants to use only some macros, he does
> set(CMAKE_MODULES_PATH ${ECM_MACROS_DIR} )
>
> If he wants to use a subset of the find-modules, there is a function
> ecm_use_find_modules:
> ecm_use_find_modules(DIR
> MODULES FindFoo.cmake FindBar.cmake ...
> [NO_OVERRIDE] )
>
> The listed find-modules will be copied from ${ECM_FIND_MODULES_DIR} to the
> directory given here as destination dir, and this directory has to be added
> to CMAKE_MODULE_PATH.
> If NO_OVERRIDE is used, the files will only be used if they do not exist in
> cmake.
> This way e.g. FindBlub.cmake will be used until it is part of cmake, then
> the cmake version will be used.
>
> Attached is a draft of the file, just to show the idea, I didn't actually
> try to run it yet.
>
>
> Examples:
>
> 1) use everything from e-c-m:
>
> find_package(extra-cmake-modules REQUIRED)
> set(CMAKE_MODULE_PATH ${ECM_MACROS_DIR} ${ECM_FIND_MODULES_DIR} )
>
> 2) make all macros available, but no find-modules:
>
> find_package(extra-cmake-modules REQUIRED)
> set(CMAKE_MODULE_PATH ${ECM_MACROS_DIR} )
>
> 3) make all macros available and some find-modules if they do not yet exist
> in cmake:
>
> find_package(extra-cmake-modules REQUIRED)
> ecm_use_find_modules(DIR ${CMAKE_CURRENT_BINARY_DIR}/ecm/
> MODULES FindFoo.cmake NO_OVERRIDE)
>
> set(CMAKE_MODULE_PATH ${ECM_MACROS_DIR} ${CMAKE_CURRENT_BINARY_DIR}/ecm/ )
>
>
> 4) make all macros available and some find-modules as override for the
> cmake ones:
>
> find_package(extra-cmake-modules REQUIRED)
> ecm_use_find_modules(DIR ${CMAKE_CURRENT_BINARY_DIR}/ecm/
> MODULES FindBoost.cmake)
>
> set(CMAKE_MODULE_PATH ${ECM_MACROS_DIR} ${CMAKE_CURRENT_BINARY_DIR}/ecm/ )
>
>
> Does that look like it should cover all use cases, for peopling wanting to
> selectively use some things from e-c-m, and fearing that something would
> break if they simply would make everything available ?
I added this now to extra-cmake-modules:
http://quickgit.kde.org/?p=extra-cmake-
modules.git&a=blob&hb=HEAD&f=modules/ECMUseFindModules.cmake
The find-modules now go into find-modules/, other modules go into modules/.
Alx
--
Powered by www.kitware.com
Visit other Kitware open-source project
[cmake-developers] Adding macro cmake_print_variables(var1 var2 ... varN) ?
Hi,
I have a small macro/function which I need often during buildsystem debugging:
function(PRINT_VARIABLES)
set(msg "")
foreach(var ${ARGN})
if(msg)
set(msg "${msg} ; ")
endif()
set(msg "${msg}${var}=\"${${var}}\"")
endforeach()
message(STATUS "${msg}")
endfunction()
it prints the values of the variables given as arguments.
Example:
print_variables(CMAKE_C_COMPILER
CMAKE_MAJOR_VERSION
THIS_ONE_DOES_NOT_EXIST)
Gives:
-- CMAKE_C_COMPILER="/usr/bin/gcc" ; CMAKE_MAJOR_VERSION="2" ;
THIS_ONE_DOES_NOT_EXIST=""
Ok to add to git ?
Or should this better be
message(VARIABLES CMAKE_C_COMPILER
CMAKE_MAJOR_VERSION
THIS_ONE_DOES_NOT_EXIST)
Or not at all ?
Then I'll put it in extra-cmake-modules, but it seems to generic that I think
it makes sense to have it in cmake directly.
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] A few more changes to automoc before 2.8.7
Hi, in current CMake HEAD automoc has two modes: strict and not strict. In strict mode it is behaves exactly how the documentation says: "If an #include statement like #include "moc_foo.cpp" is found, the Q_OBJECT class declaration is expected in the header, and moc is run on the header file. If an #include statement like #include "foo.moc" is found, then a Q_OBJECT is expected in the current source file and moc is run on the file itself." In non-strict mode it accepts more, which makes it kdelibs4-compatible. The strict mode should be qmake-compatible AFAIK. Currently, if Qt4 is detected CMAKE_AUTOMOC_STRICT_MODE is initialized to FALSE, if Qt5 is detected it is initialized to TRUE. I'd like to change that so that it is always initialized to TRUE, so everybody gets strict mode by default (which is easier to understand). Then, if STRICT mode is default, I'm thinking about inverting the variable, i.e. from CMAKE_AUTOMOC_STRICT_MODE to CMAKE_AUTOMOC_RELAXED_MODE or something. This way the other non-standard mode would be enabled by setting a variable to TRUE instead to FALSE, which would be better IMO. Makes sense ? And I would need a better name than "CMAKE_AUTOMOC_RELAXED_MODE", FORGIVING, LOOSE, better ideas ? And, again a question regarding wording, currently the warnings generated by automoc say "Better for a more robust build." I'd like to have a better way to express it. "Use for STRICT mode compatibility." ? or "for qmake compatibility" ? Better ideas ? Thanks 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Fwd: Adding macro cmake_print_variables(var1 var2 ... varN) ?
List was dropped intentionally
-- Forwarded message --
From: Eric Noulard
Date: 2011/12/11
Subject: Re: [cmake-developers] Adding macro
cmake_print_variables(var1 var2 ... varN) ?
To: neund...@kde.org
2011/12/11 Alexander Neundorf :
> Hi,
>
> I have a small macro/function which I need often during buildsystem debugging:
>
> function(PRINT_VARIABLES)
> set(msg "")
> foreach(var ${ARGN})
> if(msg)
> set(msg "${msg} ; ")
> endif()
> set(msg "${msg}${var}=\"${${var}}\"")
> endforeach()
> message(STATUS "${msg}")
> endfunction()
>
>
> it prints the values of the variables given as arguments.
> Example:
>
> print_variables(CMAKE_C_COMPILER
> CMAKE_MAJOR_VERSION
> THIS_ONE_DOES_NOT_EXIST)
>
> Gives:
> -- CMAKE_C_COMPILER="/usr/bin/gcc" ; CMAKE_MAJOR_VERSION="2" ;
> THIS_ONE_DOES_NOT_EXIST=""
pretty handy.
> Ok to add to git ?
May be in a specific separate file like
CMakeScriptsDebuggingTools.cmake
(or some less lengthy name)
one may include ?
> Or should this better be
> message(VARIABLES CMAKE_C_COMPILER
> CMAKE_MAJOR_VERSION
> THIS_ONE_DOES_NOT_EXIST)
Nope I wouldn't vote for that one.
How would you print
message(VARIABLES "BLAH " CMAKE_C_COMPILER)
and
message(VARIABLES "BLAH CMAKE_C_COMPILER")
what you be nice as a built-in is something like
trace_var(CMAKE_C_COMPILER)
which would make the concerned VAR to be traced each time
it is touched (read or written) by a script.
That said we are far away from your initial need.
and... I'm not volunteering to develop that :-(
> Then I'll put it in extra-cmake-modules, but it seems to generic that I think
> it makes sense to have it in cmake directly.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012619]: cmDependsC class Scan ignore same file name
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12619 == Reported By:chizhong jin Assigned To: == Project:CMake Issue ID: 12619 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2011-12-12 02:12 EST Last Modified: 2011-12-12 02:12 EST == Summary:cmDependsC class Scan ignore same file name Description: cmDependsC use cache for speed up dependences scan. But produce a bug. When you have two or more file with same name in different directories. cmDependsC will miss some of file. Steps to Reproduce: create src tree like this. xxx/ t.h a.h src/ a.h a.cpp a.cpp include ../t.h && a.h t.h include a.h create a CMakeLists.txt "add_executable(a a.cpp)" then in xxx do $ mkdir build && cd build && cmake ../src && make $ cat CMakeFiles/a.dir/depend.internal we get result like: CMakeFiles/a.dir/a.cpp.o /home/jcz/Desktop/src/test/cmake/samefilename/src/../t.h /home/jcz/Desktop/src/test/cmake/samefilename/src/a.cpp /home/jcz/Desktop/src/test/cmake/samefilename/src/a.h no ../a.h == Issue History Date ModifiedUsername FieldChange == 2011-12-12 02:12 chizhong jin New Issue == -- 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
