[CMake] CDash Dynamic Analysis

[Mika . Rajala]

Hi

I'm trying to integrate custom tools to CDash Dynamic analysis.

I'm not that certain on what is the way I should be going.

Is there a way to tell cmake to pick up lines from a program as defects in 
the custom tool submission xml?

Do i need to make a program that generates a valid xml file?

If so, where do I find the documentation on how to do it?

I downloaded the example XML files from http://www.itk.org/Wiki/CDash:XML

here is a part of it 

   
   
  
   
  Sep 15 19:36 CEST 
  644.3 
  
  

I think that I should modify the part "DefectList".
But this file doesn't give much information on what to do.

There was a XML Schema file as well, but it wasn't of much use.

  
   
   
   
   

-mika___
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] add_definition??

[Michael Wild]

On 04/13/2011 11:50 PM, klaas.holwerda wrote:
> Hi,
> 
> I use ADD_DEFINITIONS( ${wxWidgets_DEFINITIONS} ) to add flags for
> compilation like this:
> 
> set( wxWidgets_CXX_FLAGS ${wxWidgets_CXX_FLAGS}
> -D__WXMSW__ -D__GNUWIN32__ -D__WIN95__
> -fexceptions -fno-pcc-struct-return
> -fstrict-aliasing
> -Wall#all warnings
> -Wno-unused-variable
>  )
> 
> Now a user complains that those flags are added to CXX_FLAGS as well as
> RC_FLAGS .
> The first is right, the second is a problem for the resource compiler
> windres.exe used in codeblocks IDE.
> 
> What is the right way to set compiler flags for cpp sources and other
> flags for the resource compiler?
> 
> Or are the generated makefiles not correct??
> 
> Thanks,
> 
> Klaas

If you think about the name of the function, adding anything but
preprocessor definitions is just plain wrong. Append them to the
CMAKE_CXX_FLAGS variable instead.

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] DESTDIR behaviour with different variable name

[Michael Hertling]

On 04/12/2011 04:36 PM, Tomasz Grobelny wrote:
> On Tue, 12 Apr 2011 03:44:04 +0200, Michael Hertling 
> wrote:
>> On 04/11/2011 10:42 PM, Tomasz Grobelny wrote:
>>> On Monday 11 April 2011 21:55:48 Alexander Neundorf wrote:
 On Monday 11 April 2011, Tomasz Grobelny wrote:
> On Mon, 11 Apr 2011 09:01:09 -0700, Tyler  wrote:
>> On Mon, Apr 11, 2011 at 8:54 AM, Tomasz Grobelny
>>
>>  wrote:
>>> Ok, but is there a way to achieve the same effect so that the user
>>> can
>>> type just "make install" and not know anything about DESTDIR
> environment
>>> variable (provided he knows about MYDESTDIR)? Maybe it is possible
> to
>>> put this "DESTDIR=$MYDESTDIR" in the generated Makefiles somehow...
>>
>> If I understand your use case right (which I might not as you
> haven't
>> described what you're trying to do, just how you're trying to do
> it),
>> maybe you can just override CMAKE_INSTALL_PREFIX.
>>
>> If you go this route, check the archives because of the whole
>> _INITIALIZED_TO_DEFAULT aspect of that particular cache variable.
>
> I already tried playing with CMAKE_INSTALL_PREFIX but the problem was
> that value of MYDESTDIR was read (and saved to CMAKE_INSTALL_PREFIX)
> only when configuring first time. That's why DESTDIR mechanism comes
> closer to what I'm trying to achieve. My use case is something like
> that:
> 1. User has some default MYDESTDIR to non writable location.
> 2. User executes "cmake . && make install".
> 3. The installation fails because user has no rights to $MYDESTDIR.
> 4. User changes MYDESTDIR to another location (writable this time).
> 5. User executes "make install" once again and it should succeed.
>
> Of course the user could set MYDESTDIR to correct location before
> building but people often forget that. Now the tricky part is that
> users
> are already used to this mechanism (for particular variable name,
> called
> MYDESTDIR here). So taking different environment variable instead of
> DESTDIR would allow me to minimize confusion among users. Otherwise
> I'll
> just tell them to set yet another variable (DESTDIR). But I would
> like
> to avoid that if at all possible.

 DESTDIR has a different purpose.
 Installing to DESTDIR does not necessarily lead to a working and
> correct
 installation, mainly when paths are involved, like e.g. RPATH
> settings.
 Assuming that CMAKE_INSTALL_PREFIX would be /opt/foo, your executable
 might
 get /opt/foo/lib as RPATH, also when installed to $DESTDIR/opt/foo.
 So they will not have a correct RPATH.
 You really should set CMAKE_INSTALL_PREFIX.

>>> I'd like to. But CMAKE_INSTALL_PREFIX does not get recomputed when I
>>> change
>>> MYDESTDIR and try to do "make install" again. Or at least I don't know
>>> how to
>>> make it behave this way.
>>> Besides, I don't use RPATH (at least not explicitely, hopefully cmake
> is
>>> not
>>> doing anything nasty behind the scenes).
>>
>> But some day, you might want to use RPATH features as they are very
>> convenient in certain situations, or you might want to incorporate
>> the installation prefix or derivatives like CMAKE_INSTALL_PREFIX/lib
>> /${PROJECT_NAME} in your binaries which can be quite convenient, too.
>> Moreover, you can hardly prevent your project's users to use RPATH on
>> their own, see the CMAKE_INSTALL_RPATH/CMAKE_BUILD_WITH_INSTALL_RPATH
>> variables, e.g. In this regard, using the DESTDIR Makefile/environment
>> variable bears the risk of subtle failures and isn't worth the effort,
>> IMO. Thus, you should take Alex's warning absolutely seriously, or in
>> other words: Changing the installation prefix does invalidate your
>> already built targets, so you do need to reconfigure and rebuild.
>>
>> Anyway, see [1] for a chance to add "DESTDIR=$MYDESTDIR" to the
>> generated Makefiles, provided that you are using GNU Make, but
>> even this won't work as expected since DESTDIR is hard-coded
>> in CMake, AFAIK, and due to other reasons.
>>
>> [1] http://www.mail-archive.com/cmake@cmake.org/msg34344.html
>>
> Somewhat hackish (especially this \$\(firstword \$\(MAKEFILE_LIST\)\)

Hackish, ugly, non-portable and absolutely inadvisable. ;-)

> part). I've just come up with another solution (probably not less hackish,
> but simpler and working):
> set(CMAKE_INSTALL_PREFIX "\$ENV{MYDESTDIR}")

That's not hackish, IMO, but even quite elegant, indeed. Nevertheless,
the limitations and risks mentioned earlier in this thread still hold.
A rather obvious example for the shortcomings of that approach is the
installation of a configuration file for the concerned package; see
the following CMakeLists.txt for a highly rudimentary realisation:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(MYDESTDIR C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(CMAKE_INSTALL_PREFIX "\$ENV{MYDESTDIR}")
FILE(WRITE ${CMAKE_BIN

Re: [CMake] embedded path in shared library linked into another shared library

[Michael Hertling]

On 04/13/2011 08:52 PM, Alexander Neundorf wrote:
> On Tuesday 12 April 2011, Michael Hertling wrote:
>> On 04/11/2011 11:10 PM, David Aiken wrote:
>>> That didn't work for me.. I've got it simplified down to:
>>> SET(CMAKE_SKIP_RPATH TRUE)
>>> and in the CMakeCache.txt I see:
>>> CMAKE_SKIP_RPATH:BOOL=NO
>>
>> That's not surprising as your SET() command doesn't write to the cache.
>> It's the CMAKE_SKIP_RPATH variable's value in the current scope which
>> is - should be - crucial for dropping the RPATH settings, AFAIK.
>>
>>> I'm using the codeblocks unix makefile target. The rpath is present in
>>> both the build and install shared library.
>>
>> With the UnixMakefile generator, I can see the following CMakeLists.txt
>>
>> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
>> PROJECT(RPATH C)
>> SET(CMAKE_VERBOSE_MAKEFILE ON)
>> SET(CMAKE_SKIP_RPATH TRUE)
>> FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
>> ADD_LIBRARY(f SHARED f.c)
>> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
>> ADD_EXECUTABLE(main main.c)
>> TARGET_LINK_LIBRARIES(main f)
>>
>> produce the following command line to link:
>>
>> .../gcc CMakeFiles/main.dir/main.c.o -o main -rdynamic libf.so
>>
>> I.e., no RPATH for the executable.
> 
> Yes, but this is because you did not link against a library with a path. So 
> you don't get any RPATH.
> TARGET_LINK_LIBRARIES(main /opt/foo/libf.so)
> would give you an RPATH in this command.

AFAICS, that's not true. Look at the following CMakeLists.txt:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(RPATH C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(CMAKE_SKIP_RPATH TRUE)
FILE(WRITE /dev/shm/libf.so "")
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main /dev/shm/libf.so)

The command which links the executable is

.../gcc CMakeFiles/main.dir/main.c.o -o main -rdynamic -L/dev/shm -lf

i.e. still no RPATH for the executable, although the command fails due
to the invalid empty libf.so, of course. Specifying a full path for a
library in TARGET_LINK_LIBRARIES() does not overwrite RPATH settings;
in particular, the CMAKE_SKIP_RPATH set to TRUE keeps being effective.
When linking against a valid library, however, you get the library's
full path on the link command line instead of the -L/-l combination
unless the library is placed in a well-known system directory, but
still no RPATH as long as CMAKE_SKIP_RPATH is set to TRUE.

>> Does the above-noted CMakeLists.txt actually produce different results
>> w.r.t. the RPATHs when using the CodeBlocksUnixMakefiles generator?
> 
> Should be impossible, because the CodeBlocks generator simply generates the 
> normal makefiles, and additionally the codeblocks xml project files.

This is why I suppose that the OP's issue is caused by something else.

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

[CMake] add_definition??

[klaas.holwerda]

Hi,

I use ADD_DEFINITIONS( ${wxWidgets_DEFINITIONS} ) to add flags for compilation 
like this:

set( wxWidgets_CXX_FLAGS ${wxWidgets_CXX_FLAGS}
-D__WXMSW__ -D__GNUWIN32__ -D__WIN95__
-fexceptions -fno-pcc-struct-return
-fstrict-aliasing
-Wall#all warnings
-Wno-unused-variable
 )

Now a user complains that those flags are added to CXX_FLAGS as well as 
RC_FLAGS .
The first is right, the second is a problem for the resource compiler windres.exe used in codeblocks 
IDE.


What is the right way to set compiler flags for cpp sources and other flags for 
the resource compiler?

Or are the generated makefiles not correct??

Thanks,

Klaas
___
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] Finding dynamic libraries with major interface revision numbers (2)

[Jean-Christophe Fillion-Robin]

Thanks Michael

Doing the following ends up working ...

IF(UNIX)
  # If the faster 'gold' linker is used, to avoid complaints about undefined
symbol
  # '_gfortran_concat_string', '_gfortran_pow_i4_i4', ... , let's link
against gfortran libraries.
  # These errors happen while linking against VTK static built with R
support
  SET(CMAKE_FIND_LIBRARY_SUFFIXES_SAVED ${CMAKE_FIND_LIBRARY_SUFFIXES}) #
Backup
  LIST(APPEND CMAKE_FIND_LIBRARY_SUFFIXES ".so.3")
  FIND_LIBRARY(GFortran_LIBRARY gfortran)
  SET(CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_FIND_LIBRARY_SUFFIXES_SAVED}) #
Restore
  LIST(APPEND EXTRA_LIBRARIES ${GFortran_LIBRARY})
ENDIF()

Thanks
Jc


On Wed, Apr 13, 2011 at 4:08 PM, Michael Hertling wrote:

> On 04/13/2011 09:26 PM, Brad King wrote:
> > On 04/13/2011 02:44 PM, Jean-Christophe Fillion-Robin wrote:
> >> Is there a solution to find a library having a revision number ?
> >
> > You can specify the actual library file name "libgfortran.so.3".
>
> AFAIK, this is not sufficient because FIND_LIBRARY() only looks for
> library files - specified literally or not - which end with a suffix
> mentioned in FIND_LIBRARY_SUFFIXES. See the following CMakeLists.txt:
>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> PROJECT(XYZ NONE)
> SET(CMAKE_VERBOSE_MAKEFILE ON)
> FILE(WRITE ${CMAKE_BINARY_DIR}/libxyz.so.3 "")
> SET(CMAKE_FIND_LIBRARY_SUFFIXES ".so.3")
> FIND_LIBRARY(XYZ libxyz.so.3 PATHS ${CMAKE_BINARY_DIR} NO_DEFAULT_PATH)
> MESSAGE("XYZ: ${XYZ}")
>
> First, ${CMAKE_BINARY_DIR}/libxyz.so.3 is found, but if you remove the
> SET(CMAKE_FIND_LIBRARY_SUFFIXES ...) command and unset the XYZ cache
> entry, you'll probably see libxyz.so.3 not being found anymore. It is
> cmFindLibraryHelper::SetName() that implements this behaviour, if I'm
> not mistaken. So, a possible workaround is to temporarily add ".so.3"
> or whatever is desired to CMAKE_FIND_LIBRARY_SUFFIXES before calling
> FIND_LIBRARY(), cf. [1].
>
> Regards,
>
> Michael
>
> [1] http://www.mail-archive.com/cmake@cmake.org/msg35219.html
> ___
> 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

Re: [CMake] Finding dynamic libraries with major interface revision numbers (2)

[Jean-Christophe Fillion-Robin]

Yes it does ... see below

Does that mean I specified something incorrectly within my project ?

Note also that the problem occurs only when VTK is built statically ...

Jc

readelf -d /home/jchris/Projects/R-2.11.1/lib64/R/lib/libR.so |grep NEEDED
 0x0001 (NEEDED) Shared library: [libRblas.so]
* 0x0001 (NEEDED) Shared library: [libgfortran.so.3]
*
 0x0001 (NEEDED) Shared library: [libm.so.6]
 0x0001 (NEEDED) Shared library: [libreadline.so.6]
 0x0001 (NEEDED) Shared library: [libdl.so.2]
 0x0001 (NEEDED) Shared library: [libc.so.6]
 0x0001 (NEEDED) Shared library:
[ld-linux-x86-64.so.2]

readelf -d /home/jchris/Projects/R-2.11.1/lib64/R/lib/libRlapack.so |grep
NEEDED
 0x0001 (NEEDED) Shared library: [libRblas.so]
 0x0001 (NEEDED) Shared library: [libc.so.6]

readelf -d /home/jchris/Projects/R-2.11.1/lib64/R/lib/libRblas.so |grep
NEEDED
* 0x0001 (NEEDED) Shared library: [libgfortran.so.3]
*
 0x0001 (NEEDED) Shared library: [libm.so.6]
 0x0001 (NEEDED) Shared library: [libc.so.6]


On Wed, Apr 13, 2011 at 3:56 PM, Brad King  wrote:

> On 04/13/2011 03:37 PM, Jean-Christophe Fillion-Robin wrote:
> > 1) I have a project XYZ that linked against VTK static which also linked
> > GnuR shared
> [snip]
> > /usr/bin/ld: /home/jchris/Projects/R-2.11.1/lib64/R/lib/libRlapack.so:
> > error: undefined reference to '_gfortran_concat_string'
>
> Doesn't GnuR's so list gfortran as a dependency?  For example, lapack does:
>
> $ readelf -d /usr/lib/liblapack.so |grep NEEDED
>  0x0001 (NEEDED) Shared library: [libblas.so.3gf]
>  0x0001 (NEEDED) Shared library: [libgfortran.so.3]
>  0x0001 (NEEDED) Shared library: [libm.so.6]
>  0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
>  0x0001 (NEEDED) Shared library: [libc.so.6]
>
> -Brad
>



-- 
+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] Finding dynamic libraries with major interface revision numbers (2)

[Michael Hertling]

On 04/13/2011 09:26 PM, Brad King wrote:
> On 04/13/2011 02:44 PM, Jean-Christophe Fillion-Robin wrote:
>> Is there a solution to find a library having a revision number ?
> 
> You can specify the actual library file name "libgfortran.so.3".

AFAIK, this is not sufficient because FIND_LIBRARY() only looks for
library files - specified literally or not - which end with a suffix
mentioned in FIND_LIBRARY_SUFFIXES. See the following CMakeLists.txt:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(XYZ NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/libxyz.so.3 "")
SET(CMAKE_FIND_LIBRARY_SUFFIXES ".so.3")
FIND_LIBRARY(XYZ libxyz.so.3 PATHS ${CMAKE_BINARY_DIR} NO_DEFAULT_PATH)
MESSAGE("XYZ: ${XYZ}")

First, ${CMAKE_BINARY_DIR}/libxyz.so.3 is found, but if you remove the
SET(CMAKE_FIND_LIBRARY_SUFFIXES ...) command and unset the XYZ cache
entry, you'll probably see libxyz.so.3 not being found anymore. It is
cmFindLibraryHelper::SetName() that implements this behaviour, if I'm
not mistaken. So, a possible workaround is to temporarily add ".so.3"
or whatever is desired to CMAKE_FIND_LIBRARY_SUFFIXES before calling
FIND_LIBRARY(), cf. [1].

Regards,

Michael

[1] http://www.mail-archive.com/cmake@cmake.org/msg35219.html
___
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] Finding dynamic libraries with major interface revision numbers (2)

[Brad King]

On 04/13/2011 03:37 PM, Jean-Christophe Fillion-Robin wrote:
> 1) I have a project XYZ that linked against VTK static which also linked
> GnuR shared
[snip]
> /usr/bin/ld: /home/jchris/Projects/R-2.11.1/lib64/R/lib/libRlapack.so:
> error: undefined reference to '_gfortran_concat_string'

Doesn't GnuR's so list gfortran as a dependency?  For example, lapack does:

$ readelf -d /usr/lib/liblapack.so |grep NEEDED
 0x0001 (NEEDED) Shared library: [libblas.so.3gf]
 0x0001 (NEEDED) Shared library: [libgfortran.so.3]
 0x0001 (NEEDED) Shared library: [libm.so.6]
 0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
 0x0001 (NEEDED) Shared library: [libc.so.6]

-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] Finding dynamic libraries with major interface revision numbers (2)

[Jean-Christophe Fillion-Robin]

On Wed, Apr 13, 2011 at 3:26 PM, Brad King  wrote:

> On 04/13/2011 02:44 PM, Jean-Christophe Fillion-Robin wrote:
> > Is there a solution to find a library having a revision number ?
>
> You can specify the actual library file name "libgfortran.so.3".
>
Great

>
> However, you shouldn't need to find implicit compiler runtime libraries.
> Are you trying to mix C++ and Fortran?
>

More details ...

1) I have a project XYZ that linked against VTK static which also linked
GnuR shared

2) Using the faster Gold linker  (/usr/bin/ld -> /usr/bin/ld.gold)

3) If building against VTK-shared there is no issue, if building against
VTK-static,

tThe following undefined symbol errors arise:

/usr/bin/ld: /home/jchris/Projects/R-2.11.1/lib64/R/lib/libRlapack.so:
error: undefined reference to '_gfortran_concat_string'
/usr/bin/ld: /home/jchris/Projects/R-2.11.1/lib64/R/lib/libRlapack.so:
error: undefined reference to '_gfortran_pow_i4_i4'
/usr/bin/ld: /home/jchris/Projects/R-2.11.1/lib64/R/lib/libRlapack.so:
error: undefined reference to '_gfortran_compare_string'


>
> > Within cmake, is there a possibility to retrieve the lib directories
> > associated with the current compiler ?
>
> CMake 2.8.x already does this.  Look in the CMakeFiles/CMake*Compiler.cmake
> files in your build tree.  However, these variables are generally meant
> for internal use by the link line computation code.
>
Good to know


> If a binary contains sources from both C++ and Fortran CMake already knows
> how to link it with C++ and pass the Fortran runtime libraries on the link
> line.
>
> -Brad
>



-- 
+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] Finding dynamic libraries with major interface revision numbers (2)

[Brad King]

On 04/13/2011 02:44 PM, Jean-Christophe Fillion-Robin wrote:
> Is there a solution to find a library having a revision number ?

You can specify the actual library file name "libgfortran.so.3".

However, you shouldn't need to find implicit compiler runtime libraries.
Are you trying to mix C++ and Fortran?

> Within cmake, is there a possibility to retrieve the lib directories
> associated with the current compiler ?

CMake 2.8.x already does this.  Look in the CMakeFiles/CMake*Compiler.cmake
files in your build tree.  However, these variables are generally meant
for internal use by the link line computation code.

If a binary contains sources from both C++ and Fortran CMake already knows
how to link it with C++ and pass the Fortran runtime libraries on the link
line.

-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] embedded path in shared library linked into another shared library

[Alexander Neundorf]

On Tuesday 12 April 2011, Michael Hertling wrote:
> On 04/11/2011 11:10 PM, David Aiken wrote:
> > That didn't work for me.. I've got it simplified down to:
> > SET(CMAKE_SKIP_RPATH TRUE)
> > and in the CMakeCache.txt I see:
> > CMAKE_SKIP_RPATH:BOOL=NO
>
> That's not surprising as your SET() command doesn't write to the cache.
> It's the CMAKE_SKIP_RPATH variable's value in the current scope which
> is - should be - crucial for dropping the RPATH settings, AFAIK.
>
> > and further down:
> > CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1
> >
> > I'm using the codeblocks unix makefile target. The rpath is present in
> > both the build and install shared library.
>
> With the UnixMakefile generator, I can see the following CMakeLists.txt
>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> PROJECT(RPATH C)
> SET(CMAKE_VERBOSE_MAKEFILE ON)
> SET(CMAKE_SKIP_RPATH TRUE)
> FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
> ADD_LIBRARY(f SHARED f.c)
> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
> ADD_EXECUTABLE(main main.c)
> TARGET_LINK_LIBRARIES(main f)
>
> produce the following command line to link:
>
> .../gcc CMakeFiles/main.dir/main.c.o -o main -rdynamic libf.so
>
> I.e., no RPATH for the executable.

Yes, but this is because you did not link against a library with a path. So 
you don't get any RPATH.
TARGET_LINK_LIBRARIES(main /opt/foo/libf.so)
would give you an RPATH in this command.

But this RPATH would be patched out on make install.

> Does the above-noted CMakeLists.txt actually produce different results
> w.r.t. the RPATHs when using the CodeBlocksUnixMakefiles generator?

Should be impossible, because the CodeBlocks generator simply generates the 
normal makefiles, and additionally the codeblocks xml project files.

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

[CMake] Finding dynamic libraries with major interface revision numbers (2)

[Jean-Christophe Fillion-Robin]

Hi Folks,

Is there a solution to find a library having a revision number ?

For example, on Ubuntu, after I installed 'libgfortran3', there is the
library /usr/lib/libgfortran.so.3

then the following command failed:  FIND_LIBRARY(GFortran_LIBRARY gfortran)

If I create the symlink  /usr/lib/libgfortran.so ->
/usr/lib/libgfortran.so.3  , it works.

The issue has already been discussed here:
http://www.cmake.org/pipermail/cmake/2011-January/042392.html

Out of curiosity, Is there any known workaround ... ?

Issuing the command: apt-file search "gfortran.so"   it reveals the
following:

[...]
gfortran-4.4: /usr/lib/gcc/x86_64-linux-gnu/4.4/libgfortran.so
[...]
libgfortran3: /usr/lib/libgfortran.so.3
libgfortran3: /usr/lib/libgfortran.so.3.0.0
[...]

Within cmake, is there a possibility to retrieve the lib directories
associated with the current compiler ?

I could then add these one to the PATHS arguments of the find library
command ...

Thanks
Jc


-- 
+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] Fwd: Adding custom directories to PATH enviroment

[Michael Wild]

On 04/13/2011 05:52 PM, Gabriele Greco wrote:
> Then you haven't read or understood my message ;-) Instead of calling
> idlcc directly in the add_custom_command, you call a wrapper script,
> that sets the PATH environment variable, and *then* invokes idlcc.
> 
> 
> Ok, I implemented your solution and it works, thanks!

Great!

> 
> One additional comment: Creating output in the source tree is a *very*
> bad habit. Some people (including me) consider it to be obscene... ;-)
> Unless you are doing an in-source build (which you shouldn't, for the
> same reasons you shouldn't create output in the source tree), a build
> system should *never* modify the source tree.
> 
> 
> Yeah, you are right, I didn't like that too, I've changed the system to
> output the interfaces in ${PROJECT_BINARY_DIR}/inc/intf,
> the only thing I don't like is that to make this work, inside the
> "interface" CMakeLists.txt I've had to insert this:
> 
> execute_process(
> COMMAND cp -r "${PROJECT_SOURCE_DIR}/inc/intf" "${PROJECT_BINARY_DIR}/inc/"
> )

That's clunky and not portable, see below for the commonly used solution.

> 
> To copy the interface files that are actually hand written and then
> committed to the repository in the binary path.
> 
> It works, but I suppose I should add a mechanism to copy one of these
> files again if the user changes it... And i fear the only way to do it
> is to add a list of all these files by hand to the interfaces
> CMakeLists.txt and make the copy process a custom target that depends
> from the file in the source tree
> 
> -- 
> Bye,
>  Gabry

You're right about the explicit listing, but you should do the copying
using configure_file(... COPYONLY). And don't even think about using
file(GLOB) and friends, that's usually the wrong approach.

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] Fwd: Adding custom directories to PATH enviroment

[Gabriele Greco]

>
> Then you haven't read or understood my message ;-) Instead of calling
> idlcc directly in the add_custom_command, you call a wrapper script,
> that sets the PATH environment variable, and *then* invokes idlcc.
>

Ok, I implemented your solution and it works, thanks!

One additional comment: Creating output in the source tree is a *very*
> bad habit. Some people (including me) consider it to be obscene... ;-)
> Unless you are doing an in-source build (which you shouldn't, for the
> same reasons you shouldn't create output in the source tree), a build
> system should *never* modify the source tree.
>

Yeah, you are right, I didn't like that too, I've changed the system to
output the interfaces in ${PROJECT_BINARY_DIR}/inc/intf,
the only thing I don't like is that to make this work, inside the
"interface" CMakeLists.txt I've had to insert this:

execute_process(
COMMAND cp -r "${PROJECT_SOURCE_DIR}/inc/intf" "${PROJECT_BINARY_DIR}/inc/"
)

To copy the interface files that are actually hand written and then
committed to the repository in the binary path.

It works, but I suppose I should add a mechanism to copy one of these files
again if the user changes it... And i fear the only way to do it is to add a
list of all these files by hand to the interfaces CMakeLists.txt and make
the copy process a custom target that depends from the file in the source
tree

-- 
Bye,
 Gabry
___
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] Confusing problem with building VTK via external project

[kent williams]

Strange as it may seem, there must have been something fracked up in
my Emacs environment because this craziness went away when I restarted
Emacs.  Though the particulars of how this began are mysterious.

On Wed, Apr 13, 2011 at 10:26 AM, David Cole  wrote:
> On Wed, Apr 13, 2011 at 11:04 AM, kent williams 
> wrote:
>>
>> I've all of a sudden started having trouble building VTK via an
>> ExternalProject.  OS X, CMake 2.8.4, Standard GCC 4.2 compilers, stock
>> VTK 5.6.1.
>>
>> output of make VERBOSE=1 of the top-level project, you can see that
>> QT_QMAKE_EXECUTABLE is set, but when CMake runs, it somehow ignores
>> the variables set on the command line.  The only clue I can see is
>> this line:
>>
>> Re-run cmake no build system arguments
>>
>> What's going on?
>>
>> [  0%] Performing configure step for 'VTK'
>> cd /scratch/kent/Testing/pandora.psychiatry.uiowa.edu/Fast/VTK-build
>> && "/opt/cmake-2.8.4-Darwin-universal/CMake
>> 2.8-4.app/Contents/bin/cmake"
>>
>> -DCMAKE_INSTALL_PREFIX:PATH=/scratch/kent/Testing/pandora.psychiatry.uiowa.edu/Fast/src
>> -DCMAKE_CXX_COMPILER:STRING=/usr/bin/c++
>> -DCMAKE_CXX_COMPILER_ARG1:STRING=
>> ...
>
>
>>
>> -- Performing Test HAVE_GCC_ERROR_RETURN_TYPE
>> -- Performing Test HAVE_GCC_ERROR_RETURN_TYPE - Success
>> -- Performing Test HAVE_GCC_VISIBILITY
>> -- Performing Test HAVE_GCC_VISIBILITY - Success
>> -- Performing Test Support for 64 bit file systems
>> -- Performing Test Support for 64 bit file systems - Success
>> CMake Error at CMakeLists.txt:307 (MESSAGE):
>>  Qt 4.5.0 or greater not found.  Please check the QT_QMAKE_EXECUTABLE
>>  variable.
>>
>>
>> -- Looking for XOpenDisplay in
>> /opt/local/lib/libX11.dylib;/opt/local/lib/libXext.dylib
>
>
> The error message reported is:
> CMake Error at CMakeLists.txt:307 (MESSAGE):
>  Qt 4.5.0 or greater not found.  Please check the QT_QMAKE_EXECUTABLE
>  variable.
>
> What does "/usr/bin/qmake --version" report?
>
> Is it an older Qt? Did you change the system Qt recently?
>
>
> HTH,
> David
>
>
___
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] Confusing problem with building VTK via external project

[David Cole]

On Wed, Apr 13, 2011 at 11:04 AM, kent williams
wrote:

> I've all of a sudden started having trouble building VTK via an
> ExternalProject.  OS X, CMake 2.8.4, Standard GCC 4.2 compilers, stock
> VTK 5.6.1.
>
> output of make VERBOSE=1 of the top-level project, you can see that
> QT_QMAKE_EXECUTABLE is set, but when CMake runs, it somehow ignores
> the variables set on the command line.  The only clue I can see is
> this line:
>
> Re-run cmake no build system arguments
>
> What's going on?
>
> [  0%] Performing configure step for 'VTK'
> cd /scratch/kent/Testing/pandora.psychiatry.uiowa.edu/Fast/VTK-build
> && 
> "/opt/cmake-2.8.4-Darwin-universal/CMake
> 2.8-4.app/Contents/bin/cmake"
> -DCMAKE_INSTALL_PREFIX:PATH=/scratch/kent/Testing/
> pandora.psychiatry.uiowa.edu/Fast/src
> -DCMAKE_CXX_COMPILER:STRING=/usr/bin/c++
> -DCMAKE_CXX_COMPILER_ARG1:STRING=
> ...




> -- Performing Test HAVE_GCC_ERROR_RETURN_TYPE
> -- Performing Test HAVE_GCC_ERROR_RETURN_TYPE - Success
> -- Performing Test HAVE_GCC_VISIBILITY
> -- Performing Test HAVE_GCC_VISIBILITY - Success
> -- Performing Test Support for 64 bit file systems
> -- Performing Test Support for 64 bit file systems - Success
> CMake Error at CMakeLists.txt:307 (MESSAGE):
>  Qt 4.5.0 or greater not found.  Please check the QT_QMAKE_EXECUTABLE
>  variable.
>
>
> -- Looking for XOpenDisplay in
> /opt/local/lib/libX11.dylib;/opt/local/lib/libXext.dylib
>


The error message reported is:
CMake Error at CMakeLists.txt:307 (MESSAGE):
 Qt 4.5.0 or greater not found.  Please check the QT_QMAKE_EXECUTABLE
 variable.

What does "/usr/bin/qmake --version" report?

Is it an older Qt? Did you change the system Qt recently?


HTH,
David
___
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] Confusing problem with building VTK via external project

[kent williams]

I've all of a sudden started having trouble building VTK via an
ExternalProject.  OS X, CMake 2.8.4, Standard GCC 4.2 compilers, stock
VTK 5.6.1.

output of make VERBOSE=1 of the top-level project, you can see that
QT_QMAKE_EXECUTABLE is set, but when CMake runs, it somehow ignores
the variables set on the command line.  The only clue I can see is
this line:

Re-run cmake no build system arguments

What's going on?

[  0%] Performing configure step for 'VTK'
cd /scratch/kent/Testing/pandora.psychiatry.uiowa.edu/Fast/VTK-build
&& "/opt/cmake-2.8.4-Darwin-universal/CMake
2.8-4.app/Contents/bin/cmake"
-DCMAKE_INSTALL_PREFIX:PATH=/scratch/kent/Testing/pandora.psychiatry.uiowa.edu/Fast/src
-DCMAKE_CXX_COMPILER:STRING=/usr/bin/c++
-DCMAKE_CXX_COMPILER_ARG1:STRING=
-DCMAKE_C_COMPILER:STRING=/usr/bin/gcc -DCMAKE_C_COMPILER_ARG1:STRING=
"-DCMAKE_CXX_FLAGS:STRING=  -Wall -Wextra -Wlong-long -fopenmp
-Wno-invalid-offsetof" "-DCMAKE_C_FLAGS:STRING=  -Wall -Wextra
-Wlong-long -fopenmp" -DBUILD_SHARED_LIBS:BOOL=ON
-DCMAKE_BUILD_TYPE:STRING=Release -DBUILD_EXAMPLES:BOOL=OFF
-DBUILD_TESTING:BOOL=OFF -DVTK_DEBUG_LEAKS:BOOL=ON
-DVTK_WRAP_TCL:BOOL=ON -DVTK_USE_RPATH:BOOL=ON
-DTCL_INCLUDE_PATH:PATH=/System/Library/Frameworks/Tcl.framework/Headers
-DTCL_LIBRARY:FILEPATH=/System/Library/Frameworks/tcl.framework
-DTCL_TCLSH:FILEPATH=/usr/bin/tclsh
-DTK_INCLUDE_PATH:PATH=/System/Library/Frameworks/Tk.framework/Headers
-DTK_LIBRARY:FILEPATH=/System/Library/Frameworks/tk.framework
-DVTK_WRAP_PYTHON:BOOL=OFF
-DPYTHON_INCLUDE_DIR:PATH=/scratch/kent/Testing/pandora.psychiatry.uiowa.edu/Fast/python-build/include/python2.6
-DPYTHON_LIBRARY:FILEPATH=/scratch/kent/Testing/pandora.psychiatry.uiowa.edu/Fast/python-build/lib/libpython2.6.dylib
-DVTK_USE_CARBON:BOOL=OFF -DVTK_USE_COCOA:BOOL=ON -DVTK_USE_X:BOOL=OFF
-DVTK_USE_RPATH:BOOL=ON -DDESIRED_QT_VERSION:STRING=4
-DVTK_USE_GUISUPPORT:BOOL=ON -DVTK_USE_QVTK_QTOPENGL:BOOL=ON
-DVTK_USE_RENDERING:BOOL=ON -DVTK_USE_QT:BOOL=ON
-DQT_QMAKE_EXECUTABLE:FILEPATH=/usr/bin/qmake
-DVTK_USE_PARALLEL:BOOL=ON "-GUnix Makefiles"
/scratch/kent/Testing/pandora.psychiatry.uiowa.edu/Fast/VTK
Re-run cmake no build system arguments
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- 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
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- 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
-- Performing Test HAVE_GCC_ERROR_RETURN_TYPE
-- Performing Test HAVE_GCC_ERROR_RETURN_TYPE - Success
-- Performing Test HAVE_GCC_VISIBILITY
-- Performing Test HAVE_GCC_VISIBILITY - Success
-- Performing Test Support for 64 bit file systems
-- Performing Test Support for 64 bit file systems - Success
CMake Error at CMakeLists.txt:307 (MESSAGE):
  Qt 4.5.0 or greater not found.  Please check the QT_QMAKE_EXECUTABLE
  variable.


-- Looking for XOpenDisplay in
/opt/local/lib/libX11.dylib;/opt/local/lib/libXext.dylib
-- Looking for XOpenDisplay in
/opt/local/lib/libX11.dylib;/opt/local/lib/libXext.dylib - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /opt/local/lib/libX11.dylib
-- Checking to see if CXX compiler accepts flag -no-cpp-precomp
-- Checking to see if CXX compiler accepts flag -no-cpp-precomp - Yes
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of int
-- Check size of int - done
-- Check size of long
-- Check size of long - done
-- Check size of void*
-- Check size of void* - done
-- Check size of char
-- Check size of char - done
-- Check size of short
-- Check size of short - done
-- Check size of float
-- Check size of float - done
-- Check size of double
-- Check size of double - done
-- Looking for include files CMAKE_HAVE_LIMITS_H
-- Looking for include files CMAKE_HAVE_LIMITS_H - found
-- Looking for include files CMAKE_HAVE_UNISTD_H
-- Looking for include files CMAKE_HAVE_UNISTD_H - found
-- Looking for include files CMAKE_HAVE_PTHREAD_H
-- Looking

Re: [CMake] Searchable mail archive

[Stephen Kelly]

J.S. van Bethlehem wrote:

> Dear CMake users,
> 
> This week I started to investigate possibilities to move my build-system
> over to CMake after hearing a lot of good stories about it. To be
> honest, so far I'm still not quite convinced. The learning (I find at
> least) is rather steep and the documentation rather sparse (afaics) Then
> I noticed this mailing list, which would obviously be a got source to
> look for help, if it were searchable - so that's my question: is there
> some mirror of the mail-archive where I can search through passed mails
> to the list?
> 

http://news.gmane.org/gmane.comp.programming.tools.cmake.user

___
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] Fwd: Adding custom directories to PATH enviroment

[Michael Wild]

On 04/13/2011 01:04 PM, Gabriele Greco wrote:
> 
> 
> 
> And then configure and run it like this:
> 
> CMakeLists.txt:
> ---
> # ...
> configure_file(foo_wrapper.cmake.in 
>"${CMAKE_CURRENT_BINARY_DIR}/foo_wrapper.cmake" @ONLY)
> add_custom_command(OUTPUT bar
>  COMMAND "${CMAKE_COMMAND}" -P
>"${CMAKE_CURRENT_BINARY_DIR}/foo_wrapper.cmake"
>  COMMENT "Creating bar")
> 
> 
> If you need to pass the script variables using the -D flags, make sure
> to pass them before the -P flag, otherwise they are silently ignored.
> 
> I hope you get the idea.
> 
> 
> 
> I fear I've not explained enough the problem. 
> 
> If I understood correctly your solution when in my CMakeLists.txt I
> execute the custom command "bar" what I obtain is that "foo" is called.
> 
> In my project I have some "IDL" files written in a custom format, those
> files require a preprocessing pass to be transformed in .h/.cpp, that I
> perform using add_custom_command() inside a macro 
> 
> ADD_CUSTOM_COMMAND(
>  OUTPUT ${PROJECT_SOURCE_DIR}/inc/intf/${_out_FILE}.h
>  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_in_FILE}
>  COMMAND idlcc
>  ARGS -V -S -s ${PROJECT_SOURCE_DIR}/inc/intf
> -I${PROJECT_SOURCE_DIR}/inc/intf -I${PROJECT_SOURCE_DIR}/inc
>  ${CMAKE_CURRENT_SOURCE_DIR}/${_in_FILE}
>  )
> 
> The command *idlcc* is bundled within the repository and is in the
> directory $PROJECT_SOURCE_DIR/ext_bin/DFC, I can call it directly with a
> path, changing
> 
> COMMAND idlcc
> 
> to
> 
> COMMAND ${PROJECT_SOURCE_DIR}/ext_bin/DFC/idlcc
> 
> ...but the problem is that idlcc calls its "second step", *dfc_idl*,
> that is in the same directory, and pretend it to be in the command
> search path.
> 
> the previous makefile used to do:
> 
> export PATH=$PROJECT_DIR/ext/bin/DFC:$PATH
> 
> The exported path is used by idlcc that is launched from the Makefile
> and that can find dfc_idl without problems.
> 
> I need to mimic this behaviour in CMake.
> 
> It seems a very simple task, I can see similar problems with
> LD_LIBRARY_PATH in other projects, it's strange CMake cannot do this in
> an easy way, that's why I think I'm missing something.
> 
> ATM my solution is to manually do
> 
> export PATH=basedir/ext_bin/DFC/idlcc:$PATH 
> *
> *
> *BEFORE* building.
> 
> -- 
> Bye,
>  Gabry
> 

Then you haven't read or understood my message ;-) Instead of calling
idlcc directly in the add_custom_command, you call a wrapper script,
that sets the PATH environment variable, and *then* invokes idlcc.

In your case that would look something like this:

idlcc_wrapper.cmake.in:
---
foreach(var INFILE OUTDIR)
  if(NOT DEFINED ${var})
message(FATAL_ERROR "${var} must be passed on the command line")
  endif()
endforeach()

set(ENV{PATH} "@PROJECT_SOURCE_DIR@/ext_bin/DFC:$ENV{PATH}")

execute_process(
  COMMAND idlcc -V -S -s "${OUTDIR}"
-I"@PROJECT_SOURCE_DIR@/inc/intf" -I"@PROJECT_SOURCE_DIR@/inc"
"@INFILE@")


CMakeLists.txt:
---
# ...
configure_file(iclcc_wrapper.cmake.in
"${CMAKE_CURRENT_BINARY_DIR}/iclcc_wrapper.cmake" @ONLY)
# ...
add_custom_command(
OUTPUT "${PROJECT_SOURCE_DIR}/inc/intf/${_out_FILE}.h"
COMMAND "${CMAKE_COMMAND}"
  -DINFILE="${CMAKE_CURRENT_SOURCE_DIR}/${_in_FILE}"
  -DOUTDIR="${PROJECT_SOURCE_DIR}/inc/intf"
  -P "${CMAKE_CURRENT_BINARY_DIR}/iclcc_wrapper.cmake"
DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/${_in_FILE}"
COMMENT "Creating ${_out_FILE}.h")



One additional comment: Creating output in the source tree is a *very*
bad habit. Some people (including me) consider it to be obscene... ;-)
Unless you are doing an in-source build (which you shouldn't, for the
same reasons you shouldn't create output in the source tree), a build
system should *never* modify the source tree.

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

[CMake] Fwd: Adding custom directories to PATH enviroment

[Gabriele Greco]

> And then configure and run it like this:
>
> CMakeLists.txt:
> ---
> # ...
> configure_file(foo_wrapper.cmake.in
>"${CMAKE_CURRENT_BINARY_DIR}/foo_wrapper.cmake" @ONLY)
> add_custom_command(OUTPUT bar
>  COMMAND "${CMAKE_COMMAND}" -P
>"${CMAKE_CURRENT_BINARY_DIR}/foo_wrapper.cmake"
>  COMMENT "Creating bar")
>
>
> If you need to pass the script variables using the -D flags, make sure
> to pass them before the -P flag, otherwise they are silently ignored.
>
> I hope you get the idea.
>
>

I fear I've not explained enough the problem.

If I understood correctly your solution when in my CMakeLists.txt I execute
the custom command "bar" what I obtain is that "foo" is called.

In my project I have some "IDL" files written in a custom format, those
files require a preprocessing pass to be transformed in .h/.cpp, that I
perform using add_custom_command() inside a macro

ADD_CUSTOM_COMMAND(
 OUTPUT ${PROJECT_SOURCE_DIR}/inc/intf/${_out_FILE}.h
 DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_in_FILE}
 COMMAND idlcc
 ARGS -V -S -s ${PROJECT_SOURCE_DIR}/inc/intf
-I${PROJECT_SOURCE_DIR}/inc/intf -I${PROJECT_SOURCE_DIR}/inc
 ${CMAKE_CURRENT_SOURCE_DIR}/${_in_FILE}
 )

The command *idlcc* is bundled within the repository and is in the directory
$PROJECT_SOURCE_DIR/ext_bin/DFC, I can call it directly with a path,
changing

COMMAND idlcc

to

COMMAND ${PROJECT_SOURCE_DIR}/ext_bin/DFC/idlcc

...but the problem is that idlcc calls its "second step", *dfc_idl*, that is
in the same directory, and pretend it to be in the command search path.

the previous makefile used to do:

export PATH=$PROJECT_DIR/ext/bin/DFC:$PATH

The exported path is used by idlcc that is launched from the Makefile and
that can find dfc_idl without problems.

I need to mimic this behaviour in CMake.

It seems a very simple task, I can see similar problems with LD_LIBRARY_PATH
in other projects, it's strange CMake cannot do this in an easy way, that's
why I think I'm missing something.

ATM my solution is to manually do

export PATH=basedir/ext_bin/DFC/idlcc:$PATH
*
*
*BEFORE* building.

-- 
Bye,
 Gabry
___
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] Adding custom directories to PATH enviroment

[Michael Wild]

On 04/13/2011 11:51 AM, Gabriele Greco wrote:
> Hi,
> 
> I've started using cmake on my projects since a few weeks so I'm still a
> beginner. 
> 
> The system works very well I only have a problem.
> 
> I need to have a directory inside the project tree included in the
> command search path (the enviroment variable PATH).
> 
> I tried with:
> 
> set(ENV{PATH} "${PROJECT_SOURCE_DIR}/ext_bin/DFC:$ENV{PATH}")
> 
> but as I found googling around this command works only in the "cmake"
> stage, but not on the generated makefiles.
> 
> There is a way to tell CMake to make a change to an enviroment variable
> that is effective also inside the generated makefiles?
> 
> -- 
> Gabriele Greco, DARTS Engineering


Wrap the command in a CMake-script. Something like this:

foo_wrapper.cmake.in:
-
set(ENV{PATH} "@PROJECT_SOURCE_DIR@/ext_bin/DFC:$ENV{PATH}")
execute_process(COMMAND foo)

And then configure and run it like this:

CMakeLists.txt:
---
# ...
configure_file(foo_wrapper.cmake.in
"${CMAKE_CURRENT_BINARY_DIR}/foo_wrapper.cmake" @ONLY)
add_custom_command(OUTPUT bar
  COMMAND "${CMAKE_COMMAND}" -P
"${CMAKE_CURRENT_BINARY_DIR}/foo_wrapper.cmake"
  COMMENT "Creating bar")


If you need to pass the script variables using the -D flags, make sure
to pass them before the -P flag, otherwise they are silently ignored.

I hope you get the idea.

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

[CMake] Adding custom directories to PATH enviroment

[Gabriele Greco]

Hi,

I've started using cmake on my projects since a few weeks so I'm still a
beginner.

The system works very well I only have a problem.

I need to have a directory inside the project tree included in the command
search path (the enviroment variable PATH).

I tried with:

set(ENV{PATH} "${PROJECT_SOURCE_DIR}/ext_bin/DFC:$ENV{PATH}")

but as I found googling around this command works only in the "cmake" stage,
but not on the generated makefiles.

There is a way to tell CMake to make a change to an enviroment variable that
is effective also inside the generated makefiles?

-- 
Gabriele Greco, DARTS Engineering
___
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] Resource file skipped without warning

[pellegrini]

Hello everybody,

I am using CMake 2.8 to build a Fortran executable that uses Winteracter 
graphical library.

The build is performed using Intel Fortran Compiler.

I read in previous discussion 
(http://www.cmake.org/pipermail/cmake/2004-January/004664.html)
that just adding the rc file as a source file should work but apparently 
not. When building my project the rc filed seems to be skipped.


I used the following set of commands:

###
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)

project(sxtalsoftsuite Fortran)

set(source_files Src/rc/sxtalsoftsuite.rc Src/rc/sxtalsoftsuite_rc.f90 
Src/sxtalsoftsuite_gui.f90 Src/sxtalsoftsuite.f90)


include_directories($ENV{WINTER}/lib.if8)

add_executable(sxtalsoftsuite ${source_files})

target_link_libraries(sxtalsoftsuite $ENV{WINTER}/lib.if8/winter.lib)
###

I also read that there was a bug 
(http://www.cmake.org/Bug/view.php?id=4068) with CMake concerning 
ignored rc files without warning.


Does my case fall in that category ?

Would you have any hint to circumvent that problem ?

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] Searchable mail archive

[Eric Noulard]

2011/4/13 Michael Wild :
> On 04/13/2011 09:45 AM, J.S. van Bethlehem wrote:
>> Dear CMake users,
>>
>> This week I started to investigate possibilities to move my build-system
>> over to CMake after hearing a lot of good stories about it. To be
>> honest, so far I'm still not quite convinced. The learning (I find at
>> least) is rather steep and the documentation rather sparse (afaics) Then
>> I noticed this mailing list, which would obviously be a got source to
>> look for help, if it were searchable - so that's my question: is there
>> some mirror of the mail-archive where I can search through passed mails
>> to the list?
>>
>> Yours sincerely,
>> Jakob van Bethlehem
>
> Hi Jakob
>
> Welcome to CMake!
>
> There's a Wiki with a FAQ, also covering your question:
> http://www.cmake.org/Wiki/CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives.3F
>
> And then there's the book:
> http://www.kitware.com/products/books/CMakeBook.html
>
> And always, always, remember the mantra: "man cmake"

seconded by the various: cmake --help-X

X = command, module, policy, property, variable,
X-list works as well.

If you are Unix/Linux+bash user the cmake-completion script may help you too:
http://cmake.org/gitweb?p=cmake.git;a=blob_plain;f=Docs/cmake-completion;hb=HEAD

May be you can tell us what are your targeted platform(s) and main
development host
such that we can give you better insight on why CMake may (or may not)
fullfil your needs.

Which build system are you using now? Autotools, SCons, custom
makefiles, some IDE project files?
Are you cross-compiling or not?
Have you some packaging needs where CPack can help?
Do you use some continuous testing technics where CTest can help too?

-- 
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] How to run CMake generated projects in VS2008

[Ronan Keating]

hi all, 
 
I want to know which is the proper way of generating/using the CMake generated 
VS2008 project files. 
I've downloaded the OpenGL samples pack from G-TRUC.NET. In order to not hassle 
with include files, dependencies etcc.. from forums I've been instructed to use 
the CMake to generate the working projects of VisualC++. 
CMake generated the projects in folder "samples/(project_name.vcproj" ) as 
expected but when I attempt to open any individual project, VS2008 IDE loads 
all of them (in Solution Explorer) and any attempt to load/build individual 
projects results in whole projects bundle compilation. And compiler comlains 
about :
 
13>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other 
libs; use /NODEFAULTLIB:library
Error 1 error PRJ0019: A tool returned an error code from  DATA_COPY DATA_COPY

I'm not familiar with the CMake so don't know exactly how to construe the 
bundled set, 
any help in advance will be appreciated.

  ___
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] Searchable mail archive

[Michael Wild]

On 04/13/2011 09:45 AM, J.S. van Bethlehem wrote:
> Dear CMake users,
> 
> This week I started to investigate possibilities to move my build-system
> over to CMake after hearing a lot of good stories about it. To be
> honest, so far I'm still not quite convinced. The learning (I find at
> least) is rather steep and the documentation rather sparse (afaics) Then
> I noticed this mailing list, which would obviously be a got source to
> look for help, if it were searchable - so that's my question: is there
> some mirror of the mail-archive where I can search through passed mails
> to the list?
> 
> Yours sincerely,
> Jakob van Bethlehem

Hi Jakob

Welcome to CMake!

There's a Wiki with a FAQ, also covering your question:
http://www.cmake.org/Wiki/CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives.3F

And then there's the book:
http://www.kitware.com/products/books/CMakeBook.html

And always, always, remember the mantra: "man cmake"

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

[CMake] Searchable mail archive

[J.S. van Bethlehem]

Dear CMake users,

This week I started to investigate possibilities to move my build-system 
over to CMake after hearing a lot of good stories about it. To be 
honest, so far I'm still not quite convinced. The learning (I find at 
least) is rather steep and the documentation rather sparse (afaics) Then 
I noticed this mailing list, which would obviously be a got source to 
look for help, if it were searchable - so that's my question: is there 
some mirror of the mail-archive where I can search through passed mails 
to the list?


Yours sincerely,
Jakob van Bethlehem
___
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] Properly Detecting Win64

[Rolf Eike Beer]

>> Maybe you can base the package name by testing the generator name.
>
> I need to do that to e.g. get a useful build naming in CTest scripts. At
> that point CMAKE_SIZEOF_VOID_P is not available anyway. And I think that
> using this is just a bad idea. How do you decide if it's IA64 or AMD64?

[...]

And if you are inside the build you have also CMAKE_CL_64. At least when
using NMake. IIRC it is not set when using the Visual Studio Generators so
you are back to the previously posted solution.

Eike
___
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] Properly Detecting Win64

[Rolf Eike Beer]

> Maybe you can base the package name by testing the generator name.

I need to do that to e.g. get a useful build naming in CTest scripts. At
that point CMAKE_SIZEOF_VOID_P is not available anyway. And I think that
using this is just a bad idea. How do you decide if it's IA64 or AMD64?

I use this at the moment:

FUNCTION(GET_NMAKE_VERSION_STRING var)
IF(MSVC_VERSION EQUAL 1400)
SET(ver_string "vs8")
ELSEIF(MSVC_VERSION GREATER 1599)
SET(ver_string "vs10")
ELSEIF(MSVC_VERSION GREATER 1499)
SET(ver_string "vs9")
ELSEIF(CMAKE_COMPILER_2005)
SET(ver_string "vs7")
ELSE(MSVC_VERSION EQUAL 1400)
SET(ver_string "vs6")
ENDIF(MSVC_VERSION EQUAL 1400)
SET(${var} "${ver_string}" PARENT_SCOPE)
ENDFUNCTION(GET_NMAKE_VERSION_STRING)

# CMAKE_SIZEOF_VOID_P doesn't work here because there
# was no compiler detection until now
IF (WIN32)
SET(CMAKE_CXX_COMPILER cl)
EXECUTE_PROCESS(COMMAND ${CMAKE_CXX_COMPILER}
OUTPUT_VARIABLE _DEV_NULL
ERROR_VARIABLE _COMPILER_OUTPUT)
STRING(REGEX REPLACE " Version .*" "" CTEST_COMPILER 
${_COMPILER_OUTPUT})
IF (_COMPILER_OUTPUT MATCHES " for x64")
SET(_BUILD_64_BIT TRUE)
ELSE ()
SET(_BUILD_64_BIT FALSE)
ENDIF ()
...

A case for IA64 can be easily added at this point. Those CTest scripts are
only used with NMake at the moment so there is no case for Visual Studio
generators. But that can also easily be added with "IF (CMAKE_GENERATOR
MATCHES "AMD64$")" or something like that.

HTH

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