Re: [CMake] Does find_library check that a found library does in fact link?

[Michael Wild]

On 09/29/2011 07:15 AM, Clifford Yapp wrote:
> On Wed, Sep 28, 2011 at 8:52 PM, Michael Hertling 
> mailto:mhertl...@online.de>> wrote:
> 
> What do you do on systems which have no idea of symbolic links, e.g. 
> previous Windows versions? Adding more platform-specific code to the 
> sources of the FIND_LIBRARY() function?
> 
> 
> If the problem isn't solved (or readily solvable) on some platforms,
>  we can just fall back to doing what we do now in those cases... we 
> don't have to solve the problem on all possible platforms to improve
>  the results on platforms that can be supported.  The point wouldn't
>  be to *guarantee* the result of find_library is a valid working 
> library (it doesn't do that now), just improve the results by doing 
> what can be done to avoid returning results that can be tagged as 
> non-working (since a build trying to use such results is guaranteed 
> to fail anyway.)  Does cmake know (or can it tell) when it is cross 
> compiling?  If so, it could decide how much to test and not test in 
> those cases.
> 
> 
> Furthermore, the kernels of *nix systems hardly distinguish between 
> binary files and text files; usually, they know just "files" with the
> limited exception of being able to recognize the native executable
> formats and the #! shebang. The detection of the diverse file types
> is typically implemented in utility programs, notably the file(1)
> utility.
> 
> 
> A linker test when possible (non-cross-compilation scenarios) with a 
> fallback testing option using file introspection would handle a lot 
> of situations, if I'm understanding correctly how this works.  To the
> best of my knowledge and that of one of our other devs (he knows a
> lot more than me) there aren't any platforms where actual library 
> files (as opposed to linker scripts) consist solely of character 
> values <128. Checking a found file for at least one character over 
> 128 would avoid at least a few failure cases - empty files, plain 
> text files, and dead links.  Such a check would be reliable, consist,
> and would be useful in eliminating files we might find that are not
> actually library files.
> 
> Such a test  of course wouldn't pass linker scripts like ubuntu's 
> libc.so, but such a script *would* pass the actual linker test and 
> would never get to file introspection. Actually if the script failed
>  the linker test, then there is a real problem that should be a 
> failure case.  This would also be helpful in spotting early on the 
> hypothetical case of a linker being tested that doesn't understand 
> the .so linker script.
> 
> 
>>> But how do you test whether a library is "linkable"?
> 
> 
> If not cross-compiling, wouldn't it be possible to have find_library
>  try the link as part of its test?  Even in the case where linking 
> isn't viable, falling back on the check on file contents would still
>  be helpful.
> 
> 
> What do you do if the library found by FIND_LIBRARY() has a 
> non-native binary format, e.g. for cross-compiling purposes? How do 
> you select the right set of tools to check the library in question 
> without the user's ado? IMO, FIND_LIBRARY()'s job is to find library
>  files, and a general check whether these files are 
> valid/usable/linkable and not dangling symlinks or whatever is beyond
> the scope of this function; ensuring that is rather the realm of
> system administration.
> 
> 
> I guess the question revolves around the expectation of find_library 
> being different from find_file - as a user, my expectation would be 
> that find_library is doing something to distinguish libraries from 
> files (when that's technically workable, of course - clearly solving
>  that problem in general is hard.)  If something tricky like 
> cross-compiling is going on then the simpler testing behavior is in 
> order, but couldn't CMake scrub the results looking for library 
> validity as much as possible?
> 
> Cheers, CY

Just a few of my thoughts on this:

- There are several ways to handle dead symlinks:
  1. Don't check, let the linker complain (status quo)
  2. Check whether the found library is a symlink, and if not valid,
 remove it silently from the list of candidates. Can be very
 surprising and will likely result in quite a few bug reports
 about CMake not finding a certain library that is "clearly" there.
  3. Like 2, but warn about the issue. Possibly very annoying.
I don't know which option to prefer (perhaps somebody finds another one
that is better?). IMHO bogus symlinks to shared libraries constitute a
real problem of the library installation, so CMake shouldn't just paper
over it by silently skipping the dead link, proceeding to the next
candidate which rules out option 2 for me. Also, option 3 can be
troublesome in automated setups where no user actually reads the CMake
output.

- Concerning link-tests:
  1. Only possible with shared libraries
  2. Some shared libraries require special linker flags which CMake
 would require the user 

Re: [CMake] Does find_library check that a found library does in fact link?

[Clifford Yapp]

On Wed, Sep 28, 2011 at 8:52 PM, Michael Hertling wrote:

What do you do on systems which have no idea of symbolic links, e.g.
> previous Windows versions? Adding more platform-specific code to the
> sources of the FIND_LIBRARY() function?


If the problem isn't solved (or readily solvable) on some platforms, we can
just fall back to doing what we do now in those cases... we don't have to
solve the problem on all possible platforms to improve the results on
platforms that can be supported.  The point wouldn't be to *guarantee* the
result of find_library is a valid working library (it doesn't do that now),
just improve the results by doing what can be done to avoid returning
results that can be tagged as non-working (since a build trying to use such
results is guaranteed to fail anyway.)  Does cmake know (or can it tell)
when it is cross compiling?  If so, it could decide how much to test and not
test in those cases.


> Furthermore, the kernels of
> *nix systems hardly distinguish between binary files and text files;
> usually, they know just "files" with the limited exception of being
> able to recognize the native executable formats and the #! shebang.
> The detection of the diverse file types is typically implemented
> in utility programs, notably the file(1) utility.
>

A linker test when possible (non-cross-compilation scenarios) with a
fallback testing option using file introspection would handle a lot of
situations, if I'm understanding correctly how this works.  To the best of
my knowledge and that of one of our other devs (he knows a lot more than me)
there aren't any platforms where actual library files (as opposed to linker
scripts) consist solely of character values <128.  Checking a found file for
at least one character over 128 would avoid at least a few failure cases -
empty files, plain text files, and dead links.  Such a check would be
reliable, consist, and would be useful in eliminating files we might find
that are not actually library files.

Such a test  of course wouldn't pass linker scripts like ubuntu's libc.so,
but such a script *would* pass the actual linker test and would never get to
file introspection. Actually if the script failed the linker test, then
there is a real problem that should be a failure case.  This would also be
helpful in spotting early on the hypothetical case of a linker being tested
that doesn't understand the .so linker script.


> >> But how do you test whether a library is "linkable"?
>

If not cross-compiling, wouldn't it be possible to have find_library try the
link as part of its test?  Even in the case where linking isn't viable,
falling back on the check on file contents would still be helpful.


> What do you do if the library found by FIND_LIBRARY() has a non-native
> binary format, e.g. for cross-compiling purposes? How do you select the
> right set of tools to check the library in question without the user's
> ado? IMO, FIND_LIBRARY()'s job is to find library files, and a general
> check whether these files are valid/usable/linkable and not dangling
> symlinks or whatever is beyond the scope of this function; ensuring
> that is rather the realm of system administration.
>

I guess the question revolves around the expectation of find_library being
different from find_file - as a user, my expectation would be that
find_library is doing something to distinguish libraries from files (when
that's technically workable, of course - clearly solving that problem in
general is hard.)  If something tricky like cross-compiling is going on then
the simpler testing behavior is in order, but couldn't CMake scrub the
results looking for library validity as much as possible?

Cheers,
CY
--

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] Does find_library check that a found library does in fact link?

[Michael Wild]

On 09/29/2011 02:52 AM, Michael Hertling wrote:
> On 09/29/2011 01:30 AM, Clifford Yapp wrote:
>> On Wed, Sep 28, 2011 at 2:47 AM, Michael Wild  wrote:
>>
>>>
>>> Only if your installation is broken ;-) If the symlink is broken, I
>>> consider this to be a user-error. Period. OTOH, CMake /could/ check
>>> whether the library is a symlink, and if it is, check that it is valid.
>>>
>>
>> Oh, no question the installation is broken.  I'd just expect find_library to
>> do whatever minimal validation it can easily do and not return invalid cases
>> it can spot - checking for symlink and whether it's valid would catch one
>> general class of error, and perhaps a quick check to see if the file is a
>> binary or a text file would be another.   Not perfect, but such tests should
>> be relatively simple and would improve the utility of find_library.
> 
> What do you do on systems which have no idea of symbolic links, e.g.
> previous Windows versions? Adding more platform-specific code to the
> sources of the FIND_LIBRARY() function? Furthermore, the kernels of
> *nix systems hardly distinguish between binary files and text files;
> usually, they know just "files" with the limited exception of being
> able to recognize the native executable formats and the #! shebang.
> The detection of the diverse file types is typically implemented
> in utility programs, notably the file(1) utility.

And to add to the confusion, GNU ld also accepts linker scripts which
are text files, but are named like libraries. E.g. on my Ubuntu 11.04
box /usr/lib/x86_64-linux-gnu/libc.so is actually a linker script.

file(1) uses "magic" numbers and heuristics to detect the file type, and
it certainly isn't bulletproof...

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: Save stripped debugging information

[Yuri Timenkov]

When I was investigating similar problem, I found alternative approach at
http://code.google.com/p/dynamorio/source/browse/trunk/CMakeLists.txt.

The thing is to change linker rules, to something like this:
set(CMAKE_C_CREATE_SHARED_LIBRARY
# standard rule
" 
  
 -o  
"
# now create a .debug copy
"${CMAKE_OBJCOPY} --only-keep-debug  .debug"
# link original to point at .debug copy
# directory components are removed, so "../lib/" is fine
"${CMAKE_OBJCOPY} --add-gnu-debuglink=.debug "
# Strip all information from target binary.
"${CMAKE_STRIP} --strip-debug --discard-all --preserve-dates
"
)

I don't exactly remember benefits from this approach but it kind of works.

And I agree that functionality like installing debug symbols in install()
rules out of box would be quite handy.

Regards,
Yuri

On Sat, Sep 24, 2011 at 4:02 AM, Michael Hertling wrote:

> On 09/22/2011 01:24 PM, Rolf Eike Beer wrote:
> >> Il 22/09/2011 10.13, Rolf Eike Beer ha scritto:
>  Yeah, that's exactly what I had in mind. Any chance that we will see
>  this in a future release?
> >>> This is usually "find someone who does it and writes tests for it".
> >>> Which
> >>> then boils down to find someone who has enough knowledge and spare time
> >>> to
> >>> do or someone that needs it and is willing to pay Kitware for doing it.
> >
> >> Why don't you invoke ${CMAKE_OBJCOPY} as a post build command?
> >
> > That would be a way to _get_ these debug symbol files, but not a clean
> way
> > to _install_ them. And the other reason is that this variable doesn't
> show
> > up in any CMake documentation.
> >
> > Eike
>
> In order to take up Andrea's suggestion for Lukas' concern:
>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> PROJECT(DEBUGINFO C)
> SET(CMAKE_VERBOSE_MAKEFILE ON)
> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
> ADD_EXECUTABLE(main main.c)
> FIND_PROGRAM(OBJCOPY objcopy)
> ADD_CUSTOM_COMMAND(TARGET main POST_BUILD
>COMMAND ${OBJCOPY} --only-keep-debug
>$ ${CMAKE_BINARY_DIR}/main.dbg
>COMMAND ${OBJCOPY} --strip-debug
>$
>COMMAND ${OBJCOPY} --add-gnu-debuglink=main.dbg
>$
> )
> INSTALL(TARGETS main RUNTIME DESTINATION bin)
> INSTALL(FILES ${CMAKE_BINARY_DIR}/main.dbg DESTINATION bin)
>
> This exemplary project simply follows objcopy's manpage
> w.r.t. the --only-keep-debug switch and works on *nix.
> Does it not work for you, or is it not clean enough?
>
> 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
>
--

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] Does find_library check that a found library does in fact link?

[Michael Hertling]

On 09/29/2011 01:30 AM, Clifford Yapp wrote:
> On Wed, Sep 28, 2011 at 2:47 AM, Michael Wild  wrote:
> 
>>
>> Only if your installation is broken ;-) If the symlink is broken, I
>> consider this to be a user-error. Period. OTOH, CMake /could/ check
>> whether the library is a symlink, and if it is, check that it is valid.
>>
> 
> Oh, no question the installation is broken.  I'd just expect find_library to
> do whatever minimal validation it can easily do and not return invalid cases
> it can spot - checking for symlink and whether it's valid would catch one
> general class of error, and perhaps a quick check to see if the file is a
> binary or a text file would be another.   Not perfect, but such tests should
> be relatively simple and would improve the utility of find_library.

What do you do on systems which have no idea of symbolic links, e.g.
previous Windows versions? Adding more platform-specific code to the
sources of the FIND_LIBRARY() function? Furthermore, the kernels of
*nix systems hardly distinguish between binary files and text files;
usually, they know just "files" with the limited exception of being
able to recognize the native executable formats and the #! shebang.
The detection of the diverse file types is typically implemented
in utility programs, notably the file(1) utility.

>> But how do you test whether a library is "linkable"?
>>
> 
> Not sure - autoconf has some sort of test that works in at least some cases
> in their AC_CHECK_LIB macro, but I'm not really clear on what it does.  Even
> if such a test wouldn't catch all cases, mightn't it be useful to fail when
> available tests do detect a problem?

What do you do if the library found by FIND_LIBRARY() has a non-native
binary format, e.g. for cross-compiling purposes? How do you select the
right set of tools to check the library in question without the user's
ado? IMO, FIND_LIBRARY()'s job is to find library files, and a general
check whether these files are valid/usable/linkable and not dangling
symlinks or whatever is beyond the scope of this function; ensuring
that is rather the realm of system administration.

> Cheers,
> CY

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] How to use add_custom_command correctly

[Michael Hertling]

On 09/28/2011 01:45 PM, Martin Kupke wrote:
> Now it seems to be solved, the generator is called and the generated 
> sources / headers are then compiled and linked into a library.
> 
> My changes are in the
> 
> D:/project/Discovery/Generated/Driver/CMakeLists.txt
> 
> just adding a add_custom_target( MyGeneratedSources ALL DEPENDS 
> ${all_generated_srcs} ${all_generated_hdrs} )
> 
> Additionally I added in the root CMakeLists.txt
> add_dependencies( ${MY_PROJECT} MyGeneratedSources )
> 
> This works fine.

Just two additional remarks:

- For ADD_CUSTOM_COMMAND(OUTPUT ...), it's documented explicitly
that relative paths after the OUTPUT clause will be interpreted
with respect to the current binary directory, so you may leave
out the leading ${CMAKE_CURRENT_BINARY_DIRECTORY} and specify
relative paths here. However, for the DEPENDS clause, there
is no such documentation.

- A custom command's OUTPUTs must be mentioned as other targets'
prerequisites, i.e. as source files in ADD_EXECUTABLE/LIBRARY()
or after the DEPENDS clause of ADD_CUSTOM_TARGET() in the same
CMakeLists.txt file. Otherwise, the rule for the then unused
OUTPUT is dropped, and it will never be generated. Thus, for
generated sources/headers, there should be no need for an
additional custom target as a custom command's anchor.

Regards,

Michael

> On 28.09.11 13:34, Rolf Eike Beer wrote:
>>>
>>> On 27.09.11 18:24, Michael Wild wrote:
 On 09/27/2011 05:59 PM, Martin Kupke wrote:
> Hi,
>
> in my project there is a subfolder which SHALL contain sources to
> generate a library. The problem is that at startup of the project there
> are no source files existing, because they will be generated by a code
> generator. This means within the build process the code generator needs
> to be called first, then generates the output files in the subfolder
> and
> then a library shall be generated from that source files (this are
> standard .c and .h files). If I start the code generator by hand to
> generate the source files and remove the custom command, then the
> compilation is successful, but I want the code generator to be started
> every time the configuration file for the code generator has changed.
>
> In my sample below
> * the driver.c would be one of the files which the code generator would
> generate
> * the variable CodeGen is the executable tool (the code generator
> himself)
> * the variable CodeGenParam contains the parameters which are passed to
> be able to generate without any user interaction
> * the variable CodeGenConfig is the input file for the code generator
>
> This subfolder contains its own CMakeLists.txt with the following
> settings:
> # snip #
> project(CANstack C)
>
> add_custom_command( OUTPUT driver.c
>  COMMAND ${CodeGen}
> ${CodeGenParam}
>  DEPENDS ${CodeGenConfig} )
> )
>
> file(GLOB CANstack_srcs "*.c")
> file(GLOB CANstack_hdrs "*.h")
>
> set(lib_name "CANstack")
> add_library(${lib_name} STATIC ${CANstack_srcs} ${CANstack_hdrs})
>
> # snap #
>
> I don't get it work that the custom command is called and the source
> files from the code generator are produced.
>
 A few issues here:

 - Never generate output in the source tree, only in the binary tree.
 - Always use absolute paths with add_custom_command().
>>> I use the absolute paths
 - Always list *all* outputs after the OUTPUT argument, otherwise CMake
 won't know that they are generated sources.
>>> I added the list of *all* files which shall be generated
 - Never use file(GLOB ...). It is evil. And breaks in your case. Just
 don't.
>>> I don't use the file(GLOB ...) anymore in this CMakeLists.txt
 Michael

>>> In case the generated output files already exist and the dependency file
>>> ${CodeGenConfig} has been touched, then the output will be generated.
>>>
>>> Typically there is from beginning of the project no source file
>>> existing, because the generator needs to be run first. If the output
>>> files are not existing, then I get an error message from CMake:
>>>
>>> # snip #
>>>
>>> CMake Error at Generated/CarIF_Appl/CANstack/CMakeLists.txt:31
>>> (add_library):
>>> Cannot find source file:
>>>
>>>   D:/project/Discovery/Generated/Driver/uart.c
>>>
>>> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
>>> .hpp
>>> .hxx .in .txx
>>>
>>> # snap #
>>>
>>> How do I have to instruct CMake to run the code generator first, so that
>>> the library can be build of that sources?
>> Can you paste the relevant snippet from your new CMakeLists.txt?
>>
>> You can try this fir

Re: [CMake] Does find_library check that a found library does in fact link?

[Clifford Yapp]

On Wed, Sep 28, 2011 at 2:47 AM, Michael Wild  wrote:

>
> Only if your installation is broken ;-) If the symlink is broken, I
> consider this to be a user-error. Period. OTOH, CMake /could/ check
> whether the library is a symlink, and if it is, check that it is valid.
>

Oh, no question the installation is broken.  I'd just expect find_library to
do whatever minimal validation it can easily do and not return invalid cases
it can spot - checking for symlink and whether it's valid would catch one
general class of error, and perhaps a quick check to see if the file is a
binary or a text file would be another.   Not perfect, but such tests should
be relatively simple and would improve the utility of find_library.


> But how do you test whether a library is "linkable"?
>

Not sure - autoconf has some sort of test that works in at least some cases
in their AC_CHECK_LIB macro, but I'm not really clear on what it does.  Even
if such a test wouldn't catch all cases, mightn't it be useful to fail when
available tests do detect a problem?

Cheers,
CY
--

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] overriding ${PROJECTNAME}_BINARY_DIR before call to project()

[Michael Hertling]

On 09/28/2011 06:36 PM, Thomas Wolf wrote:
> On 28.09.2011 17:58, Jean-Christophe Fillion-Robin wrote:
>> Hi Thomas,
>>
>> You will find below few points that should help you to address your issues:
>>
>> 1) CTK build system can be build with the option CTK_SUPERBUILD set to
>> OFF, in that case the project will be built as a "regular" cmake project.
>>
>> 2) You could also build CTK normally (default option) providing VTK_DIR,
>> Log4Qt_DIR etc ... the CTK build system will understand these
>> dependencies are available and no project will be downloaded. This is
>> somehow equivalent to build CTK with CTK_SUPERBUILB OFF
>>
>> 3) If you want to make sure all binaries and libs are built in a custom
>> location, make sure you set:
>>
>> CTK_CMAKE_ARCHIVE_OUTPUT_DIRECTORY
>> CTK_CMAKE_LIBRARY_OUTPUT_DIRECTORY
>>
>>
>> CTK_CMAKE_RUNTIME_OUTPUT_DIRECTORY
>>
>> Seehttps://github.com/commontk/CTK/blob/master/CMakeLists.txt#L91
>>
>> Would be great if you could send request regarding CTK to
>> ctk-develop...@commontk.org 
>> More info here: http://www.commontk.org and
>> http://www.commontk.org/index.php/Getting_Started
>>
>> Thanks
>> Jc
>>
> 
> Hello Jean-Christophe,
> 
> thanks for your reply. Actually, i took CTK just as an example for the 
> problem, but i will also try what you suggested.
> 
> CTK_SUPERBUILD is already off.
> 
> Anyway I wonder why ${PROJ}_BINARY_DIR is not settable for me.

You *can* set a subproject's binary directory by using the binary_dir
parameter of ADD_SUBDIRECTORY(); see the following exemplary project:

# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BINDIR C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_SUBDIRECTORY(subdir1 ${CMAKE_BINARY_DIR}/bindir)
ADD_SUBDIRECTORY(subdir2)

# subdir1/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(SUBDIR1 C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f1.c "void f1(void){}\n")
ADD_LIBRARY(f1 SHARED f1.c)
MESSAGE("${PROJECT_NAME}_BINARY_DIR: ${${PROJECT_NAME}_BINARY_DIR}")

# subdir2/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(SUBDIR2 C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f2.c "void f2(void){}\n")
ADD_LIBRARY(f2 SHARED f2.c)
MESSAGE("${PROJECT_NAME}_BINARY_DIR: ${${PROJECT_NAME}_BINARY_DIR}")

As you can see during the configuration, the subproject in subdir1 will
be built in ${CMAKE_BINARY_DIR}/bindir while the essentially identical
subproject in subdir2 will be built in ${CMAKE_BINARY_DIR}/subdir2 as
usual. However, CMake doesn't allow two or more subprojects to share
a common build directory, i.e. you can't say

ADD_SUBDIRECTORY(subdir2 ${CMAKE_BINARY_DIR}/bindir)

too, and with regard to CMakeFiles, Makefile, cmake_install.cmake
etc., this would be anyway a recipe for desaster. Thus, each of your
subprojects must be provided with an individual build directory, and
to collect your targets' binaries in the top-level CMAKE_BINARY_DIR,
you may use the diverse *_OUTPUT_DIRECTORY[_] properties and
the corresponding CMAKE_*_OUTPUT_DIRECTORY variables. Alternatively,
you might add a custom target in the top-level CMakeLists.txt file:

ADD_CUSTOM_TARGET(binaries ALL
COMMAND ${CMAKE_COMMAND} -E copy $
 ${CMAKE_BINARY_DIR}
COMMAND ${CMAKE_COMMAND} -E copy $
 ${CMAKE_BINARY_DIR}
COMMENT "Copying binaries to ${CMAKE_BINARY_DIR}"
)
ADD_DEPENDENCIES(binaries f1 f2)

'hope that helps.

Regards,

Michael

> Regards,
> Thomas
> 
> PS.: i posted also something on ctk-developers, but the posting didn't 
> appear.
--

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] overriding ${PROJECTNAME}_BINARY_DIR before call to project()

[Thomas Wolf]

On 28.09.2011 17:58, Jean-Christophe Fillion-Robin wrote:

Hi Thomas,

You will find below few points that should help you to address your issues:

1) CTK build system can be build with the option CTK_SUPERBUILD set to
OFF, in that case the project will be built as a "regular" cmake project.

2) You could also build CTK normally (default option) providing VTK_DIR,
Log4Qt_DIR etc ... the CTK build system will understand these
dependencies are available and no project will be downloaded. This is
somehow equivalent to build CTK with CTK_SUPERBUILB OFF

3) If you want to make sure all binaries and libs are built in a custom
location, make sure you set:

CTK_CMAKE_ARCHIVE_OUTPUT_DIRECTORY
CTK_CMAKE_LIBRARY_OUTPUT_DIRECTORY


CTK_CMAKE_RUNTIME_OUTPUT_DIRECTORY

Seehttps://github.com/commontk/CTK/blob/master/CMakeLists.txt#L91

Would be great if you could send request regarding CTK to
ctk-develop...@commontk.org 
More info here: http://www.commontk.org and
http://www.commontk.org/index.php/Getting_Started

Thanks
Jc



Hello Jean-Christophe,

thanks for your reply. Actually, i took CTK just as an example for the 
problem, but i will also try what you suggested.


CTK_SUPERBUILD is already off.

Anyway I wonder why ${PROJ}_BINARY_DIR is not settable for me.

Regards,
Thomas

PS.: i posted also something on ctk-developers, but the posting didn't 
appear.

--

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] overriding ${PROJECTNAME}_BINARY_DIR before call to project()

[Jean-Christophe Fillion-Robin]

Hi Thomas,

You will find below few points that should help you to address your issues:

1) CTK build system can be build with the option CTK_SUPERBUILD set to OFF,
in that case the project will be built as a "regular" cmake project.

2) You could also build CTK normally (default option) providing VTK_DIR,
Log4Qt_DIR etc ... the CTK build system will understand these dependencies
are available and no project will be downloaded. This is somehow equivalent
to build CTK with CTK_SUPERBUILB OFF

3) If you want to make sure all binaries and libs are built in a custom
location, make sure you set:

CTK_CMAKE_ARCHIVE_OUTPUT_DIRECTORY
CTK_CMAKE_LIBRARY_OUTPUT_DIRECTORY

CTK_CMAKE_RUNTIME_OUTPUT_DIRECTORY

See https://github.com/commontk/CTK/blob/master/CMakeLists.txt#L91

Would be great if you could send request regarding CTK to
ctk-develop...@commontk.org
More info here: http://www.commontk.org and
http://www.commontk.org/index.php/Getting_Started

Thanks
Jc

On Wed, Sep 28, 2011 at 11:35 AM, Thomas Wolf  wrote:

> Hi there,
>
> I have some serious trouble to get a makefile running, comprising of MITK,
> VTK, ITK, CTK, Log4Qt, DCMTK, GDCM, etc...
>
> Because most of the makefiles have some imperfections regarding being built
> under windows and x64 with the project environment of Visual Studio 2008, we
> use direct builds in the main makefile. This also helps to see all source
> code of the involved projects. The project requirements are also set in a
> way that we cannto use git or downloads, so the technique called
> "superbuild" is not applicable here.
>

> To get the involved projects to be built at the correct place, namely all
> created binaries in the CMAKE_BINARY_DIR location of the main makefile, i
> try to override e.g. CTK_BINARY_DIR before the inclusion of the CTK makefile
> via add_subdirectory.
>

> I have a hard time doing this, even with
>
> SET(CTK_BINARY_DIR ${CMAKE_BINARY_DIR} CACHE INTERNAL "" FORCE
> PARENT_SCOPE)
>
> the next call to project(CTK) overrides this and takes some other value.
> This value corresponds to the layout of the source tree apparently, but is
> of no use in this situation.
>
> How can I influence the value of CTK_BINARY_DIR before the call to the
> makefile?
>
> i tried to use project(CTK) in the toplevel makefile one directory up, but
> even then the values won't be taken.
>
> so this situation in
>
> mainmakefile:
>
> project(CTK)
> set(CTK_BINARY_DIR "some other place" CACHE INTERNAL "" FORCE PARENT_SCOPE
> )
> add_subdirectory(CTK)
>
> does not change a thing for CTK. Even when the CTK makefile (naturally)
> sets project(CTK), cmake does not complain or state something about double
> projects, but silently overwrites the CTK_BINARY_DIR with new values! So it
> respects the second call to 'project()', which in my opinion should be
> either
> a) reported as an error
> or
> b) the first call to project(CTK) should have priority
>
> Can someone help me?
>
> Regards,
> Thomas
> --
>
> 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] overriding ${PROJECTNAME}_BINARY_DIR before call to project()

[Thomas Wolf]

Hi there,

I have some serious trouble to get a makefile running, comprising of 
MITK, VTK, ITK, CTK, Log4Qt, DCMTK, GDCM, etc...


Because most of the makefiles have some imperfections regarding being 
built under windows and x64 with the project environment of Visual 
Studio 2008, we use direct builds in the main makefile. This also helps 
to see all source code of the involved projects. The project 
requirements are also set in a way that we cannto use git or downloads, 
so the technique called "superbuild" is not applicable here.


To get the involved projects to be built at the correct place, namely 
all created binaries in the CMAKE_BINARY_DIR location of the main 
makefile, i try to override e.g. CTK_BINARY_DIR before the inclusion of 
the CTK makefile via add_subdirectory.


I have a hard time doing this, even with

SET(CTK_BINARY_DIR ${CMAKE_BINARY_DIR} CACHE INTERNAL "" FORCE PARENT_SCOPE)

the next call to project(CTK) overrides this and takes some other value. 
This value corresponds to the layout of the source tree apparently, but 
is of no use in this situation.


How can I influence the value of CTK_BINARY_DIR before the call to the 
makefile?


i tried to use project(CTK) in the toplevel makefile one directory up, 
but even then the values won't be taken.


so this situation in

mainmakefile:

project(CTK)
set(CTK_BINARY_DIR "some other place" CACHE INTERNAL "" FORCE PARENT_SCOPE )
add_subdirectory(CTK)

does not change a thing for CTK. Even when the CTK makefile (naturally)
sets project(CTK), cmake does not complain or state something about 
double projects, but silently overwrites the CTK_BINARY_DIR with new 
values! So it respects the second call to 'project()', which in my 
opinion should be either

a) reported as an error
or
b) the first call to project(CTK) should have priority

Can someone help me?

Regards,
Thomas
--

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] multiple source directories - solved

[pellegrini]

thanks for the hints and your help, guys. Indeed, There was one '..\' 
too much in my source files path.


Eric

Andreas Pakulat a écrit :

On 28.09.11 12:51:53, pellegrini wrote:
  

Hi all,

I have a project with the following structure:

root/
   CMakeLists.txt
   prog1/
   CMakeLists.txt
   Src/
   file1.f90
   prog2/
   CMakeLists.txt
   Src/
   file2.f90

where prog1, prog2 are individual projects.

I would like to add file1.90 to the build process of prog2. To do
so, in the CMakeLists.txt file of prog2 project, I put:

   set(SOURCES ../../prog1/Src/file1.f90
   Src/file2.f90)
and further
   add_executable(prog2 ${SOURCES})

when compiling with CMake I get the following error:

##
CMake Error at CMakeLists.txt:35 (add_executable):
 Cannot find source file:

   ../../prog1/Src/file1.f90

 Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp  .hxx .in .txx
###

It seems that CMake cna not deal with relative path when declaring
the sources for a project.



Relative paths work just fine, but your expecting a different base-path
than cmake is. In the above example the current directory when
assembling the sources is root/prog2 not root/prog2/Src which you seem
to assume. Hence you have one ".." too much in your set-line. This
should work:

set( SOURCES ../prog1/Src/file1.f90 Src/file2.f90 )

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
  



--
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] How to use add_custom_command correctly

[Martin Kupke]

Now it seems to be solved, the generator is called and the generated 
sources / headers are then compiled and linked into a library.


My changes are in the

D:/project/Discovery/Generated/Driver/CMakeLists.txt

just adding a add_custom_target( MyGeneratedSources ALL DEPENDS 
${all_generated_srcs} ${all_generated_hdrs} )


Additionally I added in the root CMakeLists.txt
add_dependencies( ${MY_PROJECT} MyGeneratedSources )

This works fine.

On 28.09.11 13:34, Rolf Eike Beer wrote:


On 27.09.11 18:24, Michael Wild wrote:

On 09/27/2011 05:59 PM, Martin Kupke wrote:

Hi,

in my project there is a subfolder which SHALL contain sources to
generate a library. The problem is that at startup of the project there
are no source files existing, because they will be generated by a code
generator. This means within the build process the code generator needs
to be called first, then generates the output files in the subfolder
and
then a library shall be generated from that source files (this are
standard .c and .h files). If I start the code generator by hand to
generate the source files and remove the custom command, then the
compilation is successful, but I want the code generator to be started
every time the configuration file for the code generator has changed.

In my sample below
* the driver.c would be one of the files which the code generator would
generate
* the variable CodeGen is the executable tool (the code generator
himself)
* the variable CodeGenParam contains the parameters which are passed to
be able to generate without any user interaction
* the variable CodeGenConfig is the input file for the code generator

This subfolder contains its own CMakeLists.txt with the following
settings:
# snip #
project(CANstack C)

add_custom_command( OUTPUT driver.c
 COMMAND ${CodeGen}
${CodeGenParam}
 DEPENDS ${CodeGenConfig} )
)

file(GLOB CANstack_srcs "*.c")
file(GLOB CANstack_hdrs "*.h")

set(lib_name "CANstack")
add_library(${lib_name} STATIC ${CANstack_srcs} ${CANstack_hdrs})

# snap #

I don't get it work that the custom command is called and the source
files from the code generator are produced.


A few issues here:

- Never generate output in the source tree, only in the binary tree.
- Always use absolute paths with add_custom_command().

I use the absolute paths

- Always list *all* outputs after the OUTPUT argument, otherwise CMake
won't know that they are generated sources.

I added the list of *all* files which shall be generated

- Never use file(GLOB ...). It is evil. And breaks in your case. Just
don't.

I don't use the file(GLOB ...) anymore in this CMakeLists.txt

Michael


In case the generated output files already exist and the dependency file
${CodeGenConfig} has been touched, then the output will be generated.

Typically there is from beginning of the project no source file
existing, because the generator needs to be run first. If the output
files are not existing, then I get an error message from CMake:

# snip #

CMake Error at Generated/CarIF_Appl/CANstack/CMakeLists.txt:31
(add_library):
Cannot find source file:

  D:/project/Discovery/Generated/Driver/uart.c

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp
.hxx .in .txx

# snap #

How do I have to instruct CMake to run the code generator first, so that
the library can be build of that sources?

Can you paste the relevant snippet from your new CMakeLists.txt?

You can try this first and see if it helps:

add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/driver.c
COMMAND ${CodeGen} {CodeGenParam}
DEPENDS ${CodeGenConfig} )

add_executable(myexe ${CMAKE_CURRENT_BINARY_DIR}/driver.c)

Of course you must tell the CodeGen where to put the result, preferably by
passing "${CMAKE_CURRENT_BINARY_DIR}/driver.c" as argument (with the
quotes, to make paths with spaces work right). If the generator can't
handle this you can try to set WORKING_DIRECTORY to
${CMAKE_CURRENT_BINARY_DIR}, passing all other file arguments with
absolute paths then.

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


--

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] multiple source directories

[Andreas Pakulat]

On 28.09.11 12:51:53, pellegrini wrote:
> Hi all,
> 
> I have a project with the following structure:
> 
> root/
>CMakeLists.txt
>prog1/
>CMakeLists.txt
>Src/
>file1.f90
>prog2/
>CMakeLists.txt
>Src/
>file2.f90
> 
> where prog1, prog2 are individual projects.
> 
> I would like to add file1.90 to the build process of prog2. To do
> so, in the CMakeLists.txt file of prog2 project, I put:
> 
>set(SOURCES ../../prog1/Src/file1.f90
>Src/file2.f90)
> and further
>add_executable(prog2 ${SOURCES})
> 
> when compiling with CMake I get the following error:
> 
> ##
> CMake Error at CMakeLists.txt:35 (add_executable):
>  Cannot find source file:
> 
>../../prog1/Src/file1.f90
> 
>  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
> .hpp  .hxx .in .txx
> ###
> 
> It seems that CMake cna not deal with relative path when declaring
> the sources for a project.

Relative paths work just fine, but your expecting a different base-path
than cmake is. In the above example the current directory when
assembling the sources is root/prog2 not root/prog2/Src which you seem
to assume. Hence you have one ".." too much in your set-line. This
should work:

set( SOURCES ../prog1/Src/file1.f90 Src/file2.f90 )

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] How to use add_custom_command correctly

[Rolf Eike Beer]

>
>
> On 27.09.11 18:24, Michael Wild wrote:
>> On 09/27/2011 05:59 PM, Martin Kupke wrote:
>>> Hi,
>>>
>>> in my project there is a subfolder which SHALL contain sources to
>>> generate a library. The problem is that at startup of the project there
>>> are no source files existing, because they will be generated by a code
>>> generator. This means within the build process the code generator needs
>>> to be called first, then generates the output files in the subfolder
>>> and
>>> then a library shall be generated from that source files (this are
>>> standard .c and .h files). If I start the code generator by hand to
>>> generate the source files and remove the custom command, then the
>>> compilation is successful, but I want the code generator to be started
>>> every time the configuration file for the code generator has changed.
>>>
>>> In my sample below
>>> * the driver.c would be one of the files which the code generator would
>>> generate
>>> * the variable CodeGen is the executable tool (the code generator
>>> himself)
>>> * the variable CodeGenParam contains the parameters which are passed to
>>> be able to generate without any user interaction
>>> * the variable CodeGenConfig is the input file for the code generator
>>>
>>> This subfolder contains its own CMakeLists.txt with the following
>>> settings:
>>> # snip #
>>> project(CANstack C)
>>>
>>> add_custom_command( OUTPUT driver.c
>>> COMMAND ${CodeGen}
>>> ${CodeGenParam}
>>> DEPENDS ${CodeGenConfig} )
>>> )
>>>
>>> file(GLOB CANstack_srcs "*.c")
>>> file(GLOB CANstack_hdrs "*.h")
>>>
>>> set(lib_name "CANstack")
>>> add_library(${lib_name} STATIC ${CANstack_srcs} ${CANstack_hdrs})
>>>
>>> # snap #
>>>
>>> I don't get it work that the custom command is called and the source
>>> files from the code generator are produced.
>>>
>> A few issues here:
>>
>> - Never generate output in the source tree, only in the binary tree.
>> - Always use absolute paths with add_custom_command().
> I use the absolute paths
>> - Always list *all* outputs after the OUTPUT argument, otherwise CMake
>> won't know that they are generated sources.
> I added the list of *all* files which shall be generated
>> - Never use file(GLOB ...). It is evil. And breaks in your case. Just
>> don't.
> I don't use the file(GLOB ...) anymore in this CMakeLists.txt
>> Michael
>>
> In case the generated output files already exist and the dependency file
> ${CodeGenConfig} has been touched, then the output will be generated.
>
> Typically there is from beginning of the project no source file
> existing, because the generator needs to be run first. If the output
> files are not existing, then I get an error message from CMake:
>
> # snip #
>
> CMake Error at Generated/CarIF_Appl/CANstack/CMakeLists.txt:31
> (add_library):
>Cannot find source file:
>
>  D:/project/Discovery/Generated/Driver/uart.c
>
>Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
> .hpp
>.hxx .in .txx
>
> # snap #
>
> How do I have to instruct CMake to run the code generator first, so that
> the library can be build of that sources?

Can you paste the relevant snippet from your new CMakeLists.txt?

You can try this first and see if it helps:

add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/driver.c
   COMMAND ${CodeGen} {CodeGenParam}
   DEPENDS ${CodeGenConfig} )

add_executable(myexe ${CMAKE_CURRENT_BINARY_DIR}/driver.c)

Of course you must tell the CodeGen where to put the result, preferably by
passing "${CMAKE_CURRENT_BINARY_DIR}/driver.c" as argument (with the
quotes, to make paths with spaces work right). If the generator can't
handle this you can try to set WORKING_DIRECTORY to
${CMAKE_CURRENT_BINARY_DIR}, passing all other file arguments with
absolute paths then.

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] multiple source directories

[Rolf Eike Beer]

> Hi all,
>
> I have a project with the following structure:
>
> root/
> CMakeLists.txt
> prog1/
> CMakeLists.txt
> Src/
> file1.f90
> prog2/
> CMakeLists.txt
> Src/
> file2.f90
>
> where prog1, prog2 are individual projects.
>
> I would like to add file1.90 to the build process of prog2. To do so, in
> the CMakeLists.txt file of prog2 project, I put:
>
> set(SOURCES ../../prog1/Src/file1.f90

Try ${CMAKE_CURRENT_SOURCE_DIR}/../../prog1/Src/file1.f90 here.

> Src/file2.f90)
> and further
> add_executable(prog2 ${SOURCES})

Then it should work.

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] multiple source directories

[Martin Kupke]

I have a same problem (even relative paths should not be used, as I 
understood from documentation) and I fixed my problem by setting a 
variable in the /root/CMakeLists.txt e.g.

set( MY_PROJECT_PROG1 ${CMAKE_CURRENT_SOURCE_DIR}/prog1 )
set( MY_PROJECT_PROG2 ${CMAKE_CURRENT_SOURCE_DIR}/prog2 )
The subprojects / subfolders always inherit the settings / variables, so 
you can work with ${MY_PROJECT_PROG1} in your /root/prog1/CMakeLists.txt.


Martin

On 28.09.11 12:51, pellegrini wrote:

Hi all,

I have a project with the following structure:

root/
 CMakeLists.txt
 prog1/
 CMakeLists.txt
 Src/
 file1.f90
 prog2/
 CMakeLists.txt
 Src/
 file2.f90

where prog1, prog2 are individual projects.

I would like to add file1.90 to the build process of prog2. To do so, in
the CMakeLists.txt file of prog2 project, I put:

 set(SOURCES ../../prog1/Src/file1.f90
 Src/file2.f90)
and further
 add_executable(prog2 ${SOURCES})

when compiling with CMake I get the following error:

##
CMake Error at CMakeLists.txt:35 (add_executable):
   Cannot find source file:

 ../../prog1/Src/file1.f90

   Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp  .hxx .in .txx
###

It seems that CMake cna not deal with relative path when declaring the
sources for a project. I tried using the option CMAKE_USE_RELATIVE_PATHS
but it might not be defined for that purpose as it did not solve the
problem. Would you have any idea how to solve that problem ?

thanks a lot

Eric






--



*martin kupke*

can diagnostics engineer | senior software developer

*m*:+49.151.5511.3632| *e*:martin.ku...@novero.com 



skype:martin.kupke_novero | w:www.novero.com 

novero GmbH
meesmannstr.103 | 44807 Bochum | germany


novero gmbh | parsevalstr. 7 a | 40468 düsseldorf | germany | 
amtsgericht düsseldorf | hrb 58283 | umsatzsteueridentifikationsnummer: 
de 814973142 | geschäftsführender gesellschafter: razvan olosu


--

Powered by www.kitware.com

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

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

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

Re: [CMake] How to use add_custom_command correctly

[Martin Kupke]

On 27.09.11 18:24, Michael Wild wrote:

On 09/27/2011 05:59 PM, Martin Kupke wrote:

Hi,

in my project there is a subfolder which SHALL contain sources to
generate a library. The problem is that at startup of the project there
are no source files existing, because they will be generated by a code
generator. This means within the build process the code generator needs
to be called first, then generates the output files in the subfolder and
then a library shall be generated from that source files (this are
standard .c and .h files). If I start the code generator by hand to
generate the source files and remove the custom command, then the
compilation is successful, but I want the code generator to be started
every time the configuration file for the code generator has changed.

In my sample below
* the driver.c would be one of the files which the code generator would
generate
* the variable CodeGen is the executable tool (the code generator himself)
* the variable CodeGenParam contains the parameters which are passed to
be able to generate without any user interaction
* the variable CodeGenConfig is the input file for the code generator

This subfolder contains its own CMakeLists.txt with the following settings:
# snip #
project(CANstack C)

add_custom_command( OUTPUT driver.c
COMMAND ${CodeGen}
${CodeGenParam}
DEPENDS ${CodeGenConfig} )
)

file(GLOB CANstack_srcs "*.c")
file(GLOB CANstack_hdrs "*.h")

set(lib_name "CANstack")
add_library(${lib_name} STATIC ${CANstack_srcs} ${CANstack_hdrs})

# snap #

I don't get it work that the custom command is called and the source
files from the code generator are produced.


A few issues here:

- Never generate output in the source tree, only in the binary tree.
- Always use absolute paths with add_custom_command().

I use the absolute paths

- Always list *all* outputs after the OUTPUT argument, otherwise CMake
won't know that they are generated sources.

I added the list of *all* files which shall be generated

- Never use file(GLOB ...). It is evil. And breaks in your case. Just don't.

I don't use the file(GLOB ...) anymore in this CMakeLists.txt

Michael

In case the generated output files already exist and the dependency file 
${CodeGenConfig} has been touched, then the output will be generated.


Typically there is from beginning of the project no source file 
existing, because the generator needs to be run first. If the output 
files are not existing, then I get an error message from CMake:


# snip #

CMake Error at Generated/CarIF_Appl/CANstack/CMakeLists.txt:31 
(add_library):

  Cannot find source file:

D:/project/Discovery/Generated/Driver/uart.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

# snap #

How do I have to instruct CMake to run the code generator first, so that 
the library can be build of that sources?


Br,
Martin

--

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] multiple source directories

[pellegrini]

Hi all,

I have a project with the following structure:

root/
   CMakeLists.txt
   prog1/
   CMakeLists.txt
   Src/
   file1.f90
   prog2/
   CMakeLists.txt
   Src/
   file2.f90

where prog1, prog2 are individual projects.

I would like to add file1.90 to the build process of prog2. To do so, in 
the CMakeLists.txt file of prog2 project, I put:


   set(SOURCES ../../prog1/Src/file1.f90
   Src/file2.f90)
and further
   add_executable(prog2 ${SOURCES})

when compiling with CMake I get the following error:

##
CMake Error at CMakeLists.txt:35 (add_executable):
 Cannot find source file:

   ../../prog1/Src/file1.f90

 Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm 
.hpp  .hxx .in .txx

###

It seems that CMake cna not deal with relative path when declaring the 
sources for a project. I tried using the option CMAKE_USE_RELATIVE_PATHS
but it might not be defined for that purpose as it did not solve the 
problem. Would you have any idea how to solve 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] Converting QMake project to CMake

[Stephen Kelly]

NoRulez wrote:

> Hi,
> 
> i'm trying to convert a qmake project to CMake.
> How can i translate "CONFIG" to CMake or what is the CMake's way of using
> the CONFIG variable?
> 
> e.g. CONFIG += mylib
> 
> Is this the CMake equivalent: SET(mylib TRUE)

No, probably not.

What does CONFIG += mylib do for a third party lib?

This link says CONFIG only accepts values with internal meaning to qmake:

http://doc.qt.nokia.com/latest/qmake-variable-reference.html#config

Thanks,

Steve.


--

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] (no subject)

[Rolf Eike Beer]

>
> Hello,
> I'm having trouble getting FIND_PATH to work in a certain case. I have it
> working in other Find*.cmake files, but in one of my files I cannot seem
> to get it to cooperate and cmake --trace/--debug-output don't seem to
> provide any useful information for debugging FIND_PATH.
> The problem is that cmake generates a "NOTFOUND" error when using the
> following cmake file (DEV_ROOT is set to /home/jlk/dev):
> FindTinyXML.cmake:
> FIND_PATH( TinyXML_INCLUDE_DIRSNAMES   tinyxml.h
> PATHS   $ENV{DEV_ROOT}/externals/tinyxml )
> MESSAGE( STATUS ${TinyXML_INCLUDE_DIRS} )MESSAGE( STATUS
> $ENV{DEV_ROOT}/externals/tinyxml )
> FIND_LIBRARY( TinyXML_LIBRARY_DebugNAMES   tinyxml
>PATHS   $ENV{DEV_ROOT}/externals/tinyxml/Debug )
> FIND_LIBRARY( TinyXML_LIBRARY_ReleaseNAMES   tinyxml
>  PATHS   $ENV{DEV_ROOT}/externals/tinyxml/Release )
> SET( TinyXML_FOUND FALSE )
> IF( TinyXML_INCLUDE_DIRS )SET( TinyXML_FOUND TRUE )SET(
> TinyXML_LIBRARIES ${TinyXML_LIBRARIES}debug
> ${TinyXML_LIBRARY_Debug}optimized   ${TinyXML_LIBRARY_Release}
> )ENDIF()
> The two MESSAGE outputs from cmake are:
> -- TinyXML_INCLUDE_DIRS-NOTFOUND-- /home/jlk/dev/externals/tinyxml
>
> The part I do not understand is if I execute an ls command like so: ls -la
> /home/jlk/dev/externals/tinyxml/tinyxml.h
> The output I get is: -rw-r--r-- 1 jlk jlk 64574 2011-09-27 02:58
> /home/jlk/dev/externals/tinyxml/tinyxml.h
> Which, as far as I understand it, is the file that cmake should be looking
> for. Does anyone know what could be wrong? As I said, I have other
> Find*.cmake files that work and I just can't seem to spot the problem.

My first attempt would be to run the cmake process trough "strace -f
-eopen,stat cmake ..." and look which files it is actually looking at.

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

[CMake] (no subject)

[Ju-Lian Kwan]

Hello,
I'm having trouble getting FIND_PATH to work in a certain case. I have it 
working in other Find*.cmake files, but in one of my files I cannot seem to get 
it to cooperate and cmake --trace/--debug-output don't seem to provide any 
useful information for debugging FIND_PATH.
The problem is that cmake generates a "NOTFOUND" error when using the following 
cmake file (DEV_ROOT is set to /home/jlk/dev):
FindTinyXML.cmake:
FIND_PATH( TinyXML_INCLUDE_DIRSNAMES   tinyxml.hPATHS   
$ENV{DEV_ROOT}/externals/tinyxml )
MESSAGE( STATUS ${TinyXML_INCLUDE_DIRS} )MESSAGE( STATUS 
$ENV{DEV_ROOT}/externals/tinyxml )
FIND_LIBRARY( TinyXML_LIBRARY_DebugNAMES   tinyxml  
  PATHS   $ENV{DEV_ROOT}/externals/tinyxml/Debug )
FIND_LIBRARY( TinyXML_LIBRARY_ReleaseNAMES   tinyxml
PATHS   $ENV{DEV_ROOT}/externals/tinyxml/Release )
SET( TinyXML_FOUND FALSE )
IF( TinyXML_INCLUDE_DIRS )SET( TinyXML_FOUND TRUE )SET( 
TinyXML_LIBRARIES ${TinyXML_LIBRARIES}debug   
${TinyXML_LIBRARY_Debug}optimized   ${TinyXML_LIBRARY_Release} 
)ENDIF()
The two MESSAGE outputs from cmake are:
-- TinyXML_INCLUDE_DIRS-NOTFOUND-- /home/jlk/dev/externals/tinyxml

The part I do not understand is if I execute an ls command like so: ls -la 
/home/jlk/dev/externals/tinyxml/tinyxml.h
The output I get is: -rw-r--r-- 1 jlk jlk 64574 2011-09-27 02:58 
/home/jlk/dev/externals/tinyxml/tinyxml.h
Which, as far as I understand it, is the file that cmake should be looking for. 
Does anyone know what could be wrong? As I said, I have other Find*.cmake files 
that work and I just can't seem to spot the problem.




  --

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] Does find_library check that a found library does in fact link?

[Eric Noulard]

2011/9/28 Michael Wild :
> On 09/28/2011 07:47 AM, Clifford Yapp wrote:
>>
>>
>> On Wed, Sep 28, 2011 at 12:13 AM, Michael Wild > > wrote:
>>
>>     On 09/28/2011 02:44 AM, Clifford Yapp wrote:
>>     > I've run into a situation where find_library is returning a symlink:
>>     >
>>     > /usr/lib/libblah.so -> libblah.so.1
>>     >
>>     >  but libblah.so.1 does not actually exist (e.g. the symlink is bad).
>>     >
>>     > Is there an option I can set to have find_library ensure that a found
>>     > library file is valid and links?
>>     >
>>     > Cheers,
>>     > CY
>>     >
>>
>>     Yes, but you need to do it yourself, e.g. use the CheckFunctionExists
>>     module.
>>
>>     Michael
>>
>>
>> Urm.  That's surprising, and not so hot in that it leads to "false
>> positives" in find_library reports.  Has anyone wrapped find_library
>> with a generic linking test successfully?
>>
>> CY
>
> Only if your installation is broken ;-) If the symlink is broken, I
> consider this to be a user-error. Period. OTOH, CMake /could/ check
> whether the library is a symlink, and if it is, check that it is valid.

I agree that the breakage is on user side and not CMake.
However CMake may just warn that the found symlink is broken,
and nothing more.
At least the user won't be puzzled by a non-working build.


> But how do you test whether a library is "linkable"? Specifically, I'm
> thinking about static libraries. First, only referenced symbols are
> linked, so that's kind of difficult to handle as CMake would need to
> know at least one symbol name to force the library to be linked at all,
> secondly static libraries may have transitive dependencies which CMake
> doesn't know about, so it's not possible to link an executable. On Unix
> you could create a shared library for the link test, but that depends on
> the linker flags being used, and on Windows you can't, since DLL's may
> not contain unresolved symbols.
>
> I don't think that there is any good way to handle this in find_library().

Agreed as well but this is another story.


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