date:20110608

Am 09.06.2011 07:35, schrieb Michael Hertling:

On 06/09/2011 07:13 AM, Andreas Naumann wrote:

Am 08.06.2011 20:43, schrieb Andreas Pakulat:

On 08.06.11 20:00:54, Andreas Naumann wrote:

Am 08.06.2011 15:02, schrieb Eric Noulard:

2011/6/8 Andreas Naumann:

Am 08.06.2011 11:56, schrieb Eric Noulard:

2011/6/8 Andreas Naumann:

Hi @all,

I have some problem with the library usage in cmake.

It seems to me, that cmake removes the full path of the library, if the
path
is in the environment variable LIBRARY_PATH.
This behaviour cause problems at our system, such that the linker links
against the wrong library.

Is there an option to avoid this splitting?

Did you read that:
http://www.cmake.org/Wiki/CMake_RPATH_handling

Which version of CMake are you using?
On which system ?

We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.

I've read the hints on RPATH handling, but there it is said, that:
"By default if you don't change any RPATH related settings, CMake will link
the executables and shared libraries with full RPATH to all used libraries
in the build tree"

Yes.
And you did not mention it but the probleme you have occurs when using
the executable **directly from the build dir** right?

what do you mean with "using"? I cannot even link the executable,
because cmake removes the path from the library without adding the
directory to the library directories.

This means, if I don't set anything related to RPATH, cmake should not strip
the path from the library, should it?

No it shoudn't for the binary in the buitd tree but...
if you do "make install" the installed binaries will have no RPATH unless
you set

SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")

# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

I don't even want to install, just build and use.

I played with the example and it was a bit hard to understand, when the path
is stripped from the library.
The problem arises before linking the executable.

This is a different issue.
Could you copy/paste the

add_executable
and
target_link_libraries

statement you use for the offending executable?

simple:
project("test")

cmake_minimum_required(VERSION 2.8)
set(MYLIB /home/andreas/cmake_test/lib/libfoo.so)
add_executable(foo_exec test.cc)
target_link_libraries(foo_exec ${MYLIB})

So the executable gets the full name and the example works, if the
environment variable library_path is not set to
/home/andreas/cmake_test/lib. The link command is:

/usr/bin/c++ CMakeFiles/foo_exec.dir/test.cc.o -o foo_exec
-rdynamic /home/andreas/cmake_test/lib/libfoo.so
-Wl,-rpath,/home/andreas/cmake_test/lib

If I set LIBRARY_PATH to /home/andreas/cmake_test/lib, the directory
is stripped and the link-command gets:

/usr/bin/c++ CMakeFiles/foo_exec.dir/test.cc.o -o foo_exec
-rdynamic -lfoo

I can reproduce this here with CMake 2.8.4.

And before someone else asks (since I thought that might be the error),
the envvar is really "LIBRARY_PATH", i.e. not LD_LIBRARY_PATH.

The strange thing is that there's no occurrence of this specific string
anywhere in the cmake sources. There are all kinds of occurrence of
LD_... or CMAKE_... but no string matching just LIBRARY_PATH. So its
unclear why CMake respects that envvar.

Andreas

___
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

The problem is related to the compiler, not to the linker. The
gcc-documentation
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Environment-Variables.html#Environment-Variables
says:

LIBRARY_PATH
The value of LIBRARY_PATH is a colon-separated list of directories, much
like PATH. When configured as a native compiler, GCC tries the
directories thus specified when searching for special linker files, if
it can't find them using GCC_EXEC_PREFIX. Linking using GCC also uses
these directories when searching for ordinary libraries for the -l
option (but directories specified with -L come first).

CMake seems to ask the compiler for implicitly used link directories and
removes each path in this list from the libraries in the directories.
Because this information comes from the compiler, cmake cannot
distinguish between working and not working directories.
My question is now, why does cmake remove the paths? If the use
specifies a library with full path, he wants EXACTLY this library.

Currently, we print a warning, if the vari

Re: [CMake] library path stripping

On 06/09/2011 07:13 AM, Andreas Naumann wrote:
> Am 08.06.2011 20:43, schrieb Andreas Pakulat:
>> On 08.06.11 20:00:54, Andreas Naumann wrote:
>>
>>> Am 08.06.2011 15:02, schrieb Eric Noulard:
>>>  
 2011/6/8 Andreas Naumann:

> Am 08.06.2011 11:56, schrieb Eric Noulard:
>  
>> 2011/6/8 Andreas Naumann:
>>
>>
>>> Hi @all,
>>>
>>> I have some problem with the library usage in cmake.
>>>
>>> It seems to me, that cmake removes the full path of the library, if the
>>> path
>>> is in the environment variable LIBRARY_PATH.
>>> This behaviour cause problems at our system, such that the linker links
>>> against the wrong library.
>>>
>>> Is there an option to avoid this splitting?
>>>
>>>  
>> Did you read that:
>> http://www.cmake.org/Wiki/CMake_RPATH_handling
>>
>> Which version of CMake are you using?
>> On which system ?
>>
>>
>>
>>
> We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.
>
> I've read the hints on RPATH handling, but there it is said, that:
> "By default if you don't change any RPATH related settings, CMake will 
> link
> the executables and shared libraries with full RPATH to all used libraries
> in the build tree"
>  
 Yes.
 And you did not mention it but the probleme you have occurs when using
 the executable **directly from the build dir** right?

>>> what do you mean with "using"? I cannot even link the executable,
>>> because cmake removes the path from the library without adding the
>>> directory to the library directories.
>>>
>>>  
> This means, if I don't set anything related to RPATH, cmake should not 
> strip
> the path from the library, should it?
>  
 No it shoudn't for the binary in the buitd tree but...
 if you do "make install" the installed binaries will have no RPATH unless
 you set

 SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")

 # add the automatically determined parts of the RPATH
 # which point to directories outside the build tree to the install RPATH
 SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)


>>> I don't even want to install, just build and use.
>>>  
> I played with the example and it was a bit hard to understand, when the 
> path
> is stripped from the library.
> The problem arises before linking the executable.
>  
 This is a different issue.
 Could you copy/paste the

 add_executable
 and
 target_link_libraries

 statement you use for the offending executable?


>>> simple:
>>> project("test")
>>>
>>> cmake_minimum_required(VERSION 2.8)
>>> set(MYLIB /home/andreas/cmake_test/lib/libfoo.so)
>>> add_executable(foo_exec test.cc)
>>> target_link_libraries(foo_exec ${MYLIB})
>>>
>>> So the executable gets the full name and the example works, if the
>>> environment variable library_path is not set to
>>> /home/andreas/cmake_test/lib. The link command is:
>>>
>>> /usr/bin/c++  CMakeFiles/foo_exec.dir/test.cc.o  -o foo_exec
>>> -rdynamic /home/andreas/cmake_test/lib/libfoo.so
>>> -Wl,-rpath,/home/andreas/cmake_test/lib
>>>
>>> If I set LIBRARY_PATH to /home/andreas/cmake_test/lib, the directory
>>> is stripped and the link-command gets:
>>>
>>> /usr/bin/c++  CMakeFiles/foo_exec.dir/test.cc.o  -o foo_exec
>>> -rdynamic -lfoo
>>>  
>> I can reproduce this here with CMake 2.8.4.
>>
>> And before someone else asks (since I thought that might be the error),
>> the envvar is really "LIBRARY_PATH", i.e. not LD_LIBRARY_PATH.
>>
>> The strange thing is that there's no occurrence of this specific string
>> anywhere in the cmake sources. There are all kinds of occurrence of
>> LD_... or CMAKE_... but no string matching just LIBRARY_PATH. So its
>> unclear why CMake respects that envvar.
>>
>> Andreas
>>
>> ___
>> 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
>>
>>
> 
> The problem is related to the compiler, not to the linker. The 
> gcc-documentation
> http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Environment-Variables.html#Environment-Variables
> says:
> 
> LIBRARY_PATH
> The value of LIBRARY_PATH is a colon-separated list of directories, much 
> like PATH. When configured as a native compiler, GCC tries the 
> directories thus specified when searching for special linker files, if 
> it can't find them using GCC_EXEC_PREFIX. Linking using GCC also uses 
> these directories when searching for ordinary libraries for the -l 
> option

Re: [CMake] library path stripping

Am 08.06.2011 20:43, schrieb Andreas Pakulat:

On 08.06.11 20:00:54, Andreas Naumann wrote:

Am 08.06.2011 15:02, schrieb Eric Noulard:

2011/6/8 Andreas Naumann:

Am 08.06.2011 11:56, schrieb Eric Noulard:

2011/6/8 Andreas Naumann:

Hi @all,

I have some problem with the library usage in cmake.

Is there an option to avoid this splitting?

Did you read that:
http://www.cmake.org/Wiki/CMake_RPATH_handling

Which version of CMake are you using?
On which system ?

We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.

Yes.
And you did not mention it but the probleme you have occurs when using
the executable **directly from the build dir** right?

what do you mean with "using"? I cannot even link the executable,
because cmake removes the path from the library without adding the
directory to the library directories.

This means, if I don't set anything related to RPATH, cmake should not strip
the path from the library, should it?

No it shoudn't for the binary in the buitd tree but...
if you do "make install" the installed binaries will have no RPATH unless
you set

SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")

# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

I don't even want to install, just build and use.

I played with the example and it was a bit hard to understand, when the path
is stripped from the library.
The problem arises before linking the executable.

This is a different issue.
Could you copy/paste the

add_executable
and
target_link_libraries

statement you use for the offending executable?

simple:
project("test")

cmake_minimum_required(VERSION 2.8)
set(MYLIB /home/andreas/cmake_test/lib/libfoo.so)
add_executable(foo_exec test.cc)
target_link_libraries(foo_exec ${MYLIB})

So the executable gets the full name and the example works, if the
environment variable library_path is not set to
/home/andreas/cmake_test/lib. The link command is:

/usr/bin/c++ CMakeFiles/foo_exec.dir/test.cc.o -o foo_exec
-rdynamic /home/andreas/cmake_test/lib/libfoo.so
-Wl,-rpath,/home/andreas/cmake_test/lib

If I set LIBRARY_PATH to /home/andreas/cmake_test/lib, the directory
is stripped and the link-command gets:

/usr/bin/c++ CMakeFiles/foo_exec.dir/test.cc.o -o foo_exec
-rdynamic -lfoo

I can reproduce this here with CMake 2.8.4.

And before someone else asks (since I thought that might be the error),
the envvar is really "LIBRARY_PATH", i.e. not LD_LIBRARY_PATH.

Andreas

___
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

The problem is related to the compiler, not to the linker. The
gcc-documentation

http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Environment-Variables.html#Environment-Variables
says:

Currently, we print a warning, if the variable LIBRARY_PATH is set in
the environment.

Andreas
___
Powered by www.kitware.com

Visit other Kitware open-source projects at
h

Re: [CMake] FindQt4.cmake to automatically include QT_USE_FILE?

On 06/07/2011 09:13 PM, Bjørn Forsman wrote:
> 2011/6/7 Michael Wild :
>> If the FindXXX.cmake file called add_definitions(),
>> include_directories() et al., that could be potentially harmful. Some
>> sources might required that some define is not set, or a wrong header
>> file might be #include'ed (thing of all the different X.h that exist).
>> FindXXX.cmake modules should just define a few variables, *not* change
>> the build system. That's the caller's responsibility, either by calling
>> the functions himself or by including the UseXXX.cmake (if provided).
> 
> Ok, I see the point now. However, if find_package is called only in
> the subdirectories that actually need it the above problem is
> non-existent. No? (At least add_definitions only work on the current
> dir and below.) But if the policy is they way it is, then OK, I get
> the point and I'll leave it at that.

As you've said yourself in this thread earlier, FIND_PACKAGE()'s point
is to "set up variables containing necessary includes and libs" - and
nothing should happen behind your back. For this reason, I think that
FIND_PACKAGE() should be safe to invoke from *anywhere* in a project,
with results solely depending on the COMPONENTS, well-known variables
like CMAKE_PREFIX_PATH and well-documented ones like XXX_ROOT; taking
into account the results of previous FIND_PACKAGE() invocations might
have undesired effects, e.g. overlinking.

> However, according to Modules/readme.txt, FindXXX.cmake files should
> set XXX_LIBRARIES, XXX_INCLUDE_DIRS and XXX_DEFINITIONS. FindQt4.cmake
> sets neither. I can try to come up with a patch to fix this, but I
> won't complain if someone beats me to it ;-)

My suggestions for an improvement of FindQt4.cmake are:

1) Introduce symbolic names, e.g. QT_QT*_DEFINITIONS, for the modules'
preprocessor definitions like -DQT_*_LIB, so one has a chance to set
up a complete compilation environment w.r.t. Qt modules without the
need to include the QT_USE_FILE. This is important for find modules
using FindQt4.cmake and should be feasible without harming backward
compatibility.

2) Correct/complete the management of Qt's inter-module dependencies
and check if it can be added to FindQt4.cmake. AFAICS, it means no
harm if this is done in FindQt4.cmake, too, along with UseQt4.cmake.

3) Populate QT_{LIBRARIES,INCLUDE_DIRS,DEFINITIONS} with settings
according only to the COMPONENTS and their prerequisites, cf (2).
QT_INCLUDE_DIRS is new, i.e. no harm, and QT_LIBRARIES is reset by
UseQt4.cmake, so the latter's users should not see any differences
with regard to the current behavior. Admittedly, the enhancement of
QT_DEFINITIONS might result in some doublings among the preprocessor
definitions, but this should also mean no harm and could possibly be
taken into account by UseQt4.cmake. Alternatively, one might use the
variables QT4_{LIBRARIES,INCLUDE_DIRS,DEFINITIONS} for this purpose.
^
Regards,

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] FindQt4.cmake to automatically include QT_USE_FILE?

On 06/07/2011 06:58 PM, Michael Wild wrote:
> On 06/07/2011 06:23 PM, Bjørn Forsman wrote:
>> 2011/6/7 Michael Wild :
>>> On 06/07/2011 03:38 PM, Bjørn Forsman wrote:
 Why not put find_package(Qt4) in the sub directories where it is actually 
 used?
>>>
>>> And if it is used in multiple subdirectories?
>>
>> What's bad about that? (Sorry, I really don't know).
> 
> Then you would need to call find_package in all the subdirectories, with
> all the work that goes along with that.

Michael, with your approach, i.e. a FIND_PACKAGE(Qt4) once in the top-
level CMakeLists.txt and INCLUDE(${QT_USE_FILE}) where needed, you've
to set up the required QT_USE_* variables each time, and possibly, you
must even unset some of them in case they are inherited from previous
actions like that. Is this really less effort than an additional call
to FIND_PACKAGE()? IMO, the latter is neater and more expressive, and
if FindQt4.cmake would provide the variables recommended by Modules/
readme.txt, i.e. QT_{LIBRARIES,INCLUDE_DIRS,DEFINITIONS}, one could
completely drop the QT_USE_FILE and proceed as known from the
majority of packages.

>>> FindXXX.cmake modules should only do the minimum, i.e. finding the
>>> required libraries and include-directories, setting XXX_FOUND,
>>> XXX_INCLUDE_DIRS and XXX_LIBRARIES. Anything more complex, e.g. calling
>>> add_definitions(), include_directories(), function(), macro() etc.
>>> should go into a UseXXX.cmake module.
>>
>> Ok, I didn't know about that policy.
>>
>>> If you find a FindXXX.cmake module that calls add_definitions(),
>>> include_directories(), link_libraries() or some such, it is broken and
>>> needs to be fixed.
>>
>> Broken because of the above defined policy? Or of technical reasons?
>> Sorry, but I still don't see the reason why the current find_package +
>> use_file is better than a find_package that includes the use_file
>> itself.
> 
> If the FindXXX.cmake file called add_definitions(),
> include_directories() et al., that could be potentially harmful. Some
> sources might required that some define is not set, or a wrong header
> file might be #include'ed (thing of all the different X.h that exist).
> FindXXX.cmake modules should just define a few variables, *not* change
> the build system. That's the caller's responsibility, either by calling
> the functions himself or by including the UseXXX.cmake (if provided).

Absolutely, but note that FindXXX.cmake is possibly used in other find
modules, so it must provide *complete* information to set up the build
environment for XXX without a need to include UseXXX.cmake; otherwise,
the other package is forced to provide a use file, too, and this might
be inappropriate. The combination of {Find,Use}Qt4.cmake has such a
deficiency w.r.t. the QT_*_LIB preprocessor definitions.

>> What I see is that current usage goes something like this:
>>
>> 1) find_package(Qt4 REQUIRED) at the top level
>> 2) subdirs that actually need Qt: set what modules to enable/disable
>> and then include the use_file.
>>
>> How about doing it this way:
>> 1) subdirs that actually need Qt: call find_package(Qt4 COMPONENTS
>> QtCore [...] REQUIRED) with the modules it needs.
>>
>> Is there a problem with this approach? Other than breaking the policy ;-)
> 
> In principle not, except that all these redundant find_path() and
> find_library() calls will incur some slight overhead.

As Marcus has pointed out in the meantime, this should carry no weight
due to the cache. Personally, I also prefer to have multiple calls to
FIND_PACKAGE(Qt4), once in each CMakeLists.txt that's using Qt, and I
place them after any ADD_SUBDIRECTORY() command unless I actually want
to convey the results to the subdirectories. IMO, this allows for good
locality and self-contained subprojects and minimizes the chance of
overlinking, but probably, it's a matter of taste.

Regards,

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] FindQt4.cmake to automatically include QT_USE_FILE?

On 06/07/2011 02:20 PM, Bjørn Forsman wrote:
> Hi all,
> 
> As far as I can tell, all Qt programs built with CMake must include
> QT_USE_FILE after find_package(). So why doesn't FindQt4.cmake simply
> include QT_USE_FILE itself? Is there maybe a use case where
> QT_USE_FILE is *not* wanted?

Yes, there is: Suppose there is a tiny library package X which uses
Qt's signal/slot mechanism and, thus, must link against QtCore. X's
FindX.cmake or XConfig.cmake is expected to provide the variables
X_LIBRARIES, X_INCLUDE_DIRS and X_DEFINITIONS. While you can add
QT_QTCORE_LIBRARY to X_LIBRARIES and QT_QTCORE_INCLUDE_DIR to
X_INCLUDE_DIRS, how do you add the preprocessor definition for
the compilation with the QtCore headers, i.e. -DQT_CORE_LIB, to
X_DEFINITIONS? These definitions are hardcoded in QT_USE_FILE and
immediately enabled there via ADD_DEFINITIONS(). FindQt4.cmake does
not provide symbolic names for them, so you cannot set up a complete
compilation environment for Qt modules without including QT_USE_FILE,
and that's not allowed for find modules or config files as Michael W.
has pointed out in this thread earlier. The only possibilities for X
to allow its users to prepare a complete compilation environment are

1) either tell X's users to include QT_USE_FILE after FIND_PACKAGE(X)
when they want to use the X stuff ("Why do I have to include this
QT_USE_FILE thing when all I want is just using X? Strange...")

2) or provide an own X_USE_FILE which just includes QT_USE_FILE, and
tell X's users to include X_USE_FILE after FIND_PACKAGE(X) when they
want to use the X stuff ("Why do I have to bother with this USE_FILE
thing when I want to use a tiny package like X? I have already seen
more complex packages that don't require such hassle. Strange...").

Currently, the QT_USE_FILE is not just convenient, but *necessary* to
completely set up the compilation environment. IMO, that's wrong, in
particular as it is not only to be used in CMakeLists.txt files, but
also in other find modules and, possibly, configuration files.

There's another reason why QT_USE_FILE is somewhat essential to set
up the compilation environment: It cares for the Qt inter-module
dependencies. Look at the following example:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(QTMODDEPS C CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FIND_PACKAGE(Qt4 COMPONENTS QtSvg)
INCLUDE(${QT_USE_FILE})
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main ${QT_LIBRARIES})

It's QT_USE_FILE that enables Qt{Xml,Gui,Core} in the link command line
although only QtSvg has been requested. Therefore, if one doesn't want
to use QT_USE_FILE, one has to sort out these dependencies by oneself.
IMO, that's also wrong as I'd consider it to be the find module's job
to track dependencies among components requested with FIND_PACKAGE(),
not a USE_FILE's one. BTW, if you replace Svg by Sql in the example
above, you'll see that the main target is linked only against QtSql
although the latter does depend on QtCore. Obviously, QT_USE_FILE's
dependency management is not complete, so one should take care of
mentioning all necessary Qt modules in FIND_PACKAGE() by oneself.

Personally, I'd appreciate a FindQt4.cmake which

- completely and correctly tracks dependencies among the Qt modules,
- provides the usual variables QT_{LIBRARIES,INCLUDE_DIRS,DEFINITIONS},
- populates them with settings based on the COMPONENTS list passed to
  the FIND_PACKAGE(Qt4 ...) call and those components' prerequisites,
- does *not* take the results of previous FIND_PACKAGE(Qt4 ...) calls
  into consideration, i.e. does not act in an accumulative manner. So,
  the values of the QT_{LIBRARIES,INCLUDE_DIRS,DEFINITIONS} variables
  after a call to FIND_PACKAGE() do depend only on the COMPONENTS list
  passed to FIND_PACKAGE(), well-known variables as CMAKE_PREFIX_PATH
  and package-specific - documented - ones as QT_QMAKE_EXECUTABLE.

In this way, QT_USE_FILE would not be necessary anymore, and one could
invoke FIND_PACKAGE(Qt4 ...) multiple times and anywhere in a project
and gets exactly what has been requested without the risk of catching
unmeant results from previous FIND_PACKAGE(Qt4) invocations. Finally,
find modules may provide their users with complete information about
the compilation environment if their respective package uses Qt4.

Regards,

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] cmake - preventing `make clean` from cleaning ExternalProject.

2011-06-08 Thread Alexander Neundorf

On Tuesday 07 June 2011, Alexander Neundorf wrote:
> On Tuesday, June 07, 2011 04:41:03 AM jeeyoung kim wrote:
> > I was wondering if there's some way to prevent make clean in cmake from
> > re-building external dependencies. I'm using ExternalProject to build
> > third party c++ libraries, and they do not have to be rebuilt even if I
> > do make clean.
> > 
> > On the other hand, I might want to create a new rule, say, make
> > really-clean, which even clears the dependencies. is there a good way to
> > do this?
> 
> That really sounds like a useful thing.
> Same thing for me.
> Since I have only a few targets in my projects, it is still possible to
> simply make clean in the other directories.
> 
> I am not aware of a way to exclude the external projects from the normal
> clean. But this sounds like something useful.

So, can you please create an entry in the cmake bug tracker at 
http://www.cmake.org/Bug ?

Thanks
Alex
___
Powered by www.kitware.com

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

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

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

Re: [CMake] submit after partial buildup

2011-06-08 Thread Alexander Neundorf

On Wednesday 08 June 2011, Ilias Miroslav wrote:
> Dear CMake developers,
> 
> for our oproject we are utilizing the 'make Exerimental' and 'make Nigthly'
> commands to make the all (update)/configure/build/test  and sending report
> steps.
> 
> One can see that on our CDash-board, like
> https://repo.ctcc.no/CDash/index.php?project=DIRAC&date=2011-06-07
> 
> However,  we would need to perform only the  ('Update',) 'Configure' and
> 'Build' steps, without the  'Test', since for one platform (Windows) we
> don't have 'make test' running properly.
> 
> I tried it with commands 'make' and 'make ExperimentalSubmit', but I don't
> see report of the dashboard.
> 
> I got only message of 'Submission successful' without results on the
> web-board:
> 
> .make ExperimentalSubmit
>Site: pd
>Build name: pd_uniza.linux.openmpi_gfortran_gcc_atlas.ilp64.opt
> Submit files (using http)
>Using HTTP submit method
>Drop site:http://repo.ctcc.no/CDash/submit.php?project=DIRAC
>Submission successful
> Built target ExperimentalSubmit
> 
> Any help please how to report each partial buildup step on the dashboard ?

Don't use the targets provided for Nightly, they only kind-of somewhat work.

Instead, write a ctest script which drives the testing, then you have full 
control.
Examples you can find e.g. here:
http://websvn.kde.org/trunk/quality/nightly-
support/KDE/KDELibsNightly.cmake?revision=HEAD
which needs the file KDECTestNightly.cmake located in the parent directory: 
http://websvn.kde.org/trunk/quality/nightly-support/
(this file has no KDE dependencies, it only has the "KDE" prefix to show that 
this does not come with standard cmake).

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] library path stripping

2011-06-08 Thread Andreas Pakulat

On 08.06.11 20:00:54, Andreas Naumann wrote:
> Am 08.06.2011 15:02, schrieb Eric Noulard:
> >2011/6/8 Andreas Naumann:
> >>Am 08.06.2011 11:56, schrieb Eric Noulard:
> >>>2011/6/8 Andreas Naumann:
> >>>
> Hi @all,
> 
> I have some problem with the library usage in cmake.
> 
> It seems to me, that cmake removes the full path of the library, if the
> path
> is in the environment variable LIBRARY_PATH.
> This behaviour cause problems at our system, such that the linker links
> against the wrong library.
> 
> Is there an option to avoid this splitting?
> 
> >>>Did you read that:
> >>>http://www.cmake.org/Wiki/CMake_RPATH_handling
> >>>
> >>>Which version of CMake are you using?
> >>>On which system ?
> >>>
> >>>
> >>>
> >>We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.
> >>
> >>I've read the hints on RPATH handling, but there it is said, that:
> >>"By default if you don't change any RPATH related settings, CMake will link
> >>the executables and shared libraries with full RPATH to all used libraries
> >>in the build tree"
> >Yes.
> >And you did not mention it but the probleme you have occurs when using
> >the executable **directly from the build dir** right?
> what do you mean with "using"? I cannot even link the executable,
> because cmake removes the path from the library without adding the
> directory to the library directories.
> 
> >>This means, if I don't set anything related to RPATH, cmake should not strip
> >>the path from the library, should it?
> >No it shoudn't for the binary in the buitd tree but...
> >if you do "make install" the installed binaries will have no RPATH unless
> >you set
> >
> >SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> >
> ># add the automatically determined parts of the RPATH
> ># which point to directories outside the build tree to the install RPATH
> >SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> >
> I don't even want to install, just build and use.
> >>I played with the example and it was a bit hard to understand, when the path
> >>is stripped from the library.
> >>The problem arises before linking the executable.
> >This is a different issue.
> >Could you copy/paste the
> >
> >add_executable
> >and
> >target_link_libraries
> >
> >statement you use for the offending executable?
> >
> simple:
> project("test")
> 
> cmake_minimum_required(VERSION 2.8)
> set(MYLIB /home/andreas/cmake_test/lib/libfoo.so)
> add_executable(foo_exec test.cc)
> target_link_libraries(foo_exec ${MYLIB})
> 
> So the executable gets the full name and the example works, if the
> environment variable library_path is not set to
> /home/andreas/cmake_test/lib. The link command is:
> 
> /usr/bin/c++  CMakeFiles/foo_exec.dir/test.cc.o  -o foo_exec
> -rdynamic /home/andreas/cmake_test/lib/libfoo.so
> -Wl,-rpath,/home/andreas/cmake_test/lib
> 
> If I set LIBRARY_PATH to /home/andreas/cmake_test/lib, the directory
> is stripped and the link-command gets:
> 
> /usr/bin/c++  CMakeFiles/foo_exec.dir/test.cc.o  -o foo_exec
> -rdynamic -lfoo

I can reproduce this here with CMake 2.8.4.

And before someone else asks (since I thought that might be the error),
the envvar is really "LIBRARY_PATH", i.e. not LD_LIBRARY_PATH.

The strange thing is that there's no occurrence of this specific string
anywhere in the cmake sources. There are all kinds of occurrence of
LD_... or CMAKE_... but no string matching just LIBRARY_PATH. So its
unclear why CMake respects that envvar.

Andreas

___
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] library path stripping


Am 08.06.2011 15:02, schrieb Eric Noulard:

2011/6/8 Andreas Naumann:
   

Am 08.06.2011 11:56, schrieb Eric Noulard:
 

2011/6/8 Andreas Naumann:

   

Hi @all,

I have some problem with the library usage in cmake.

It seems to me, that cmake removes the full path of the library, if the
path
is in the environment variable LIBRARY_PATH.
This behaviour cause problems at our system, such that the linker links
against the wrong library.

Is there an option to avoid this splitting?

 

Did you read that:
http://www.cmake.org/Wiki/CMake_RPATH_handling

Which version of CMake are you using?
On which system ?



   

We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.

I've read the hints on RPATH handling, but there it is said, that:
"By default if you don't change any RPATH related settings, CMake will link
the executables and shared libraries with full RPATH to all used libraries
in the build tree"
 

Yes.
And you did not mention it but the probleme you have occurs when using
the executable **directly from the build dir** right?
   
what do you mean with "using"? I cannot even link the executable, 
because cmake removes the path from the library without adding the 
directory to the library directories.


   

This means, if I don't set anything related to RPATH, cmake should not strip
the path from the library, should it?
 

No it shoudn't for the binary in the buitd tree but...
if you do "make install" the installed binaries will have no RPATH unless
you set

SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")

# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

   

I don't even want to install, just build and use.

I played with the example and it was a bit hard to understand, when the path
is stripped from the library.
The problem arises before linking the executable.
 

This is a different issue.
Could you copy/paste the

add_executable
and
target_link_libraries

statement you use for the offending executable?

   

simple:
project("test")

cmake_minimum_required(VERSION 2.8)
set(MYLIB /home/andreas/cmake_test/lib/libfoo.so)
add_executable(foo_exec test.cc)
target_link_libraries(foo_exec ${MYLIB})

So the executable gets the full name and the example works, if the 
environment variable library_path is not set to 
/home/andreas/cmake_test/lib. The link command is:


/usr/bin/c++  CMakeFiles/foo_exec.dir/test.cc.o  -o foo_exec 
-rdynamic /home/andreas/cmake_test/lib/libfoo.so 
-Wl,-rpath,/home/andreas/cmake_test/lib


If I set LIBRARY_PATH to /home/andreas/cmake_test/lib, the directory is 
stripped and the link-command gets:


/usr/bin/c++  CMakeFiles/foo_exec.dir/test.cc.o  -o foo_exec 
-rdynamic -lfoo




We link to a library, which exists in two different directories:
/usr/lib64
and
somewhere/lib/
 

This should be resolved by YOU inside CMakeLists.txt by

target_link_libraries(exename /path/to/appropriate/lib/lbname.so)

the
/path/to/appropriate/lib/lbname.so could be the result of an appropriate
find_library
call.

   

At the same time, the environment variable LIBRARY_PATH is set to
somewhere/lib. In this case, cmake removes the path from the library name,
but does not append it as -L to the linker search paths.
Now it is up to the linker to choose the right library, which is really bad!
In our case (gcc 4.1.2 on Suse) it selects the wrong library.

Is there any possibility to avoid this "environmentvariable dependent"
splitting?
 

Yes full RPATH should be the solution.


   


___
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] cmd.exe does not expand wildcards

2011-06-08 Thread Jean-Christophe Fillion-Robin

Hi Mathieu,

May be you could try the following ...

file(GLOB log_files "*.log")
if(log_files)
  execute_process(${CMAKE_COMMAND} -E tar cvfz test.tgz ${log_files})
endif()

Hth
Jc

On Wed, Jun 8, 2011 at 12:05 PM, Mathieu Malaterre <
mathieu.malate...@gmail.com> wrote:

> Hi there,
>
>  Slightly off topic, but how do people cope with cmd.exe not
> expanding wildcards (*) ?
>
>  I would like to do something like:
>
> cmd> cmake -E tar cvfz test.tgz *.log
>
> Thanks
> --
> Mathieu
> ___
> 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
>



-- 
+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

[CMake] cmd.exe does not expand wildcards

2011-06-08 Thread Mathieu Malaterre

Hi there,

  Slightly off topic, but how do people cope with cmd.exe not
expanding wildcards (*) ?

  I would like to do something like:

cmd> cmake -E tar cvfz test.tgz *.log

Thanks
-- 
Mathieu
___
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's check of the generated target

2011/6/8 Ilias Miroslav :
> Dear experts,
>
> We would like to check the generated target (main executable) after it was 
> built.
>
> For example
> .
> .
> Linking Fortran executable vibcal.x
> [100%] Built target vibcal.x
> [100%] Built target dirac.x
>
> afterwards, it would be good to get own message about properties of the 
> generated target dirac.x, for instance "ldd dirac.x",  "size dirac.x" etc. 
> How to do that with the  CMake please ?

add_custom_command(TARGET dirac.x POST_BUILD COMMAND ldd dirac.x)

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

[CMake] cmake's check of the generated target

2011-06-08 Thread Ilias Miroslav

Dear experts,

We would like to check the generated target (main executable) after it was 
built.

For example
.
.
Linking Fortran executable vibcal.x
[100%] Built target vibcal.x
[100%] Built target dirac.x

afterwards, it would be good to get own message about properties of the 
generated target dirac.x, for instance "ldd dirac.x",  "size dirac.x" etc. How 
to do that with the  CMake please ?

Thanks, Miro
___
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] library path stripping

2011/6/8 Andreas Naumann :
> Am 08.06.2011 11:56, schrieb Eric Noulard:
>>
>> 2011/6/8 Andreas Naumann:
>>
>>>
>>> Hi @all,
>>>
>>> I have some problem with the library usage in cmake.
>>>
>>> It seems to me, that cmake removes the full path of the library, if the
>>> path
>>> is in the environment variable LIBRARY_PATH.
>>> This behaviour cause problems at our system, such that the linker links
>>> against the wrong library.
>>>
>>> Is there an option to avoid this splitting?
>>>
>>
>> Did you read that:
>> http://www.cmake.org/Wiki/CMake_RPATH_handling
>>
>> Which version of CMake are you using?
>> On which system ?
>>
>>
>>
>
> We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.
>
> I've read the hints on RPATH handling, but there it is said, that:
> "By default if you don't change any RPATH related settings, CMake will link
> the executables and shared libraries with full RPATH to all used libraries
> in the build tree"

Yes.
And you did not mention it but the probleme you have occurs when using
the executable **directly from the build dir** right?

> This means, if I don't set anything related to RPATH, cmake should not strip
> the path from the library, should it?

No it shoudn't for the binary in the buitd tree but...
if you do "make install" the installed binaries will have no RPATH unless
you set

SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")

# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

> I played with the example and it was a bit hard to understand, when the path
> is stripped from the library.
> The problem arises before linking the executable.

This is a different issue.
Could you copy/paste the

add_executable
and
target_link_libraries

statement you use for the offending executable?

> We link to a library, which exists in two different directories:
> /usr/lib64
> and
> somewhere/lib/

This should be resolved by YOU inside CMakeLists.txt by

target_link_libraries(exename /path/to/appropriate/lib/lbname.so)

the
/path/to/appropriate/lib/lbname.so could be the result of an appropriate
find_library
call.

> At the same time, the environment variable LIBRARY_PATH is set to
> somewhere/lib. In this case, cmake removes the path from the library name,
> but does not append it as -L to the linker search paths.
> Now it is up to the linker to choose the right library, which is really bad!
> In our case (gcc 4.1.2 on Suse) it selects the wrong library.
>
> Is there any possibility to avoid this "environmentvariable dependent"
> splitting?

Yes full RPATH should be the solution.


-- 
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] library path stripping


Am 08.06.2011 11:56, schrieb Eric Noulard:

2011/6/8 Andreas Naumann:
   

Hi @all,

I have some problem with the library usage in cmake.

It seems to me, that cmake removes the full path of the library, if the path
is in the environment variable LIBRARY_PATH.
This behaviour cause problems at our system, such that the linker links
against the wrong library.

Is there an option to avoid this splitting?
 

Did you read that:
http://www.cmake.org/Wiki/CMake_RPATH_handling

Which version of CMake are you using?
On which system ?


   

We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.

I've read the hints on RPATH handling, but there it is said, that:
"By default if you don't change any RPATH related settings, CMake will 
link the executables and shared libraries with full RPATH to all used 
libraries in the build tree"


This means, if I don't set anything related to RPATH, cmake should not 
strip the path from the library, should it?


I played with the example and it was a bit hard to understand, when the 
path is stripped from the library.
The problem arises before linking the executable. We link to a library, 
which exists in two different directories:

/usr/lib64
and
somewhere/lib/

At the same time, the environment variable LIBRARY_PATH is set to 
somewhere/lib. In this case, cmake removes the path from the library 
name, but does not append it as -L to the linker search paths.
Now it is up to the linker to choose the right library, which is really 
bad! In our case (gcc 4.1.2 on Suse) it selects the wrong library.


Is there any possibility to avoid this "environmentvariable dependent" 
splitting?



___
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] ToolChain file scope

2011-06-08 Thread Kishore

On Tuesday 07 Jun 2011 7:40:33 PM dfurt...@cox.net wrote:
> I have been hammergin on a vxworks cross-compile toolchain file. It seems
> that not all properties that are set in the cross-compilation file
> propogate to the CMakeLists.txt file that is using it. An example is the
> CMAKE_AR property.  Setting it in the cross-compilation file had no effect
> and the value during linking of a static library was "'. Once I moved it to
> the CMakeLists.txt file the setting was recognized. Setting of library
> prefix and postfix values seemed to behave the same way.
> 
> These things seem like reasonable targets for the cross-compilation file so
> I am confused as to why they wouldn't work. Any help is appreciated.

I would be interested in this information too. Too often i get bitten by the 
scope issues when working with "Generic" embedded systems. In addition, I 
would also like the scope of the three platform/* modules to be documented as 
well.
-- 
Cheers!
Kishore
___
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] library path stripping

2011/6/8 Andreas Naumann :
> Hi @all,
>
> I have some problem with the library usage in cmake.
>
> It seems to me, that cmake removes the full path of the library, if the path
> is in the environment variable LIBRARY_PATH.
> This behaviour cause problems at our system, such that the linker links
> against the wrong library.
>
> Is there an option to avoid this splitting?

Did you read that:
http://www.cmake.org/Wiki/CMake_RPATH_handling

Which version of CMake are you using?
On which system ?


-- 
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] Binary packages naming convention

2011/6/7 Jean-Christophe Fillion-Robin :
> Hi Folks,
>
> I observed there are different ways of naming binary packages:
>
>    myproject-Linux-i386.{ext}
>    myproject-Linux-amd64.{ext}
>    myproject-Linux-x86_32.{ext}
>    myproject-Linux-x86_64.{ext}
>
>    myproject-Windows-win32_x86.{ext}
>    myproject-Windows-win64_x86.{ext}
>    myproject-Windows-win64_x64.{ext}
>    myproject-Windows-x86_32.{ext}
>    myproject-Windows-x86_64.{ext}
>
>    myproject-Darwin-amd64.{ext}
>
>    ...
>
> Was wondering which naming scheme should I favor ?
>
> I am thinking to use:
>    myproject-Linux-i386.{ext}
>    myproject-Linux-amd64.{ext}
>    myproject-Windows-win32_x86.{ext}
>    myproject-Windows-win64_x86.{ext}
>    myproject-Darwin-amd64.{ext}
>
> If there any reason I shouldn't choose that convention ?

The naming convention may depends on:
   - the host system (Windows, MacOS, Linux, Soalris etc...)
   - the package format (RPM, DEB, Package Maker etc...)
   - in the Linux case the distribution convention
  Fedora and OpenSuSE are RPM-based but they do not necesseraly
use the same naming scheme.
  same problem with Debian / Ubuntu for DEB.

So I think the appropriate naming scheme could be enforced (or at
least suggested) by
the CPack generator, this is now possible since 2.8.3:
http://public.kitware.com/Bug/view.php?id=9900

And some bug are open for that:
http://public.kitware.com/Bug/view.php?id=11050

So at least on Linux I would suggest to try to do it at CPack level.
On the Windows side you may want to mangle the package name depending
on the name
of the compiler used. If your package includes devel. lib knowing that
it has been compiled
with MSVC or MinGW could be useful.
In the same way may be "Windows" is not enough and you would want
WinXP/WinVISTA.

I did write some preliminary CMake scripts in order to do such
specific system informations,
find it attached to the mail.


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org


SystemSpecificInformations.cmake
Description: Binary data
___
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] library path stripping