[cmake-developers] [CMake 0012385]: Dependencies of check_*_source_compiles are not tracked

2011-08-03 Thread Mantis Bug Tracker

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

2011-08-03 Thread Brad King

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 ?

2011-08-03 Thread Alexander Neundorf
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] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?

2011-08-03 Thread Brad King

On 8/3/2011 4:00 PM, Alexander Neundorf wrote:

Are you ok with this branch or are there issues left (...since it wasn't
merged into master on Tuesday) ?


I still need to find time to do further review and try it out.

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

2011-08-03 Thread Brad King

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

2011-08-03 Thread Mantis Bug Tracker

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

2011-08-03 Thread Andrei Buzgan
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-08-03 Thread Eric Noulard
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

2011-08-03 Thread Michael Wild
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

2011-08-03 Thread Clinton Stimpson
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 ?

2011-08-03 Thread Alexander Neundorf
On Tuesday 02 August 2011, Hendrik Sattler wrote:
 Am Dienstag, 2. August 2011, 21:55:16 schrieb Alexander Neundorf:
  Hi,
  
  until recently, I recommended to install Config.cmake files more or less
  like this:
  
  install(FILES FooConfig.cmake DESTINATION lib${LIB_SUFFIX}/cmake/Foo )
  
  with LIB_SUFFIX being 64 on systems where this is required.
  
  How do I do this on a Debian multiarch system ?
  How do I know in which directory I should install ?
 
 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.

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] How to installing cmake Config.cmake files under Debian multiarch ?

2011-08-03 Thread Brad King

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

2011-08-03 Thread Glenn Coombs
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

2011-08-03 Thread Glenn Coombs
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] How to installing cmake Config.cmake files under Debian multiarch ?

2011-08-03 Thread Brad King

On 8/3/2011 1:19 PM, Alexander Neundorf wrote:

Is there already a variable which contains the multiarch triplet, so I can do
something like lib/${CMAKE_MULTIARCH_TRIPLET}/... ?


Yes, CMAKE_LIBRARY_ARCHITECTURE.  It contains no slashes and is empty
if there is no architecture choice.


Slightly different question: if a Config.cmake file is installed on a
multiarch debian system, will it also be found if installed in lib/ or lib64/
(i.e. without the multiarch triplet) ?


Yes.


How can lib/cmake/Foo/FooConfig.cmake know where the include dir is ?


If someone uses absolute install locations he/she better use the installed
package only from those locations.  The packager that creates a binary
installer better use relative locations.  This is no different than it
was before multiarch or GNUInstallDirs.


We didn't see a way how to do this, so we decided those directories should not
be in the cache, so we can be sure they are never absolute.


if(IS_ABSOLUTE ${CMAKE_INSTALL_LIBDIR})
  message(FATAL_ERROR We do not support this.)
endif()

-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

2011-08-03 Thread Alexander Neundorf
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

2011-08-03 Thread Andrei Buzgan
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

2011-08-03 Thread David Cole
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

2011-08-03 Thread Brad King
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

2011-08-03 Thread Alexander Neundorf
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

2011-08-03 Thread Bill Hoffman
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

2011-08-03 Thread David Cole
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