[cmake-developers] [CMake 0012355]: add a cpack_add_shortcut function in cpack

2011-07-22 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=12355 
== 
Reported By:ycollet
Assigned To:
== 
Project:CMake
Issue ID:   12355
Category:   CPack
Reproducibility:N/A
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2011-07-22 04:21 EDT
Last Modified:  2011-07-22 04:21 EDT
== 
Summary:add a cpack_add_shortcut function in cpack
Description: 
add a cpack_add_shortcut(COMPONENT
 WHERE
 ICONPATH
 [SUBDIRPATH]) function to create shortcuts

Where:
- COMPONENT is the component name
- WHERE can be STARTUP or DESKTOP
- ICONPATH is the path to the ICON
- SUBDIRPATH is optional and only used with STARTUP: the subdir where the link
will be installed

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-07-22 04:21 ycolletNew Issue
==

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[cmake-developers] [CMake 0012356]: add an optional version check before installing a component via NSIS

2011-07-22 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=12356 
== 
Reported By:ycollet
Assigned To:
== 
Project:CMake
Issue ID:   12356
Category:   CPack
Reproducibility:N/A
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2011-07-22 05:14 EDT
Last Modified:  2011-07-22 05:14 EDT
== 
Summary:add an optional version check before installing a
component via NSIS
Description: 

add an optional version check before installing a component via NSIS:

This can be down via a new option VERSION:

cpack_add_component(compname
[DISPLAY_NAME name]
[DESCRIPTION description]
[HIDDEN | REQUIRED | DISABLED ]
[GROUP group]
[DEPENDS comp1 comp2 ... ]
[INSTALL_TYPES type1 type2 ... ]
[DOWNLOADED]
[VERSION maj min rev] **
[ARCHIVE_FILE filename])

If VERSION is present, then a registry key will be added with name [DISPLAY
NAME] and with a version Key.
If VERSION is not present, the registry key will not be added.

And via adding a new cpack variable:

CPACK_NSIS_CHECK_VERSION_BEFORE_INSTALL ON / OFF

If this variable is at ON, and if the VERSION option is present, then we check
the installed registry key and the application is installed if:
- the registry key is present and maj = maj_installed min = min_installed rev
 rev_installed


== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-07-22 05:14 ycolletNew Issue
==

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [CMake] [CPack] post install scripts

2011-07-22 Thread Domagoj Saric

On 21.7.2011. 13:49, David Cole wrote:

Apologies for nagging but Google searches about CMake, CPack and symlinks
show that is not a rare problem/question..is there no comment/help on this
from the CMake devs?


Just busy, that's all...


Ok, sorry...It just seemed to me that nobody cared about this considering that 
the list does otherwise have noticeable traffic...




install(CODE) and install(SCRIPT) code is run at make install time. By
default, CPack does a make install to an intermediate location in the build
tree (underneath _CPack_Packages in your build tree) as part of building the
final installer.


So basically install( CODE/SCRIPT ) have any influence on the CPack generated 
installer only if they alter the contents of the directories and/or files that 
go into the installer (as specified by other install() CMake commands)?




I don't know about the CPack post script stuff, or the OS X version differences
you're talking about. I'll have to investigate / take a look later, but not sure
I'll have the time for it this week. If you can give me easy-to-reproduce steps,
that might help.


As far as the CPack post install scripts go, this is easy to reproduce:
a)
 set( CPACK_POSTFLIGHT_SCRIPT myscript.sh )
 set( CPACK_OSX_PACKAGE_VERSION 10.5 )
b)
 set( CPACK_POSTFLIGHT_SCRIPT myscript.sh )

For (a) the script does not get included in the installer at all, for (b) it 
does get included but it does not get executed.


You can also easily see why this is so if you fire up PackageMaker, create a 
dummy project and then in the installer properties change the minimum target 
version to 10.5 and then notice how for all components all pre/postflight script 
options have gone and only preinstall and postinstall are left...


It is also not specified in the documentation (or I did not find it) does/should 
CPack automatically include/copy myscript.sh into the installer/package 
(whatever the generator used) or does it simply make a 'reference' of some sort 
and the user must somehow manually ensure that the script (the actual file) gets 
included in the installer?


These post install script problems however are secondary for me, as my main 
problem (that I tried to solve with scripts) is how to create symlinks with 
CPack. If there is any other way that works I would be more than grateful if 
someone could share it with me ;)


In this specific case of mine relative symlinks would work good enough, and 
those I can generate manually or at CMake time so if there could be a way to add 
symlinks as symlinks (not as actual files they point to) to the CPack installer 
this specific problem of mine would probably be solved.



In any case, the need for proper portable post install scripting and symlinks 
support in CPack is definitely needed. AFAICT, CMake still supports symlinks 
only on *NIXes while they also exist on Windows since Win2k times...



Thanks in advance ;)


--
What Huxley teaches is that in the age of advanced technology, spiritual
devastation is more likely to come from an enemy with a smiling face than
from one whose countenance exudes suspicion and hate.
Neil Postman
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


[CMake] EXECUTABLE_OUTPUT_PATH vs RUNTIME_OUTPUT_DIRECTORY

2011-07-22 Thread pellegrini

Hello everybody,

I use CMake 2.8.4, Fortran 90 and Intel compiler to build an executable. 
I read in the documentation that

RUNTIME_OUTPUT_DIRECTORY supercedes the old EXECUTABLE_OUTPUT_PATH command.

When using:

   add_executable(myexec ${source_files})
   set(EXECUTABLE_OUTPUT_PATH mydir)

I can find my executable in mydir but when using

   add_executable(myexec ${source_files})
   set(RUNTIME_OUTPUT_DIRECTORY mydir)

nothing appears in mydir. Did I miss something when reading the doc ?

I would have an additional question concerning both commands. Anytime I 
build my project the following files are created alongside my executable:


   - myexec.exe.embed.manifest
   - myexec.exe.embed.manifest.res
   - myexec.exe.intermediate.manifest
   - myexec.exe.resource.txt
   - myexec.ilk

is there a way to get rid of these files ?

thanks a lot

Eric


--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France

___
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] EXECUTABLE_OUTPUT_PATH vs RUNTIME_OUTPUT_DIRECTORY

2011-07-22 Thread Michael Wild
On 07/22/2011 03:46 PM, pellegrini wrote:
 Hello everybody,
 
 I use CMake 2.8.4, Fortran 90 and Intel compiler to build an executable.
 I read in the documentation that
 RUNTIME_OUTPUT_DIRECTORY supercedes the old EXECUTABLE_OUTPUT_PATH command.
 
 When using:
 
add_executable(myexec ${source_files})
set(EXECUTABLE_OUTPUT_PATH mydir)
 
 I can find my executable in mydir but when using
 
add_executable(myexec ${source_files})
set(RUNTIME_OUTPUT_DIRECTORY mydir)
 
 nothing appears in mydir. Did I miss something when reading the doc ?
 
 I would have an additional question concerning both commands. Anytime I
 build my project the following files are created alongside my executable:
 
- myexec.exe.embed.manifest
- myexec.exe.embed.manifest.res
- myexec.exe.intermediate.manifest
- myexec.exe.resource.txt
- myexec.ilk
 
 is there a way to get rid of these files ?
 
 thanks a lot
 
 Eric
 
 

RUNTIME_OUTPUT_DIRECTORY is a *property*, not a variable. If you want to
set a variable, use CMAKE_RUNTIME_OUTPUT_DIRECTORY.

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] EXECUTABLE_OUTPUT_PATH vs RUNTIME_OUTPUT_DIRECTORY

2011-07-22 Thread pellegrini

Michael Wild a écrit :

On 07/22/2011 03:46 PM, pellegrini wrote:
  

Hello everybody,

I use CMake 2.8.4, Fortran 90 and Intel compiler to build an executable.
I read in the documentation that
RUNTIME_OUTPUT_DIRECTORY supercedes the old EXECUTABLE_OUTPUT_PATH command.

When using:

   add_executable(myexec ${source_files})
   set(EXECUTABLE_OUTPUT_PATH mydir)

I can find my executable in mydir but when using

   add_executable(myexec ${source_files})
   set(RUNTIME_OUTPUT_DIRECTORY mydir)

nothing appears in mydir. Did I miss something when reading the doc ?

I would have an additional question concerning both commands. Anytime I
build my project the following files are created alongside my executable:

   - myexec.exe.embed.manifest
   - myexec.exe.embed.manifest.res
   - myexec.exe.intermediate.manifest
   - myexec.exe.resource.txt
   - myexec.ilk

is there a way to get rid of these files ?

thanks a lot

Eric





RUNTIME_OUTPUT_DIRECTORY is a *property*, not a variable. If you want to
set a variable, use CMAKE_RUNTIME_OUTPUT_DIRECTORY.

HTH

  

Oups ! sorry.

Thanks for the hints Michael. That's OK, my executable is now created in 
the selected directory. Unfortunately, it does not come alone, there are 
still those manifest and ilk files ...




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
  



--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France

___
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] Build the dependencies tree of an executable

2011-07-22 Thread Yuri Timenkov
Hi Marco,

I think target_link_libraries and add_dependencies are not applicable to
 imported targets. You should set IMPORTED_LINK_INTERFACE_LIBRARIES property
instead. I don't remember exactly, but I solved similar problem.

You can also try creating sample project with dependent static libraries
(you even don't need to compile it), and then export dependencies with
export(TARGETS) commands, and see what code CMake will generate.

Best wishes,
Yuri

On Mon, Jul 18, 2011 at 8:54 PM, Marco Corvo marco.co...@pd.infn.it wrote:

 Hi all,

 I'm facing the following problem trying to generate the dependencies tree
 of an executable. I have a working area

 /path/to/my/working/area/**MyPackage

 with, say, one executable I want to build. The relevant CMakeLists.txt line
 is something like:

 add_executable(App src/App.cc)
 target_link_libraries(App A B C D)

 now these libs (A B C D) are already installed somewhere and they depend on
 other libraries of my software release. Say they're under

 /path/to/sw/release/X.Y.Z/lib/**arch/libA.a
 /path/to/sw/release/X.Y.Z/lib/**arch/libB.a
 /path/to/sw/release/X.Y.Z/lib/**arch/libC.a
 /path/to/sw/release/X.Y.Z/lib/**arch/libD.a
 /path/to/sw/release/X.Y.Z/lib/**arch/libE.a

 ...

 and that A depends on D, E and F. When I run my build, cmake only finds
 that my App has A, B, C and D as dependencies, while actually these
 libraries have also their own dependencies.

 I tried to add a .cmake file to each package in the release area

 /path/to/sw/release/X.Y.Z/**packageA/Deps.cmake
 /path/to/sw/release/X.Y.Z/**packageB/Deps.cmake
 /path/to/sw/release/X.Y.Z/**packageD/Deps.cmake

 with

 add_library(A STATIC IMPORTED)
 add_dependencies(A D E F...)

 which is includeed with my CmakeLists.txt file in order to let cmake know
 that when I build App it depends on A, B, C D _and_ A itself depends in his
 turn on D, E and F. This should create a complete dependencies tree for my
 App.

 I know that add_dependencies gives Adding dependency to non-existent
 target with cmake version before 2.8.4 if the target is IMPORTED while with
 2.8.4/5 on a Scientific Linux 5 I'm getting a seg fault with the add_dep
 directive.

 Is this nevertheless the way to solve this problem? Are there other ways to
 build the dependencies tree of an executable which depends directly on some
 libs and indirectly on some other ones? Consider that I build static
 libraries, so I need to have the full list of libraries when linking the
 executable.

 Thanks in advance for your help.

 Cheers

 Marco

 --
 Marco Corvo
 SuperB experiment
 CNRS - Orsay
 c/o INFN - Padova
 __**_
 Powered by www.kitware.com

 Visit other Kitware open-source projects at http://www.kitware.com/**
 opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/**listinfo/cmakehttp://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

[CMake] VS2010 and superbuild - Fwd: [Ctk-developers] VS2010 support

2011-07-22 Thread Jean-Christophe Fillion-Robin
Hi Folks,

Before digging further into the problem ... if some your experience issue
with VS2010 and superbuild .. would be great if you could provide more
details about your investigation.

Thanks
Jc

-- Forwarded message --
From: Sascha Zelzer s.zel...@dkfz-heidelberg.de
Date: Fri, Jul 22, 2011 at 12:07 PM
Subject: Re: [Ctk-developers] VS2010 support
To: ctk-develop...@commontk.org


Hi,

there is something very strange going on. The generated VS 2010 projects (I
am using the Express editions, 32bit) for the external dependencies like
DCMTK, Log4Qt, etc. only call the download step of the ExternalProject_add
call in our superbuild scripts. The projects are not configured and build.

Did anybody experience the same? I tried with and without the VS 2010 SP1
and with CMake 2.8.4 and 2.8.5.

Thanks,
Sascha


On 07/22/2011 01:39 PM, Sascha Zelzer wrote:

 Hi Folks,

 I would like to get Visual Studio 2010 compatibility for CTK.

 Currently, it looks like I will have to copy ExternalProject.cmake to
 CTK for the CMAKE_CACHE_ARGS argument. Then a couple of small
 modifications should do.

 Any other ideas or objections?

 Thanks,

 Sascha
 __**_
 Ctk-developers mailing list
 ctk-develop...@commontk.org
 http://public.kitware.com/cgi-**bin/mailman/listinfo/ctk-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers


__**_
Ctk-developers mailing list
ctk-develop...@commontk.org
http://public.kitware.com/cgi-**bin/mailman/listinfo/ctk-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers



-- 
+1 919 869 8849
___
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] Appending to the LINK_FLAGS target property ?

2011-07-22 Thread Johan Björk
Glenn,

An option APPEND_STRING was added, see
http://public.kitware.com/Bug/view.php?id=12342

/Johan


On Mon, Jun 27, 2011 at 4:47 PM, Glenn Coombs glenn.coo...@gmail.com wrote:
 For variables like CMAKE_C_FLAGS one can append to them like this:

     set(CMAKE_C_FLAGS ${CMAKE_CFLAGS} -some_option)

 For target properties like LINK_FLAGS I was using this command:

     set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
 /NODEFAULTLIB:LIBCMT)

 to do the append.  However, when I append a second time:

     set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
 /INCLUDE:_InitLibrary)

 then it breaks because the string that Visual Studio sees contains a
 semicolon in between the 2 options.  I can work round this by writing my
 append like this:

     get_property(link_flags TARGET myDLL PROPERTY LINK_FLAGS)
     set(link_flags ${link_flags} /INCLUDE:_InitLibrary)
     set_target_properties(myDLL PROPERTIES LINK_FLAGS ${link_flags})

 but that is a bit verbose for my liking.  I understand that the semicolons
 are how cmake separates list items from one another but shouldn't cmake
 automatically stringify the list (by replacing semicolons with spaces)
 before passing it through to the generator code ?  The same problem will
 occur for any of the XXX_FLAGS properties like COMPILE_FLAGS that are passed
 through unchanged to the makefile or Visual Studio project file.

 Is it worth filing a feature request to ask for cmake to stringify lists for
 the appropriate variables ?  Or is there a good reason why cmake can't or
 shouldn't implement this behaviour ?

 --
 Glenn


 ___
 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 pass a -spec parameter to FindQt4.cmake?

2011-07-22 Thread Clinton Stimpson
On Thursday, July 21, 2011 11:48:04 pm Daniel Näslund wrote:
 On Thu, Jul 21, 2011 at 7:00 PM,  clin...@elemtech.com wrote:
  Managed to compile and link when I added the following snippet to the
  toolchain file:
  
  set(QT_HEADERS_DIR /opt/env/lenny-ppc/usr/lib)
  set(QT_LIBRARY_DIR /opt/env/lenny-ppc/usr/include/qt4)
  
  set(QT_QTCORE_LIBRARY /opt/env/lenny-ppc/usr/lib/libQtCore.so)
  set(QT_QTCORE_LIBRARY_RELEASE
  /opt/env/lenny-ppc/usr/lib/libQtCore.so)
  set(QT_QTCORE_INCLUDE_DIR /opt/env/lenny-ppc/usr/include/qt4)
  
  set(QT_QTDBUS_LIBRARY /opt/env/lenny-ppc/usr/lib/libQtDBus.so)
  set(QT_QTDBUS_LIBRARY_RELEASE
  /opt/env/lenny-ppc/usr/lib/libQtDBus.so)
  set(QT_QTDBUS_INCLUDE_DIR /opt/env/lenny-ppc/usr/include/qt4)
  
  set(QT_QTXML_LIBRARY /opt/env/lenny-ppc/usr/lib/libQtXml.so)
  set(QT_QTXML_LIBRARY_RELEASE
  /opt/env/lenny-ppc/usr/lib/libQtXml.so)
  set(QT_QTXML_INCLUDE_DIR /opt/env/lenny-ppc/usr/include/qt4)
  
  Would have been nice if I didn't have to set those paths explicitely.
  Will continue the digging.
  
  Does it work if you only specify just this:
 set(QT_HEADERS_DIR /opt/env/lenny-ppc/usr/include/qt4)
 set(QT_QTCORE_LIBRARY_RELEASE
   /opt/env/lenny-ppc/usr/lib/libQtCore.so)
 
 Unfortunately no. I get:
 
 Warning: QT_QMAKE_EXECUTABLE reported QT_INSTALL_LIBS as /usr/lib
 Warning: But QtCore couldn't be found.  Qt must NOT be installed
 correctly, or it wasn't found for cross compiling.
 CMake Error at /usr/share/cmake-2.8/Modules/FindQt4.cmake:642
 (MESSAGE): Could NOT find QtCore.  Check
 /tmp/tmpMm5uhv/CMakeFiles/CMakeError.log for more details.

Ok then perhaps you'll need a newer cmake for it to work.
I looked again and it should actually be as simple as:
set(QT_QTCORE_INCLUDE_DIR /opt/env/lenny-ppc/usr/include/qt4)
set(QT_QTCORE_LIBRARY_RELEASE /opt/env/lenny-ppc/usr/lib/libQtCore.so)
and the others should be found based on that.

 
  And I would have thought it can find QtCore if /opt/env/lenny-ppc/usr
  was given as a find root.  No?
 
 Adding /opt/env/lenny-ppc/usr causes Pkg-config to choke:
 
 -- checking for module 'ecco-sqlite-1.12'
 /opt/env/lenny-ppc/usr/bin/pkg-config: 1: Syntax error: ( unexpected
 --   package 'ecco-sqlite-1.12' not found
 CMake Error at
 /usr/share/cmake-2.8/Modules/FindPkgConfig.cmake:266 (message):
   A required package was not found
 Call Stack (most recent call first):
   /usr/share/cmake-2.8/Modules/FindPkgConfig.cmake:320
 (_pkg_check_modules_internal)
   CMakeLists.txt:51 (pkg_check_modules)
 
 This happens for each of the libraries we're trying to detect with
 PkgConfig.

Ok, then it looks like the PkgConfig stuff needs fixed as well.

 
 Adding /opt/env/lenny-ppc/usr/share/qt4 to CMAKE_FIND_ROOT_PATH gives:
 
 -- Found Qt-Version 4.6.3 (using /usr/bin/qmake)
 CMake Error: The following variables are used in this project, but
 they are set to NOTFOUND.
 Please set them or make sure they are set and tested correctly in the
 CMake files:
 QT_QTCORE_INCLUDE_DIR (ADVANCED)
used as include directory in directory /home/dannas/bigsister_775
 
 Trying to prefix the PATH enviroment variable with
 /opt/env/lenny-ppc/usr/share/qt4 gives the same result.

Ok, I think the following will fix that by automatically finding the headers if 
Qt was configured with -headerdir include/qt4

--- a/Modules/FindQt4.cmake
+++ b/Modules/FindQt4.cmake
@@ -620,7 +620,7 @@ IF (QT_QMAKE_EXECUTABLE AND QTVERSION)
   SET(QT_QTCORE_INCLUDE_DIR NOTFOUND)
   FIND_PATH(QT_QTCORE_INCLUDE_DIR QtCore
 HINTS ${qt_headers} ${QT_LIBRARY_DIR}
-PATH_SUFFIXES QtCore
+PATH_SUFFIXES QtCore qt4/QtCore
 )

With that patch, and you adding /opt/env/lenny-ppc/usr to 
CMAKE_FIND_ROOT_PATH, then Qt will be found without you helping it (that is if 
the PkgConfig thing gets fixed too).

-- 
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] Assembler handling in 2.8.5 vs 2.8.4

2011-07-22 Thread Alexander Neundorf
On Thursday 21 July 2011, Florian Reinhard wrote:
 Hi Alex,
 
 Thank you for the quick response,
 
 2011/7/20 Alexander Neundorf a.neundorf-w...@gmx.net:
  Damn, I was so sure I updated the wiki, but apparently I didn't.
  So here are the old docs, but this changed quite a bit for 2.8.5:
  http://www.vtk.org/Wiki/CMake/Assembler
  
  What it does now:
  the language ASM is now for assembler files which can be processed by
  your C compiler. This actually seems to be the case for you.
  Is the compiler ID of your compiler recognized by cmake ?
 
 I guess not, since i define the compiler and how it is being called my
 self there is/was no need to have cmake detect the compiler ID.
 
  It seems like it isn't.
  If it was, the assembler support would not try to figure out the
  compiler ID for the assembler again, it would just use the compiler ID
  from C or CXX.
  
  Can you please post the complete cmake output from some basic C project ?
 
 Sure, hope to get this done by Friday afternoon CEST.
 
  Basically, what we should do, add support for your compiler toolchain,
  i.e. add support for recognizing your compiler, and create files in
  Modules/Compiler/TMS-C|CXX|ASM.cmake.
 
 Having cl6x support included in CMake would be really nice, besides
 that knowing how to setup a toolchain easily would be good either ;)
 
  This doesn't require recompiling cmake, it is all in the modules files.
  Then it should all work much better.
  
  How do you compiler settings, toolchain file etc. look right now ?
 
 I attached three files:
 help-command.txt
 The Texas Instruments command --help output
 CMakeLists_root.txt
 Thats where i setup the toolchain and define the project
 CMakeLists_src.txt
 Thats where i add sources and binaries
 
 The cl6x toolchain is available for linux and windows after registration
 at:
 https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.
 htm

Can you build cmake from this branch I just created ?
http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/TI_DSP_Compiler

It has basic support for the TI compiler, see the files 
Modules/Compiler/TI_DSP-*.cmake.

At least I was able to compile and link C, C++ and an assembler file.

It should also work to copy these three files simply in the Modules/Compiler/ 
directory of your installed cmake, but you need at least CMake 2.8.4.

I'm quite sure these files are not complete.
Please give them a try and I'd be happy about patches to make them really 
work.

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] Assembler handling in 2.8.5 vs 2.8.4

2011-07-22 Thread Johan Björk
Alex,

I'm trying to conditionally enable ASM support for my compilers that
support it (I have a project that gets crosscompiled to a whole slew
of architectures).

In an ideal situation, I would use
ENABLE_LANGUAGE(ASM OPTIONAL) and check the flag if it works or not.

For a few of the compilers, I get the same issue as Florian where the
whole project generation fails (because cmake couldn't figure out the
assembler type :/). Is there any way to tell cmake what 'type' it is?
Also, can it be changed to just report asm support as false if it
can't detect the assembler type?

/Johan


On Fri, Jul 22, 2011 at 10:00 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
 On Thursday 21 July 2011, Florian Reinhard wrote:
 Hi Alex,

 Thank you for the quick response,

 2011/7/20 Alexander Neundorf a.neundorf-w...@gmx.net:
  Damn, I was so sure I updated the wiki, but apparently I didn't.
  So here are the old docs, but this changed quite a bit for 2.8.5:
  http://www.vtk.org/Wiki/CMake/Assembler
 
  What it does now:
  the language ASM is now for assembler files which can be processed by
  your C compiler. This actually seems to be the case for you.
  Is the compiler ID of your compiler recognized by cmake ?

 I guess not, since i define the compiler and how it is being called my
 self there is/was no need to have cmake detect the compiler ID.

  It seems like it isn't.
  If it was, the assembler support would not try to figure out the
  compiler ID for the assembler again, it would just use the compiler ID
  from C or CXX.
 
  Can you please post the complete cmake output from some basic C project ?

 Sure, hope to get this done by Friday afternoon CEST.

  Basically, what we should do, add support for your compiler toolchain,
  i.e. add support for recognizing your compiler, and create files in
  Modules/Compiler/TMS-C|CXX|ASM.cmake.

 Having cl6x support included in CMake would be really nice, besides
 that knowing how to setup a toolchain easily would be good either ;)

  This doesn't require recompiling cmake, it is all in the modules files.
  Then it should all work much better.
 
  How do you compiler settings, toolchain file etc. look right now ?

 I attached three files:
 help-command.txt
     The Texas Instruments command --help output
 CMakeLists_root.txt
     Thats where i setup the toolchain and define the project
 CMakeLists_src.txt
     Thats where i add sources and binaries

 The cl6x toolchain is available for linux and windows after registration
 at:
 https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.
 htm

 Can you build cmake from this branch I just created ?
 http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/TI_DSP_Compiler

 It has basic support for the TI compiler, see the files
 Modules/Compiler/TI_DSP-*.cmake.

 At least I was able to compile and link C, C++ and an assembler file.

 It should also work to copy these three files simply in the Modules/Compiler/
 directory of your installed cmake, but you need at least CMake 2.8.4.

 I'm quite sure these files are not complete.
 Please give them a try and I'd be happy about patches to make them really
 work.

 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

___
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] Build the dependencies tree of an executable

2011-07-22 Thread Glenn Coombs
Have you tried using target_link_libraries(A D E F) in A/Deps.cmake instead
of add_dependencies ?  I think that the add_dependencies command only
enforces a build order between targets.  I don't think it actually adds
libraries to the link line.

On 18 July 2011 17:54, Marco Corvo marco.co...@pd.infn.it wrote:

 Hi all,

 I'm facing the following problem trying to generate the dependencies tree
 of an executable. I have a working area

 /path/to/my/working/area/**MyPackage

 with, say, one executable I want to build. The relevant CMakeLists.txt line
 is something like:

 add_executable(App src/App.cc)
 target_link_libraries(App A B C D)

 now these libs (A B C D) are already installed somewhere and they depend on
 other libraries of my software release. Say they're under

 /path/to/sw/release/X.Y.Z/lib/**arch/libA.a
 /path/to/sw/release/X.Y.Z/lib/**arch/libB.a
 /path/to/sw/release/X.Y.Z/lib/**arch/libC.a
 /path/to/sw/release/X.Y.Z/lib/**arch/libD.a
 /path/to/sw/release/X.Y.Z/lib/**arch/libE.a

 ...

 and that A depends on D, E and F. When I run my build, cmake only finds
 that my App has A, B, C and D as dependencies, while actually these
 libraries have also their own dependencies.

 I tried to add a .cmake file to each package in the release area

 /path/to/sw/release/X.Y.Z/**packageA/Deps.cmake
 /path/to/sw/release/X.Y.Z/**packageB/Deps.cmake
 /path/to/sw/release/X.Y.Z/**packageD/Deps.cmake

 with

 add_library(A STATIC IMPORTED)
 add_dependencies(A D E F...)

 which is includeed with my CmakeLists.txt file in order to let cmake know
 that when I build App it depends on A, B, C D _and_ A itself depends in his
 turn on D, E and F. This should create a complete dependencies tree for my
 App.

 I know that add_dependencies gives Adding dependency to non-existent
 target with cmake version before 2.8.4 if the target is IMPORTED while with
 2.8.4/5 on a Scientific Linux 5 I'm getting a seg fault with the add_dep
 directive.

 Is this nevertheless the way to solve this problem? Are there other ways to
 build the dependencies tree of an executable which depends directly on some
 libs and indirectly on some other ones? Consider that I build static
 libraries, so I need to have the full list of libraries when linking the
 executable.

 Thanks in advance for your help.

 Cheers

 Marco

 --
 Marco Corvo
 SuperB experiment
 CNRS - Orsay
 c/o INFN - Padova
 __**_
 Powered by www.kitware.com

 Visit other Kitware open-source projects at http://www.kitware.com/**
 opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/**listinfo/cmakehttp://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] Appending to the LINK_FLAGS target property ?

2011-07-22 Thread Glenn Coombs
Excellent.  Do you know if this option was included in the recent cmake
2.8.5 release, or will it not appear officially until 2.8.6 ?

On 22 July 2011 18:39, Johan Björk p...@spotify.com wrote:

 Glenn,

 An option APPEND_STRING was added, see
 http://public.kitware.com/Bug/view.php?id=12342

 /Johan


 On Mon, Jun 27, 2011 at 4:47 PM, Glenn Coombs glenn.coo...@gmail.com
 wrote:
  For variables like CMAKE_C_FLAGS one can append to them like this:
 
  set(CMAKE_C_FLAGS ${CMAKE_CFLAGS} -some_option)
 
  For target properties like LINK_FLAGS I was using this command:
 
  set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
  /NODEFAULTLIB:LIBCMT)
 
  to do the append.  However, when I append a second time:
 
  set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
  /INCLUDE:_InitLibrary)
 
  then it breaks because the string that Visual Studio sees contains a
  semicolon in between the 2 options.  I can work round this by writing my
  append like this:
 
  get_property(link_flags TARGET myDLL PROPERTY LINK_FLAGS)
  set(link_flags ${link_flags} /INCLUDE:_InitLibrary)
  set_target_properties(myDLL PROPERTIES LINK_FLAGS ${link_flags})
 
  but that is a bit verbose for my liking.  I understand that the
 semicolons
  are how cmake separates list items from one another but shouldn't cmake
  automatically stringify the list (by replacing semicolons with spaces)
  before passing it through to the generator code ?  The same problem will
  occur for any of the XXX_FLAGS properties like COMPILE_FLAGS that are
 passed
  through unchanged to the makefile or Visual Studio project file.
 
  Is it worth filing a feature request to ask for cmake to stringify lists
 for
  the appropriate variables ?  Or is there a good reason why cmake can't or
  shouldn't implement this behaviour ?
 
  --
  Glenn
 
 
  ___
  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] Appending to the LINK_FLAGS target property ?

2011-07-22 Thread David Cole
It was just committed a week ago... It's not even in 'master' -- but it
should make it into 2.8.6...


On Fri, Jul 22, 2011 at 6:36 PM, Glenn Coombs glenn.coo...@gmail.comwrote:

 Excellent.  Do you know if this option was included in the recent cmake
 2.8.5 release, or will it not appear officially until 2.8.6 ?


 On 22 July 2011 18:39, Johan Björk p...@spotify.com wrote:

 Glenn,

 An option APPEND_STRING was added, see
 http://public.kitware.com/Bug/view.php?id=12342

 /Johan


 On Mon, Jun 27, 2011 at 4:47 PM, Glenn Coombs glenn.coo...@gmail.com
 wrote:
  For variables like CMAKE_C_FLAGS one can append to them like this:
 
  set(CMAKE_C_FLAGS ${CMAKE_CFLAGS} -some_option)
 
  For target properties like LINK_FLAGS I was using this command:
 
  set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
  /NODEFAULTLIB:LIBCMT)
 
  to do the append.  However, when I append a second time:
 
  set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
  /INCLUDE:_InitLibrary)
 
  then it breaks because the string that Visual Studio sees contains a
  semicolon in between the 2 options.  I can work round this by writing my
  append like this:
 
  get_property(link_flags TARGET myDLL PROPERTY LINK_FLAGS)
  set(link_flags ${link_flags} /INCLUDE:_InitLibrary)
  set_target_properties(myDLL PROPERTIES LINK_FLAGS ${link_flags})
 
  but that is a bit verbose for my liking.  I understand that the
 semicolons
  are how cmake separates list items from one another but shouldn't cmake
  automatically stringify the list (by replacing semicolons with spaces)
  before passing it through to the generator code ?  The same problem will
  occur for any of the XXX_FLAGS properties like COMPILE_FLAGS that are
 passed
  through unchanged to the makefile or Visual Studio project file.
 
  Is it worth filing a feature request to ask for cmake to stringify lists
 for
  the appropriate variables ?  Or is there a good reason why cmake can't
 or
  shouldn't implement this behaviour ?
 
  --
  Glenn
 
 
  ___
  Powered by www.kitware.com
 
  Visit other Kitware open-source projects at
  http://www.kitware.com/opensource/opensource.html
 
  Please keep messages on-topic and check the CMake FAQ at:
  http://www.cmake.org/Wiki/CMake_FAQ
 
  Follow this link to subscribe/unsubscribe:
  http://www.cmake.org/mailman/listinfo/cmake
 



 ___
 Powered by www.kitware.com

 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/listinfo/cmake

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v2.8.4-1899-g0e31b65

2011-07-22 Thread Clinton Stimpson
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  0e31b654a93ddf29930ce5be202085322917 (commit)
   via  0ae8a3405bb32afadda13f43100484e85f7ef74f (commit)
  from  caeb79d42dabfcb6f0a519b7185b0da50e2e645c (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=0e31b654a93ddf29930ce5be202085322917
commit 0e31b654a93ddf29930ce5be202085322917
Merge: caeb79d 0ae8a34
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Fri Jul 22 15:37:24 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Jul 22 15:37:24 2011 -0400

Merge topic 'cross-qt4-find-includes' into next

0ae8a34 Add qt4/QtCore to help find Qt headers when cross-compiling.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ae8a3405bb32afadda13f43100484e85f7ef74f
commit 0ae8a3405bb32afadda13f43100484e85f7ef74f
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Fri Jul 22 13:38:36 2011 -0600
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Fri Jul 22 13:38:36 2011 -0600

Add qt4/QtCore to help find Qt headers when cross-compiling.

diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
index 86fce9d..a0941ca 100644
--- a/Modules/FindQt4.cmake
+++ b/Modules/FindQt4.cmake
@@ -620,7 +620,7 @@ IF (QT_QMAKE_EXECUTABLE AND QTVERSION)
   SET(QT_QTCORE_INCLUDE_DIR NOTFOUND)
   FIND_PATH(QT_QTCORE_INCLUDE_DIR QtCore
 HINTS ${qt_headers} ${QT_LIBRARY_DIR}
-PATH_SUFFIXES QtCore
+PATH_SUFFIXES QtCore qt4/QtCore
 )
 
   # Set QT_HEADERS_DIR based on finding QtCore header

---

Summary of changes:
 Modules/FindQt4.cmake |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, master, updated. v2.8.4-642-gc70c62d

2011-07-22 Thread KWSys Robot
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, master has been updated
   via  c70c62db55f066a25641a1e027959c3b62ec486a (commit)
  from  528262365816923ba7caca6a3c3d870a94ba7061 (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=c70c62db55f066a25641a1e027959c3b62ec486a
commit c70c62db55f066a25641a1e027959c3b62ec486a
Author: KWSys Robot kwro...@kitware.com
AuthorDate: Sat Jul 23 00:01:03 2011 -0400
Commit: KWSys Robot kwro...@kitware.com
CommitDate: Sat Jul 23 00:14:05 2011 -0400

KWSys Nightly Date Stamp

diff --git a/Source/kwsys/kwsysDateStamp.cmake 
b/Source/kwsys/kwsysDateStamp.cmake
index 0a7e8ae..c9beeeb 100644
--- a/Source/kwsys/kwsysDateStamp.cmake
+++ b/Source/kwsys/kwsysDateStamp.cmake
@@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR  2011)
 SET(KWSYS_DATE_STAMP_MONTH 07)
 
 # KWSys version date day component.  Format is DD.
-SET(KWSYS_DATE_STAMP_DAY   22)
+SET(KWSYS_DATE_STAMP_DAY   23)

---

Summary of changes:
 Source/kwsys/kwsysDateStamp.cmake |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits