[cmake-developers] [CMake 0012385]: Dependencies of check_*_source_compiles are not tracked
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12385 == Reported By:simonh Assigned To: == Project:CMake Issue ID: 12385 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-08-03 06:55 EDT Last Modified: 2011-08-03 06:55 EDT == Summary:Dependencies of check_*_source_compiles are not tracked Description: It would be useful if the text/source being tested were scanned for dependencies. At the moment, if the header files used by the test source change, there is no re-run of the test. Attached is an example, very simple project, whose successful build depends on a certain header VERSION macro. This is correctly tested initially, but if the contents of that header file change (e.g. to #define HEADER 100), the CMake configuration is not re-run. == Issue History Date ModifiedUsername FieldChange == 2011-07-25 14:00 Dominique BelhachemiChangeset attached= VTK master b7dde9bb 2011-07-25 14:00 David Partyka Changeset attached= VTK master 06385b75 2011-08-03 06:55 simonh New Issue 2011-08-03 06:55 simonh File Added: check_test.tar.gz == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Supporting imported targets in CHECK_CXX_SOURCE_COMPILES() and friends
On 7/18/2011 4:13 PM, Alexander Neundorf wrote:
Hi,
in KDE we have a copy of CHECK_CXX_SOURCE_COMPILES() which supports imported
targets in CMAKE_REQUIRED_LIBRARIES:
http://websvn.kde.org/branches/KDE/4.5/kdelibs/cmake/modules/CheckCXXSourceCompiles.cmake?revision=1143427view=markup
http://websvn.kde.org/branches/KDE/4.5/kdelibs/cmake/modules/HandleImportedTargetsInCMakeRequiredLibraries.cmake?view=markup
This means, you can put any ${FOO_LIBRARY} you got from some find-module into
CMAKE_REQUIRED_LIBRARIES and it will work, also if ${FOO_LIBRARY} is actually
an imported target and not a path to a library.
It works for us in KDE and I am not aware of problems with it. Also, the
number of imported targets is increasing, by more and more projects installing
Config.cmake files, so this is getting more important.
I can remember that quite some time ago I suggested to merge this into cmake,
but there were objections. I can't remember what the objections were, well,
actually I don't see a reason not to have that in cmake.
So, do these objections still exist or can I merge that into cmake ?
I think this was a private discussion we had over 2 years ago. Here is
all I could find from that thread. It looks like we were talking about
creating a general solution for try_compile. I still don't have time to
look at it in detail, and the special case solution the above scripts
provide will not conflict with a future general solution.
Please try to generalize the scripts to work with the other CMake check
modules and push a topic to the stage for me to review.
Thanks,
-Brad
==
From: Alexander Neundorf neund...@kde.org
To: Brad King brad.k...@kitware.com
Subject: Re: issue with imported library targets ?
Date: Thu, 12 Mar 2009 22:54:57 +0100
Hi Brad,
there is one more issue with imported library targets.
We have now e.g. ${KDE4_KDEUI_LIBRARY} in KDE, which resolves to the imported
target KDE4__kdeui .
Now if you try to use that for CMAKE_REQUIRED_LIBRARIES e.g. in
check_cxx_source_runs(), it breaks, because the trycompile-project doesn't
know about that imported target.
I made a quick almost working fix which we can add to KDE to make it work:
http://lists.kde.org/?l=kde-buildsystemm=123689449526711w=2
Something should go into cmake to make that work, not sure whether these
macros should be extended this way or whether cmCoreTryCompile should try to
analyze the flags and if it sees LINK_LIBRARIES iterate over it and handle it
appropriately. It seems almost a bit complicated for doing it in cmake code.
What do you think ?
Alex
==
Date: Fri, 13 Mar 2009 09:20:07 -0400
From: Brad King brad.k...@kitware.com
To: Alexander Neundorf neund...@kde.org
Subject: Re: issue with imported library targets ?
Alexander Neundorf wrote:
there is one more issue with imported library targets.
We have now e.g. ${KDE4_KDEUI_LIBRARY} in KDE, which resolves to the imported
target KDE4__kdeui .
Now if you try to use that for CMAKE_REQUIRED_LIBRARIES e.g. in
check_cxx_source_runs(), it breaks, because the trycompile-project doesn't
know about that imported target.
I made a quick almost working fix which we can add to KDE to make it work:
http://lists.kde.org/?l=kde-buildsystemm=123689449526711w=2
Something should go into cmake to make that work, not sure whether these
macros should be extended this way or whether cmCoreTryCompile should try to
analyze the flags and if it sees LINK_LIBRARIES iterate over it and handle it
appropriately. It seems almost a bit complicated for doing it in cmake code.
I was reading that thread and realized the problem as soon as I saw
mention of KDE4__kdeui in a try-compile message thread. Certainly we
should try to get the C++ code implementing try-compile to take care of
this. Since the try-compile implementation knows what configuration it
will try to build (Debug, IIRC) it can just pre-compute the path to the
library and give it to the test project. I'm not sure how to handle
dependencies though. Perhaps instead the generated test project should
get code to reproduce the imported target.
I'll try to get to this sometime next week.
-Brad
==
From: Alexander Neundorf neund...@kde.org
To: Brad King brad.k...@kitware.com
Subject: Re: issue with imported library targets ?
Date: Sun, 15 Mar 2009 21:37:32 +0100
On Friday 13 March 2009, you wrote:
Alexander Neundorf wrote:
there is one more issue with imported library targets.
We have now e.g. ${KDE4_KDEUI_LIBRARY} in KDE, which resolves to the
imported target KDE4__kdeui .
Now if you try to use that for CMAKE_REQUIRED_LIBRARIES e.g. in
check_cxx_source_runs(), it breaks, because the trycompile-project
doesn't know about that imported target.
I made a quick almost working fix which we can add to KDE to
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On Monday 01 August 2011, Alexander Neundorf wrote: On Monday 01 August 2011, Brad King wrote: On 07/31/2011 04:09 PM, Alexander Neundorf wrote: I'm not sure which syntax I like better. The one with the macro feels more high-level, but maybe hides too much what is actually going on (which is not much). The one where the user must use configure_file() directly feels more low-level, but doesn't try to make a secret of what's going on, which may be better to encourage users to write their own version files. Which one would you prefer ? I'll add tests for the one we decide to use. I like the macro better. It will allow us to extend the capabilities later while retaining compatibility. If we let people configure the file directly then if we add more fields that need replacement in the future then old versions may stop working because there are no defaults for new fields. I pushed and merged now a 3rd branch WriteConfigVersionFile_2TemplateFiles which does both: it provides the Are you ok with this branch or are there issues left (...since it wasn't merged into master on Tuesday) ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindDevIL.cmake module looks for wrong header
On 8/2/2011 4:41 PM, Miłosz Kosobucki wrote:
FindDevIL.cmake module seems to be looking for il.h header instead of
IL/il.h. This way, user should be writing
#includeil.h
instead of
#includeIL/il.h
in his code. Note that the latter version is used with all examples in
DevIL library. Also libraries like OpenGL use the latter format.
I hope I included the patch properly. It was tested on Windows (MSVC
2010) and Linux.
Unfortunately this is a backward-incompatible change. If a CMake-based
project does
find_package(DevIL)
include_directories(${IL_INCLUDE_DIR})
and in its C code has
#include il.h
then it would work prior to this patch and not afterward. In order to
make this change in a compatible way you will need to use a different
variable name.
The module also needs to be fixed to follow conventions documented in
the module readme (note the difference between singular and plural names):
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/readme.txt;hb=v2.8.5
Perhaps you can name all the variables with a DevIL_ prefix and the
proper behavior you propose above. Then provide compatible values in
the old names.
BTW, currently the FindDevIL module has no module maintainer:
http://www.cmake.org/Wiki/CMake:Module_Maintainers
to review patches and maintain the module. If you're interested in
becoming the maintainer for this module, let me know.
-Brad
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012386]: A FindItstool module is missing
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12386 == Reported By:Nathan Samson Assigned To: == Project:CMake Issue ID: 12386 Category: Modules Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2011-08-03 20:28 EDT Last Modified: 2011-08-03 20:28 EDT == Summary:A FindItstool module is missing Description: itstool is a free and opensource software tool that is used in some projects to generate documentation (as far as I know). The projects that are using CMake and itstools are doomed to A) hardcode the itstool executable (and hope the user has it installed) B) include their own FindItstool file This bug reports wants to solve that with an attached FindItstool.cmake module. It is very basic, but as far as I know it does not need more. Please give comments and/or include. == Issue History Date ModifiedUsername FieldChange == 2011-08-03 20:28 Nathan Samson New Issue 2011-08-03 20:28 Nathan Samson File Added: FindItstool.cmake == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Include directories for C compile command
Hello everyone, I'm trying to set up an environment for building a pre-existing medium sized embedded software project, by using CMake 2.8 and MinGW. The compiler kit is specific for the target microcontroller and contains C compiler, assembler, linker, all different executables. I do have some restrictions: The project structure looks like this: Sources |-- SWC1 ||-- swc1.c ||-- swc1.h ||--CMakeLists.txt |-- SWC2 ||-- swc2_a.c ||-- swc2_b.c ||-- swc2.h ||--CMakeLists.txt |-- COMMON ||-- config1.h ||-- config2.h ||--CMakeLists.txt |-- UNUSED_DIR |-- SWC3 ||-- swc3.obj ||-- swc3.h - I cannot change the directory structure of the project (i can add but i must not move files around) - each SW module (component) has it own files including interface headers in it's own directory (SW component SWC1 resides in folder SWC1 and contains a source file and a header file) - SW modules may be interfaced with any other module (swc1.c may include swc2.h...) - There are common header files with project scope definitions and configurations which reside in their own directory too (both swc1.c and swc2.c may include headers config1.h and config2.h) - The SW has more variants, some variants use different C source files for a specific SW component but the sources reside in the same directory and interface headers are common for all variants. (For SW variant A the SW component SWC2 uses swc2_a.c source file, for SW variant B it uses swc2_b.c file) - Some SW components are precompiled and provided as object files together with the interface header (SWC3) *These being the conditions, i couldn't manage to gather the relevant folders in order to correctly create the build object command *where flags like -Idir_pah1 -Idir_path2 ... are expected in order to look for included headers. Due to mixed source-precompiled objects I chose to define each component as a static library (add_library(...)) in each CMakeLists.txt file and list there the used source files, being able to use conditions for SW variants and basically add different library definitions for each variant. I intend to add the pre-compiled sources as IMPORTED libraries and in the end just link the libraries with the specific linker command for linking any object files (but i didn't get there yet!) I'm currently use the default CMAKE_C_COMPILE_OBJECT command CMAKE_C_COMPILER DEFINES FLAGS -o OBJECT -c SOURCE, the compiler ignoring the unknown flags (-c in this case). *Without any explicit configuration from my part, it looks like FLAGS variable contains also a -Ipath directive for the current compiled source file* (path is the same directory where the source files about to be compiled resides). I tried to use set( CMAKE_INCLUDE_CURRENT_DIR ON ) in each CMakeLists.txt file but FLAGS variable seems not to be updated this way. I'd like to know if there is an efficient method to build an include directory list in order to pass it to compile flags. It would be very useful to make this in CMakeLists.txt file or link it somehow to add_directory(dir) and use an internal CMake mechanism trying to avoid creating this part of the compiler flags manually in order to be easily maintained in the future. Thanks, Andrei ___ 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-developers] Cross platform test for comparing two text files
2011/8/2 Ali Ghayoor alii.ghay...@gmail.com: Thank you Eric, I want use this inside a Cmake file not as a command line, you can call cmake from within a CMake script using execute_process. so I used the flag of --compare_files inside the Cmake file, but it does not still work. I do not understand what you mean here? PS: please do not drop the list address when replying. -- 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] Header and CXX.includecache - how first comes in second
On 08/03/2011 01:07 PM, Mikhail Pridushchenko wrote: Hello! I have a problem with include files dependencies in my C++ project: iostream system header (for example) is being cached by CMake in CXX.includecache file for some targets. Also there are no #include iostream lines in my sources. I wonder if there is any way to figure out where it could come from? Thank you. -- Mikhail Pridushchenko Create the preprocessed file like this: cd path/to/build/tree/where/target/is/defined make help # look for an appropriate sourcename.i in the output make sourcename.i # open the file name in the output in a text editor It is important that if your target (e.g. library or executable) is defined in a sub-directory, you have to call the make help and make sourcename.i commands in the corresponding directory of the build tree. This file is the file as the compiler sees it after preprocessing. You can follow the trace of which file includes what other files. HTH 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] Gathering up required shared libraries
On Tuesday, August 02, 2011 06:36:45 pm David Cole wrote: On Tue, Aug 2, 2011 at 8:05 PM, Clinton Stimpson clin...@elemtech.com wrote: On Aug 2, 2011, at 5:47 PM, Gregory Crosswhite wrote: On 8/2/11 4:32 PM, Clinton Stimpson wrote: There is no scanning the file system to find which libraries to fix up. Any libraries used by executables will be considered in the set of libraries to fix up, regardless of where they are installed (in bin/ or lib/). Any libraries not found as a dependency can be specified by the second parameter of fixup_bundle(). Plugins are a typical example of that, because executables and libraries don't link against plugins. Doh! For some reason I thought I saw that the code was doing that but I see now that I was mistaken. You don't need to add your libraries to the second parameter. If you did, you'd have to know them all up front, and that defeats one of the purpose of BundleUtilities. Sorry, I obviously didn't make it clear that I was referring to libraries that I was not planning on linking the program against --- that is, libraries provided for the benefit of other developers but not actually used by my program. Having said that, discussing this has made me realize that in my case it would probably make more sense for me to link against my own shared library anyway to prevent code from being duplicated in both program and library, so my use case is not as likely as I had been originally imagining. Oh, so you're also providing libraries for other developers. In that case, you do specify them into the second parameter of fixup_bundle(). If those libraries have additional dependencies, then BundleUtilities could be useful for that. Clint ___ 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 Let's not lose sight of the intent behind fixup_bundle here. I don't want to confuse things by trying to make it all things to all people. For our purposes, a bundle is a relocatable file system entity (a directory) which contains a set of executables and libraries that after fixup, are entirely self-contained, referring to each other only by relative paths, and will work on any compatible OS, regardless of where they are placed in the target file system. On the Mac, this is achieved by copying external libraries into the bundle and fixing up their references. Elsewhere, this is typically achieved by copying libraries into the same directory with the executable (on Windows, just works, on Linux, works as long as you use $ORIGIN RPATH references). When you do not have a .app directory, and you are not copying into the same directory with the executable, then the question in my mind becomes what exactly is 'the bundle' at this point? With a dir/bin, dir/lib typical Linux style layout, dir would be the bundle... If we really want to support this, perhaps we need another function to extend fixup_bundle so that you pass in the bundle's directory, and its main executable, or a list of executables. Instead of trying to derive it from just the main executable like we do now. Ok.. that does sound like a good idea. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ 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 to installing cmake Config.cmake files under Debian multiarch ?
On 8/3/2011 11:41 AM, Alexander Neundorf wrote:
On Tuesday 02 August 2011, Hendrik Sattler wrote:
If you use cmake 2.8.5, you can use GNUInstalldirs.cmake and let the user
specify the multiarch directory to install in (or solve it once in that
cmake module).
You mean having the user adjust the lib install dir correctly manually ?
Hmm, I think it is not realistic to expect that users will know about that.
There must be a way to do this so that it is works automatically, at least so
that a cmake on the same system will find what was installed.
See discussion here on why we can't transform the install() DESTINATION
options magically:
http://www.cmake.org/Bug/view.php?id=11964#c25884
The conclusion was that user code that intends to support such cases
must reference a variable in its install destinations. The
GNUInstallDirs module provides a good variable to reference:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/GNUInstallDirs.cmake;hb=v2.8.5#l71
install(... DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/Foo)
However, as noted in the comments it still needs to be taught about
multiarch. Even though that it doesn't do it in CMake 2.8.5 the variable
is a cache entry so packagers can fix it at build time.
The find_package command in CMake 2.8.5 is multiarch-aware and will
search the right place under each installation prefix.
-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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Assembly language support using gcc or gas
I tried changing from ASM to ASM-ATT and that fails like this:
/usr/bin/as -I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src
-I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/kernel
-DNOMINMAX -DUSE_SIM_NAMESPACE -o
CMakeFiles/systemc.dir/src/sysc/qt/md/i386.s.o
/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/qt/md/i386.s
/usr/bin/as: unrecognized option `-NOMINMAX'
I really don't think the -I and -D options should be passed through for
assembler files. They only make sense for C/C++ files. There should be a
separate variable like CMAKE_ASM_FLAGS that is used instead of CMAKE_C_FLAGS
or CMAKE_CXX_FLAGS. And maybe there needs to be a change to the
add_definitions() command to allow an optional LANG argument ? Do assembers
even support preprocessor definitions ?
I was able to get it to work for both 2.8.4 and 2.8.5 with the following
code:
if(UNIX)
list(APPEND sources src/sysc/qt/qt.c)
# see if we are building 32-bit or 64-bit executables
file(WRITE ${CMAKE_BINARY_DIR}/check_32or64bit.cpp int main(int argc,
char *argv[]) { return 8 * sizeof(char *); }\n)
try_run(
run_result
compile_result
${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}/check_32or64bit.cpp
)
if (${run_result} EQUAL 32)
list(APPEND sources src/sysc/qt/md/i386.s)
if(APPLE)
set(ASM_SYS_FLAGS -arch i386)
else()
set(ASM_SYS_FLAGS -32)
endif()
else()
list(APPEND sources src/sysc/qt/md/iX86_64.s)
if(APPLE)
set(ASM_SYS_FLAGS -arch x86_64)
else()
set(ASM_SYS_FLAGS -64)
endif()
endif()
enable_language(ASM-ATT)
set(CMAKE_ASM-ATT_COMPILE_OBJECT CMAKE_ASM-ATT_COMPILER
${ASM_SYS_FLAGS} -o OBJECT SOURCE)
endif()
I'm not sure if this is the recommended way to do this though. I thought
the documentation said to override CMAKE_ASM-ATT_COMPILE_OBJECT before the
enable_language() command. If I do that then I get the -I and -D flags back
and my ASM_SYS_FLAGS variable is ignored. Is there a cleaner way to do this
or is my current solution okay ?
2011/8/2 Alexander Neundorf a.neundorf-w...@gmx.net
Hi,
On Tuesday 02 August 2011, Glenn Coombs wrote:
Previously with cmake 2.8.4 we were using these lines to compile an
with 2.8.5 there was a major rework of the assembler support (and now it
finally does not say Assembler support is experimental anymore).
Sorry that this causes inconvenience for you.
If you enable ASM, you get support for assembler via your C/C++ compiler.
That's why you get gcc now instead of as.
If the C/C++ compiler does not support processing assembler files, this
language can't be enabled.
If you need a real assembler, you have to enable the respective assembler
dialect. E.g. to get as/gas, you need to enable ASM-ATT.
This should work with both versions.
Let me know if this doesn't work for you.
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] Include directories for C compile command
Have you tried using the include_directories() command ? In your top level CMakeLists.txt add a line like this: include_directories(SWC1 SWC2 SWC3 Common) before you do any add_subdirectory() commands. Does that not add the appropriate -Ixxx flags to the compile command ? It does for me but I'm using Visual Studio and gcc rather than an embedded compiler. On 3 August 2011 07:25, Andrei Buzgan andrei.buz...@gmail.com wrote: Hello everyone, I'm trying to set up an environment for building a pre-existing medium sized embedded software project, by using CMake 2.8 and MinGW. The compiler kit is specific for the target microcontroller and contains C compiler, assembler, linker, all different executables. I do have some restrictions: The project structure looks like this: Sources |-- SWC1 ||-- swc1.c ||-- swc1.h ||--CMakeLists.txt |-- SWC2 ||-- swc2_a.c ||-- swc2_b.c ||-- swc2.h ||--CMakeLists.txt |-- COMMON ||-- config1.h ||-- config2.h ||--CMakeLists.txt |-- UNUSED_DIR |-- SWC3 ||-- swc3.obj ||-- swc3.h - I cannot change the directory structure of the project (i can add but i must not move files around) - each SW module (component) has it own files including interface headers in it's own directory (SW component SWC1 resides in folder SWC1 and contains a source file and a header file) - SW modules may be interfaced with any other module (swc1.c may include swc2.h...) - There are common header files with project scope definitions and configurations which reside in their own directory too (both swc1.c and swc2.c may include headers config1.h and config2.h) - The SW has more variants, some variants use different C source files for a specific SW component but the sources reside in the same directory and interface headers are common for all variants. (For SW variant A the SW component SWC2 uses swc2_a.c source file, for SW variant B it uses swc2_b.c file) - Some SW components are precompiled and provided as object files together with the interface header (SWC3) *These being the conditions, i couldn't manage to gather the relevant folders in order to correctly create the build object command *where flags like -Idir_pah1 -Idir_path2 ... are expected in order to look for included headers. Due to mixed source-precompiled objects I chose to define each component as a static library (add_library(...)) in each CMakeLists.txt file and list there the used source files, being able to use conditions for SW variants and basically add different library definitions for each variant. I intend to add the pre-compiled sources as IMPORTED libraries and in the end just link the libraries with the specific linker command for linking any object files (but i didn't get there yet!) I'm currently use the default CMAKE_C_COMPILE_OBJECT command CMAKE_C_COMPILER DEFINES FLAGS -o OBJECT -c SOURCE, the compiler ignoring the unknown flags (-c in this case). *Without any explicit configuration from my part, it looks like FLAGS variable contains also a -Ipath directive for the current compiled source file* (path is the same directory where the source files about to be compiled resides). I tried to use set( CMAKE_INCLUDE_CURRENT_DIR ON ) in each CMakeLists.txt file but FLAGS variable seems not to be updated this way. I'd like to know if there is an efficient method to build an include directory list in order to pass it to compile flags. It would be very useful to make this in CMakeLists.txt file or link it somehow to add_directory(dir) and use an internal CMake mechanism trying to avoid creating this part of the compiler flags manually in order to be easily maintained in the future. Thanks, Andrei ___ 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] Assembly language support using gcc or gas
Hi,
On Wednesday 03 August 2011, Glenn Coombs wrote:
I tried changing from ASM to ASM-ATT and that fails like this:
/usr/bin/as -I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src
-I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/kernel
-DNOMINMAX -DUSE_SIM_NAMESPACE -o
CMakeFiles/systemc.dir/src/sysc/qt/md/i386.s.o
/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/qt/md/i386.
s /usr/bin/as: unrecognized option `-NOMINMAX'
I really don't think the -I and -D options should be passed through for
assembler files. They only make sense for C/C++ files. There should be a
separate variable like CMAKE_ASM_FLAGS that is used instead of
CMAKE_C_FLAGS or CMAKE_CXX_FLAGS. And maybe there needs to be a change to
the
add_definitions() command to allow an optional LANG argument ? Do
assembers even support preprocessor definitions ?
I was able to get it to work for both 2.8.4 and 2.8.5 with the following
code:
if(UNIX)
list(APPEND sources src/sysc/qt/qt.c)
# see if we are building 32-bit or 64-bit executables
file(WRITE ${CMAKE_BINARY_DIR}/check_32or64bit.cpp int main(int argc,
char *argv[]) { return 8 * sizeof(char *); }\n)
try_run(
run_result
compile_result
${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}/check_32or64bit.cpp
)
if (${run_result} EQUAL 32)
list(APPEND sources src/sysc/qt/md/i386.s)
if(APPLE)
set(ASM_SYS_FLAGS -arch i386)
else()
set(ASM_SYS_FLAGS -32)
endif()
else()
list(APPEND sources src/sysc/qt/md/iX86_64.s)
if(APPLE)
set(ASM_SYS_FLAGS -arch x86_64)
else()
set(ASM_SYS_FLAGS -64)
endif()
endif()
enable_language(ASM-ATT)
set(CMAKE_ASM-ATT_COMPILE_OBJECT CMAKE_ASM-ATT_COMPILER
${ASM_SYS_FLAGS} -o OBJECT SOURCE)
endif()
I'm not sure if this is the recommended way to do this though. I thought
the documentation said to override CMAKE_ASM-ATT_COMPILE_OBJECT before the
enable_language() command.
You should not have to override it.
To set flags, there are for every enabled language CMAKE_LANGUAGE_FLAGS in
the cmake cache, i.e. CMAKE_ASM-ATT_FLAGS in this case.
I tried to reproduce the problem with the attached tiny project, and I don't
get the problem you describe. This is the output:
as-test/b$ /opt/cmake-HEAD/bin/cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- The ASM-ATT compiler identification is GNU
-- Found assembler: /usr/bin/as
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alex/src/CMake/build dir/CMake-
git/Tests/Assembler/as-test/b
as-test/b$ make VERBOSE=1
...
Scanning dependencies of target hello
make[2]: Leaving directory `/home/alex/src/CMake/build dir/CMake-
git/Tests/Assembler/as-test/b'
make -f CMakeFiles/hello.dir/build.make CMakeFiles/hello.dir/build
make[2]: Entering directory `/home/alex/src/CMake/build dir/CMake-
git/Tests/Assembler/as-test/b'
/opt/cmake-HEAD/bin/cmake -E cmake_progress_report /home/alex/src/CMake/build
dir/CMake-git/Tests/Assembler/as-test/b/CMakeFiles 1
[ 50%] Building C object CMakeFiles/hello.dir/main.c.o
/usr/bin/gcc -DFOO -DBLUB=blub -DBAR=bar -I/opt/include-o
CMakeFiles/hello.dir/main.c.o -c /home/alex/src/CMake/build dir/CMake-
git/Tests/Assembler/as-test/main.c
/opt/cmake-HEAD/bin/cmake -E cmake_progress_report /home/alex/src/CMake/build
dir/CMake-git/Tests/Assembler/as-test/b/CMakeFiles 2
[100%] Building ASM-ATT object CMakeFiles/hello.dir/foo.s.o
/usr/bin/as -I/opt/include-o CMakeFiles/hello.dir/foo.s.o
/home/alex/src/CMake/build dir/CMake-git/Tests/Assembler/as-test/foo.s
Linking C executable hello
...
So, here main.c gets all the -D's, and foo.s gets the -I, but not the -D's.
Is that different for you ?
Alex
as-test.tar.gz
Description: application/compressed-tar
___
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] Include directories for C compile command
Hello Glenn and thanks, I found out yesterday the method you describe works. I was trying to use include_directories() before, but unfortunately the statement was after any add_directory() statement and it was a matter of scope (what other variable/property updates add_directory() does?). It works now, but still I'm wondering if there is a method of doing the same thing at module level (leaf CMakeLists.txt files) and propagate the updates upwards in directory hierarchy. Thanks again, Andrei On Wed, Aug 3, 2011 at 8:10 PM, Glenn Coombs glenn.coo...@gmail.com wrote: Have you tried using the include_directories() command ? In your top level CMakeLists.txt add a line like this: include_directories(SWC1 SWC2 SWC3 Common) before you do any add_subdirectory() commands. Does that not add the appropriate -Ixxx flags to the compile command ? It does for me but I'm using Visual Studio and gcc rather than an embedded compiler. On 3 August 2011 07:25, Andrei Buzgan andrei.buz...@gmail.com wrote: Hello everyone, I'm trying to set up an environment for building a pre-existing medium sized embedded software project, by using CMake 2.8 and MinGW. The compiler kit is specific for the target microcontroller and contains C compiler, assembler, linker, all different executables. I do have some restrictions: The project structure looks like this: Sources |-- SWC1 ||-- swc1.c ||-- swc1.h ||--CMakeLists.txt |-- SWC2 ||-- swc2_a.c ||-- swc2_b.c ||-- swc2.h ||--CMakeLists.txt |-- COMMON ||-- config1.h ||-- config2.h ||--CMakeLists.txt |-- UNUSED_DIR |-- SWC3 ||-- swc3.obj ||-- swc3.h - I cannot change the directory structure of the project (i can add but i must not move files around) - each SW module (component) has it own files including interface headers in it's own directory (SW component SWC1 resides in folder SWC1 and contains a source file and a header file) - SW modules may be interfaced with any other module (swc1.c may include swc2.h...) - There are common header files with project scope definitions and configurations which reside in their own directory too (both swc1.c and swc2.c may include headers config1.h and config2.h) - The SW has more variants, some variants use different C source files for a specific SW component but the sources reside in the same directory and interface headers are common for all variants. (For SW variant A the SW component SWC2 uses swc2_a.c source file, for SW variant B it uses swc2_b.c file) - Some SW components are precompiled and provided as object files together with the interface header (SWC3) *These being the conditions, i couldn't manage to gather the relevant folders in order to correctly create the build object command *where flags like -Idir_pah1 -Idir_path2 ... are expected in order to look for included headers. Due to mixed source-precompiled objects I chose to define each component as a static library (add_library(...)) in each CMakeLists.txt file and list there the used source files, being able to use conditions for SW variants and basically add different library definitions for each variant. I intend to add the pre-compiled sources as IMPORTED libraries and in the end just link the libraries with the specific linker command for linking any object files (but i didn't get there yet!) I'm currently use the default CMAKE_C_COMPILE_OBJECT command CMAKE_C_COMPILER DEFINES FLAGS -o OBJECT -c SOURCE, the compiler ignoring the unknown flags (-c in this case). *Without any explicit configuration from my part, it looks like FLAGS variable contains also a -Ipath directive for the current compiled source file* (path is the same directory where the source files about to be compiled resides). I tried to use set( CMAKE_INCLUDE_CURRENT_DIR ON ) in each CMakeLists.txt file but FLAGS variable seems not to be updated this way. I'd like to know if there is an efficient method to build an include directory list in order to pass it to compile flags. It would be very useful to make this in CMakeLists.txt file or link it somehow to add_directory(dir) and use an internal CMake mechanism trying to avoid creating this part of the compiler flags manually in order to be easily maintained in the future. Thanks, Andrei ___ 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
[Cmake-commits] CMake branch, next, updated. v2.8.5-1414-g6d765b7
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 6d765b7d49fdba2b760c3b9da8e3b771aa735655 (commit)
via f46236949e8c981703fd4b0f7b32d588c888d98d (commit)
via 14e54c4c449e2704799ab5283c6c6764472d5a0a (commit)
from a94b306697605418e0ac2a54da2ebd538c9ac72d (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=6d765b7d49fdba2b760c3b9da8e3b771aa735655
commit 6d765b7d49fdba2b760c3b9da8e3b771aa735655
Merge: a94b306 f462369
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Aug 3 10:00:20 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Aug 3 10:00:20 2011 -0400
Merge topic 'fix-12054-eliminate-findjava-noise' into next
f462369 remove extra output message from FindJava.cmake
14e54c4 KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f46236949e8c981703fd4b0f7b32d588c888d98d
commit f46236949e8c981703fd4b0f7b32d588c888d98d
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Fri Apr 8 07:56:39 2011 +0200
Commit: David Cole david.c...@kitware.com
CommitDate: Wed Aug 3 09:40:10 2011 -0400
remove extra output message from FindJava.cmake
FPHSA already prints out the version number. And this line was printed on
every subsequent CMake run.
diff --git a/Modules/FindJava.cmake b/Modules/FindJava.cmake
index 1b11a34..34a7077 100644
--- a/Modules/FindJava.cmake
+++ b/Modules/FindJava.cmake
@@ -130,11 +130,6 @@ IF(Java_JAVA_EXECUTABLE)
else( )
set(Java_VERSION
${Java_VERSION_MAJOR}.${Java_VERSION_MINOR}.${Java_VERSION_PATCH}.${Java_VERSION_TWEAK})
endif( )
- # display info
- #MESSAGE( STATUS Java version ${Java_VERSION_STRING} configured
successfully! ) # keep me, used for debug
- IF(NOT Java_FIND_QUIETLY)
-MESSAGE( STATUS Java version ${Java_VERSION} configured
successfully! )
- ENDIF(NOT Java_FIND_QUIETLY)
ENDIF()
ENDIF(Java_JAVA_EXECUTABLE)
---
Summary of changes:
Modules/FindJava.cmake|5 -
Source/kwsys/kwsysDateStamp.cmake |2 +-
2 files changed, 1 insertions(+), 6 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.5-1420-g09c6832
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 09c68325ec9d68c4c4de366d524dba0dd027a742 (commit) via 74e1156bc292f45dd376d6324fbf13aa2de539b7 (commit) from 1e6de14cda9a14dedfcaeb05d399e39f7b3e59e7 (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=09c68325ec9d68c4c4de366d524dba0dd027a742 commit 09c68325ec9d68c4c4de366d524dba0dd027a742 Merge: 1e6de14 74e1156 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Aug 3 14:50:31 2011 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Aug 3 14:50:31 2011 -0400 Merge branch 'master' into next --- Summary of changes: Source/kwsys/SystemTools.cxx| 73 -- Source/kwsys/SystemTools.hxx.in |8 + 2 files changed, 17 insertions(+), 64 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.5-1423-g68f4277
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 68f42779d377e5e6a11c386d12c0de20ce904777 (commit)
via 6899e58fa0d819638aa5de1408721b718d3299b8 (commit)
via fe6bb7af2aef536d29593f1da8ae4dd19b195e88 (commit)
from 09c68325ec9d68c4c4de366d524dba0dd027a742 (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=68f42779d377e5e6a11c386d12c0de20ce904777
commit 68f42779d377e5e6a11c386d12c0de20ce904777
Merge: 09c6832 6899e58
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Wed Aug 3 16:36:25 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Aug 3 16:36:25 2011 -0400
Merge topic 'FindX11ImprovementsFromKDE' into next
6899e58 Also search for libxkbfile, XSync and SM include dir
fe6bb7a Remove trailing whitespace
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6899e58fa0d819638aa5de1408721b718d3299b8
commit 6899e58fa0d819638aa5de1408721b718d3299b8
Author: Alex Neundorf neund...@kde.org
AuthorDate: Wed Aug 3 22:33:18 2011 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Wed Aug 3 22:33:18 2011 +0200
Also search for libxkbfile, XSync and SM include dir
Alex
diff --git a/Modules/FindX11.cmake b/Modules/FindX11.cmake
index 29f2be5..9df3f01 100644
--- a/Modules/FindX11.cmake
+++ b/Modules/FindX11.cmake
@@ -6,6 +6,7 @@
#
# and also the following more fine grained variables:
# Include paths: X11_ICE_INCLUDE_PATH, X11_ICE_LIB,
X11_ICE_FOUND
+#X11_SM_INCLUDE_PATH, X11_SM_LIB,
X11_SM_FOUND
#X11_X11_INCLUDE_PATH, X11_X11_LIB
#X11_Xaccessrules_INCLUDE_PATH,
X11_Xaccess_FOUND
#X11_Xaccessstr_INCLUDE_PATH,
X11_Xaccess_FOUND
@@ -27,6 +28,7 @@
#X11_Xinput_INCLUDE_PATH, X11_Xinput_LIB,
X11_Xinput_FOUND
#X11_Xkb_INCLUDE_PATH,
X11_Xkb_FOUND
#X11_Xkblib_INCLUDE_PATH,
X11_Xkb_FOUND
+#X11_Xkbfile_INCLUDE_PATH, X11_Xkbfile_LIB,
X11_Xkbfile_FOUND
#X11_Xpm_INCLUDE_PATH, X11_Xpm_LIB,
X11_Xpm_FOUND
#X11_XTest_INCLUDE_PATH,X11_XTest_LIB,
X11_XTest_FOUND
#X11_Xrandr_INCLUDE_PATH, X11_Xrandr_LIB,
X11_Xrandr_FOUND
@@ -35,6 +37,8 @@
#X11_Xt_INCLUDE_PATH, X11_Xt_LIB,
X11_Xt_FOUND
#X11_Xutil_INCLUDE_PATH,
X11_Xutil_FOUND
#X11_Xv_INCLUDE_PATH, X11_Xv_LIB,
X11_Xv_FOUND
+#X11_XSync_INCLUDE_PATH,(in X11_Xext_LIB),
X11_XSync_FOUND
+
#=
# Copyright 2001-2009 Kitware, Inc.
@@ -80,6 +84,7 @@ IF (UNIX)
# Solaris lacks XKBrules.h, so we should skip kxkbd there.
FIND_PATH(X11_ICE_INCLUDE_PATH X11/ICE/ICE.h
${X11_INC_SEARCH_PATH})
+ FIND_PATH(X11_SM_INCLUDE_PATH X11/SM/SM.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xaccessrules_INCLUDE_PATH X11/extensions/XKBrules.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xaccessstr_INCLUDE_PATH X11/extensions/XKBstr.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xau_INCLUDE_PATH X11/Xauth.h
${X11_INC_SEARCH_PATH})
@@ -97,6 +102,7 @@ IF (UNIX)
FIND_PATH(X11_Xinput_INCLUDE_PATH X11/extensions/XInput.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xkb_INCLUDE_PATH X11/extensions/XKB.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xkblib_INCLUDE_PATH X11/XKBlib.h
${X11_INC_SEARCH_PATH})
+ FIND_PATH(X11_Xkbfile_INCLUDE_PATH X11/extensions/XKBfile.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xpm_INCLUDE_PATH X11/xpm.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_XTest_INCLUDE_PATH X11/extensions/XTest.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_XShm_INCLUDE_PATH X11/extensions/XShm.h
${X11_INC_SEARCH_PATH})
@@ -107,6 +113,7 @@ IF (UNIX)
FIND_PATH(X11_Xutil_INCLUDE_PATH X11/Xutil.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xt_INCLUDE_PATH X11/Intrinsic.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xv_INCLUDE_PATH X11/extensions/Xvlib.h
${X11_INC_SEARCH_PATH})
+ FIND_PATH(X11_XSync_INCLUDE_PATH X11/extensions/sync.h
${X11_INC_SEARCH_PATH})
FIND_LIBRARY(X11_X11_LIB X11
[Cmake-commits] CMake branch, next, updated. v2.8.5-1425-g37f7336
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 37f733655d38bae199003a9b7f7d70d5ea69162b (commit)
via 3c53fbb1f0d7276d0ef1f07facb2a1d937fc5153 (commit)
from 68f42779d377e5e6a11c386d12c0de20ce904777 (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=37f733655d38bae199003a9b7f7d70d5ea69162b
commit 37f733655d38bae199003a9b7f7d70d5ea69162b
Merge: 68f4277 3c53fbb
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Wed Aug 3 17:34:53 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Aug 3 17:34:53 2011 -0400
Merge topic 'intel_fortran_vs2010' into next
3c53fbb Fix custom commands in VS2010 Fortran projects using CFG_INTDIR and
test.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c53fbb1f0d7276d0ef1f07facb2a1d937fc5153
commit 3c53fbb1f0d7276d0ef1f07facb2a1d937fc5153
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Wed Aug 3 17:24:43 2011 -0400
Commit: Bill Hoffman bill.hoff...@kitware.com
CommitDate: Wed Aug 3 17:24:43 2011 -0400
Fix custom commands in VS2010 Fortran projects using CFG_INTDIR and test.
For custom commands in VS2010 Fortran projects the INTDIR variable
is different than in the rest of the solution because Intel
fortran still uses the old VS project files even in VS2010. So,
we replace $(Configuration) directly in the project files. I have also
added a FortranOnly test that tests this feature and is run on any
generator that has Fortran abilities.
diff --git a/Source/cmLocalVisualStudio7Generator.cxx
b/Source/cmLocalVisualStudio7Generator.cxx
index 7a62b9c..d254164 100644
--- a/Source/cmLocalVisualStudio7Generator.cxx
+++ b/Source/cmLocalVisualStudio7Generator.cxx
@@ -1622,6 +1622,10 @@ WriteCustomRule(std::ostream fout,
}
std::string script = this-ConstructScript(command, i-c_str());
+if(this-FortranProject)
+ {
+ cmSystemTools::ReplaceString(script, $(Configuration), i-c_str());
+ }
fout \t\t\t\t\tTool\n
\t\t\t\t\tName=\ customTool \\n
\t\t\t\t\tDescription=\
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx
b/Source/cmVisualStudio10TargetGenerator.cxx
index d710405..183399f 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -1563,6 +1563,13 @@ void
cmVisualStudio10TargetGenerator::WriteProjectReferences()
i != depends.end(); ++i)
{
cmTarget* dt = *i;
+// skip fortran targets as they can not be processed by MSBuild
+// the only reference will be in the .sln file
+if(static_castcmGlobalVisualStudioGenerator*(this-GlobalGenerator)
+ -TargetIsFortranOnly(*dt))
+ {
+ continue;
+ }
this-WriteString(ProjectReference Include=\, 2);
cmMakefile* mf = dt-GetMakefile();
std::string name = dt-GetName();
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 2ad9a77..da4eda0 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -16,6 +16,8 @@ MACRO(ADD_TEST_MACRO NAME COMMAND)
LIST(APPEND TEST_BUILD_DIRS ${CMake_BINARY_DIR}/Tests/${dir})
ENDMACRO(ADD_TEST_MACRO)
+INCLUDE(${CMAKE_CURRENT_SOURCE_DIR}/CheckFortran.cmake)
+
# Fake a user home directory to avoid polluting the real one.
IF(DEFINED ENV{HOME} AND NOT CTEST_NO_TEST_HOME)
SET(TEST_HOME ${CMake_BINARY_DIR}/Tests/CMakeFiles/TestHome)
@@ -155,6 +157,9 @@ IF(BUILD_TESTING)
ADD_TEST_MACRO(MissingSourceFile MissingSourceFile)
SET_TESTS_PROPERTIES(MissingSourceFile PROPERTIES
PASS_REGULAR_EXPRESSION CMake Error at CMakeLists.txt:3
\\(add_executable\\):[ \r\n]*Cannot find source file:[
\r\n]*DoesNotExist/MissingSourceFile.c)
+ IF(CMAKE_Fortran_COMPILER)
+ADD_TEST_MACRO(FortranOnly FortranOnly)
+ ENDIF()
ADD_TEST_MACRO(COnly COnly)
ADD_TEST_MACRO(CxxOnly CxxOnly)
ADD_TEST_MACRO(IPO COnly/COnly)
@@ -1879,7 +1884,6 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
${CMake_SOURCE_DIR}/Utilities/
# fortran does not work for IDE builds because
# CMAKE_STANDARD_LIBRARIES needs to be per language
IF(CMAKE_TEST_GENERATOR MATCHES Make|KDevelop)
-INCLUDE(${CMAKE_CURRENT_SOURCE_DIR}/CheckFortran.cmake)
IF(CMAKE_Fortran_COMPILER)
ADD_TEST(Fortran ${CMAKE_CTEST_COMMAND}
--build-and-test
diff --git a/Tests/FortranOnly/CMakeLists.txt b/Tests/FortranOnly/CMakeLists.txt
new file mode 100644
index 000..3c4f0e7
--- /dev/null
+++ b/Tests/FortranOnly/CMakeLists.txt
@@ -0,0 +1,42 @@
+cmake_minimum_required (VERSION 2.8)
+project(FortranOnly Fortran)
+message(CTEST_FULL_OUTPUT
[Cmake-commits] CMake branch, next, updated. v2.8.5-1427-g5b33b48
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 5b33b48429b24279150e35e6ce2a632616b46ad8 (commit)
via 91704ef2dee3ad606a6cc0f1e03e6f254d211b8f (commit)
from 37f733655d38bae199003a9b7f7d70d5ea69162b (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=5b33b48429b24279150e35e6ce2a632616b46ad8
commit 5b33b48429b24279150e35e6ce2a632616b46ad8
Merge: 37f7336 91704ef
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Aug 3 21:43:20 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Aug 3 21:43:20 2011 -0400
Merge topic 'add-kwstyle-test' into next
91704ef Tests: Add a KWStyle test, equivalent to the make StyleCheck target
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=91704ef2dee3ad606a6cc0f1e03e6f254d211b8f
commit 91704ef2dee3ad606a6cc0f1e03e6f254d211b8f
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Aug 3 21:37:01 2011 -0400
Commit: David Cole david.c...@kitware.com
CommitDate: Wed Aug 3 21:37:01 2011 -0400
Tests: Add a KWStyle test, equivalent to the make StyleCheck target
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 4bf83b7..ee38fd0 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -2073,6 +2073,19 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
${CMake_SOURCE_DIR}/Utilities/
--test-command IncludeDirectories)
LIST(APPEND TEST_BUILD_DIRS ${CMake_BINARY_DIR}/Tests/IncludeDirectories)
+ IF(CMAKE_USE_KWSTYLE AND KWSTYLE_EXECUTABLE)
+# The make StyleCheck command line as a test. If the test fails, look
+# for lines like Error #0 (624) Line length exceed 88 (max=79) in the
+# output to find where the style errors are...
+ADD_TEST(KWStyle ${KWSTYLE_EXECUTABLE}
+ -xml ${CMake_BINARY_DIR}/CMake.kws.xml
+ -o ${CMake_SOURCE_DIR}/Utilities/KWStyle/CMakeOverwrite.txt
+ -v
+ -D ${CMake_BINARY_DIR}/CMakeKWSFiles.txt
+ )
+SET_TESTS_PROPERTIES(KWStyle PROPERTIES
+ WORKING_DIRECTORY ${CMake_BINARY_DIR}/Utilities/KWStyle)
+ ENDIF()
ENDIF(BUILD_TESTING)
SUBDIRS(CMakeTests)
---
Summary of changes:
Tests/CMakeLists.txt | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
