Re: [CMake] Forcing CMake to place targets in directories?

[Robert Dailey]

I wanted my vcproj files to be placed in "test_projects". Any idea how I can
make this happen?

On Thu, Dec 4, 2008 at 8:30 PM, Mike Jackson <[EMAIL PROTECTED]>wrote:

> CMAKE_CURRENT_SOURCE_DIR denotes your source tree and NOT the build
> tree. Are you building in your source tree instead of using a
> dedicated build directory?
>
> To answer your code you are setting the output directory of where the
> executable will be placed in a directory called "test_projects" at the
> top level of your build tree.
>
> Mike Jackson
>
>
> On Thu, Dec 4, 2008 at 7:40 PM, Robert Dailey <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I'm trying to use set_target_properties() to make CMake place generated
> > vcproj files in a subdirectory of ${CMAKE_CURRENT_SOURCE_DIR}. This isn't
> > working and I'm not sure what I'm doing wrong. Below is what I'm doing:
> >
> > set( test_project_name ${project_name}_test_${test_name} )
> > project( ${test_project_name} )
> > source_group( "" ${file} )
> > add_executable( ${test_project_name} ${file} )
> > set_target_properties( ${test_project_name} PROPERTIES
> > OUTPUT_NAME test_projects/${test_project_name} )
> >
> > My project should be getting placed inside of a test_projects
> subdirectory,
> > right?
> >
> > ___
> > CMake mailing list
> > CMake@cmake.org
> > http://www.cmake.org/mailman/listinfo/cmake
> >
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Forcing CMake to place targets in directories?

[Mike Jackson]

CMAKE_CURRENT_SOURCE_DIR denotes your source tree and NOT the build
tree. Are you building in your source tree instead of using a
dedicated build directory?

To answer your code you are setting the output directory of where the
executable will be placed in a directory called "test_projects" at the
top level of your build tree.

Mike Jackson


On Thu, Dec 4, 2008 at 7:40 PM, Robert Dailey <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm trying to use set_target_properties() to make CMake place generated
> vcproj files in a subdirectory of ${CMAKE_CURRENT_SOURCE_DIR}. This isn't
> working and I'm not sure what I'm doing wrong. Below is what I'm doing:
>
> set( test_project_name ${project_name}_test_${test_name} )
> project( ${test_project_name} )
> source_group( "" ${file} )
> add_executable( ${test_project_name} ${file} )
> set_target_properties( ${test_project_name} PROPERTIES
> OUTPUT_NAME test_projects/${test_project_name} )
>
> My project should be getting placed inside of a test_projects subdirectory,
> right?
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to make ctest not buffer its output?

[Daniel Nelson]

Alexander Neundorf wrote:

On Thursday 04 December 2008, Hugo Heden wrote:

Good day all,

I use ctest --build-and-test to do some stuff that takes a long time.
It seems that ctest buffers the output of its subcommands so that
nothing is written (to the "terminal") until at the end. This is a
little unconvenient -- as a human I feel more comfortable actually
seeing that "something is happening".

Is there a way I can force ctest to not buffer the output of
subcommands, but rather just flush it?


Does ctest -VV do what you want ?
It switches to "extra verbose" mode.



I submitted this some time ago as bug 0005814.  I don't believe there is 
a way to view the output until the test finishes.

--
Daniel
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] 'unset' not in --help-commands-list (also, attn: neundorf)

[Philip Lowman]

On Thu, Dec 4, 2008 at 5:36 PM, Matthew Woehlke <
[EMAIL PROTECTED]> wrote:

> Philip Lowman wrote:
>
>> On Tue, Nov 18, 2008 at 6:39 PM, Matthew Woehlke  wrote:
>>
>>> Need a bug opened for this or is it trivial enough to fix on the spot?
>>>
>>
>> unset appears to be in --help-commands and --help-command-list.  Was this
>> a
>> bug?  If so, how was it fixed?
>>
>
> Not for me it doesn't?
>
> $ cmake --help-command unset
> cmake version 2.6-patch 2
> Argument "unset" to --help-command is not a CMake command.  Use
> --help-command-list to see all commands.
> $ rpm -q cmake
> cmake-2.6.2-1.fc10.x86_64
>
> What version of cmake are you looking at? Maybe I am wrong what version
> introduces 'unset'?


As far as I know the unset command hasn't been backported to the CMake 2.6.x
branch.  If you want to use it in your scripts you probably would need to be
running CVS CMake.

-- 
Philip Lowman
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Forcing CMake to place targets in directories?

[Robert Dailey]

Hi,

I'm trying to use set_target_properties() to make CMake place generated
vcproj files in a subdirectory of ${CMAKE_CURRENT_SOURCE_DIR}. This isn't
working and I'm not sure what I'm doing wrong. Below is what I'm doing:

set( test_project_name ${project_name}_test_${test_name} )
project( ${test_project_name} )
source_group( "" ${file} )
add_executable( ${test_project_name} ${file} )
set_target_properties( ${test_project_name} PROPERTIES
OUTPUT_NAME test_projects/${test_project_name} )

My project should be getting placed inside of a test_projects subdirectory,
right?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] MSVC71 WholeProgramOptimization flags (/LTCG and /GL)

[Luke Kucalaba]

Hi,

 

I would like to reopen issue #0006794 dealing with this linker warning
that is still present for MSVC 7.1 static library builds:

 

Linking CXX static library ..\build\MT-DLL\Util-SL.lib

XMLWriter.cpp.obj : warning LNK4218: non-native module found; restarting

 

I did some more investigation of this problem, and I think I've nailed
it down now. I thought it was the missing WholeProgramOptimization
element that was causing the warning, when in fact it is the missing
"/LTCG" flag that should be in the Librarian additional command-line
options. I realize that for a static library project the linker flags
are not included in the generated project file, but this should be an
exception case to that rule. As a general rule of thumb, if the /GL
compiler flag is passed to a static library project, then the /LTCG flag
should be passed to the Librarian AdditionalOptions line.

 



 

Thank you for your time and effort. I appreciate the hard work that you
have all done to make and keep CMake a high-quality software product.

 

Sincerely,

Luke

 

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] source_group() and solution directories

[David . Karr]

> By directories I mean "Solution Folders", sorry for the confusion.
> This is a feature that allows you to add "Folders" to the solution.
> This has nothing to do with projects. You can add files to these
> solution folders. Solution folders are at the same level tree-wise
> as projects are (Directly under the solution). There are a couple
> of projects that I have that do not have any implementation files
> (Don't ask why lol). For these, I need solution folders since
> creating a project for these won't work- A project needs at least
> 1 CPP file to be usable.

So, for example, I open a .SLN file generated by CMake, look in the 
"Solution Explorer" pane of Visual Studio 2008, and see the infamous 
ALL_BUILD in the list between two of my projects. (I haven't opened
any of these projects yet, so the entire list is at one level of
indentation below the "Solution" icon.)

ALL_BUILD shows up in this list because there's a file 
ALL_BUILD.vcproj in the same directory as my .SLN file in 
the filesystem.  And there are no .CPP files that are built by 
ALL_BUILD itself (though of course ALL_BUILD depends on projects
that do build .CPP files).

I tend to call ALL_BUILD a "project" because it shows up at the 
same level of the hierarchy as all the projects in Solution Explorer 
and because the "proj" in the filename ALL_BUILD.vcproj suggests 
the word "project" to me.  But I suppose technically I should call 
it a "target".

Anyway, I'm pretty sure now I completely misread the earlier email.
Not so sure I read it correctly this time, though.


> I'm hoping source_group() can be used without any project and
> simply add solution folders to the solution.

Actually this seems counterintuitive to me.  There's no other case 
in which SOURCE_GROUP by itself would cause a .VCPROJ file to be 
generated.  And the icon that shows up in Solution Explorer looks 
like a little manila file folder (the kind you could buy at a 
stationery store in 1970, before some genius decided it was a 
synonym for "filesystem directory"), whereas the icon for a 
"project" in Solution Explorer looks completely different 
(but is identical to the icon for ALL_BUILD).  I guess one could 
question why one level of the hierarchy is different from all 
other levels, but it _is_ different (blame the designers of 
Visual Studio) and I think it would be too confusing to 
pretend otherwise.

Also, you specifically don't want any source files in the thing 
you're creating, which seems already to say it's not a "source group".

It seems to me that what you want is a command that you can use 
instead of ADD_LIBRARY or ADD_EXECUTABLE to create a new target. 
Actually I think there are some such commands; maybe one of them 
does what you want (but if so, someone else will have to explain
it, because I don't know how to use any of those commands).
Otherwise, it seems to me you need a new command.

David

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] what is wrong with this snippet? (bug?)

[Matthew Woehlke]

Bill Hoffman wrote:

Matthew Woehlke wrote:

Matthew Woehlke wrote:

set(!BANG wacky CACHE STRING "" FORCE)
set("var with space" wacky CACHE STRING "" FORCE)
message(STATUS "This is !BANG: ${!BANG}")
message(STATUS "This is var with space: ${var with space}")

The above snippet (as expected) causes a CMake error. What's 
interesting is that the error is in the message, not the set. More 
so, the variables do indeed end up in the cache!


The utility of a variable that can't be referenced seems... dubious. 
Should CMake prevent this?


(cmake 2.6-2)


ping?


Please create a bug entry.


Done [1], and thanks. I wasn't sure how this was supposed to work.

 Also, don't create variables with odd 
characters in them as CMake does not correctly warn that this is invalid 
right now.  :)


No worries, I was actually hoping the set would fail also. As mentioned 
in [2] I was trying to work around bug 8226 [3], and wanted to verify 
that such variables were invalid. So, I hope they will stay invalid ;-). 
(But yes, it would be good for SET to fail, as well as expansion.)


1: http://public.kitware.com/Bug/view.php?id=8228
2: http://permalink.gmane.org/gmane.comp.programming.tools.cmake.user/17555
3: http://public.kitware.com/Bug/view.php?id=8226

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Microsoft, electricity, network connectivity. For a secure system pick 
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] if(MATCHES) broken??

[Matthew Woehlke]

Bill Hoffman wrote:

Matthew Woehlke wrote:


ping?


I have created a bug report:

http://public.kitware.com/Bug/view.php?id=8226


No ETA right now.


Ok, thanks.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Microsoft, electricity, network connectivity. For a secure system pick 
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] source_group() and solution directories

[Robert Dailey]

On Thu, Dec 4, 2008 at 4:48 PM, <[EMAIL PROTECTED]> wrote:

> > Is it possible to have source_group() place files into
> > a "solution directory"? This would be a folder directly
> > under the solution instead of inside of a project.
>
> I'm confused, because I don't think of SOURCE_GROUP() as
> placing any files in any directory.  Instead, you need to
> call ADD_EXECUTABLE or ADD_LIBRARY to create a Visual Studio
> "project" file (DSP or VCPROJ), and all SOURCE_GROUP does
> is to specify which file names are in one of the "folders"
> described within that DSP or VCPROJ file.
>
> And of course the DSP or VCPROJ file specifies many
> different kinds of files that Visual Studio will produce.
> I've already asked the mailing list how to control where
> each one of _those_ files will be written.  See my message
> in the list archive:
>
> http://www.cmake.org/pipermail/cmake/2008-December/025803.html
>
> If this has anything to do with what you're requesting,
> maybe we should combine the two requests.
>
> By the way, I've been following your other emails, and
> they remind me of some of what I went through when I first
> tried to apply CMake to an already existing software project
> about five years ago.  (Yes, it did ultimately work and
> we've been using it on that project ever since.)


Thanks for getting back with me David.

By directories I mean "Solution Folders", sorry for the confusion. This is a
feature that allows you to add "Folders" to the solution. This has nothing
to do with projects. You can add files to these solution folders. Solution
folders are at the same level tree-wise as projects are (Directly under the
solution). There are a couple of projects that I have that do not have any
implementation files (Don't ask why lol). For these, I need solution folders
since creating a project for these won't work- A project needs at least 1
CPP file to be usable.

I'm hoping source_group() can be used without any project and simply add
solution folders to the solution.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] what is wrong with this snippet? (bug?)

[Bill Hoffman]

Matthew Woehlke wrote:

Matthew Woehlke wrote:

set(!BANG wacky CACHE STRING "" FORCE)
set("var with space" wacky CACHE STRING "" FORCE)
message(STATUS "This is !BANG: ${!BANG}")
message(STATUS "This is var with space: ${var with space}")

The above snippet (as expected) causes a CMake error. What's 
interesting is that the error is in the message, not the set. More so, 
the variables do indeed end up in the cache!


The utility of a variable that can't be referenced seems... dubious. 
Should CMake prevent this?


(cmake 2.6-2)


ping?

Please create a bug entry.  Also, don't create variables with odd 
characters in them as CMake does not correctly warn that this is invalid 
right now.  :)



-Bill

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] if(MATCHES) broken??

[Bill Hoffman]

Matthew Woehlke wrote:


ping?


I have created a bug report:

http://public.kitware.com/Bug/view.php?id=8226


No ETA right now.

-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] what is wrong with this snippet? (bug?)

[Matthew Woehlke]

Matthew Woehlke wrote:

set(!BANG wacky CACHE STRING "" FORCE)
set("var with space" wacky CACHE STRING "" FORCE)
message(STATUS "This is !BANG: ${!BANG}")
message(STATUS "This is var with space: ${var with space}")

The above snippet (as expected) causes a CMake error. What's interesting 
is that the error is in the message, not the set. More so, the variables 
do indeed end up in the cache!


The utility of a variable that can't be referenced seems... dubious. 
Should CMake prevent this?


(cmake 2.6-2)


ping?

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Microsoft, electricity, network connectivity. For a secure system pick 
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about transitive dependencies

[Bill Hoffman]

Robert Dailey wrote:



In your sample code above, I noticed you didn't use add_dependencies(). 
Does target_link_libraries() guarantee build order when targets are 
specified instead of libraries?

Yes.

-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] if(MATCHES) broken??

[Matthew Woehlke]

Matthew Woehlke wrote:

Bill Hoffman wrote:
The problem is that if(something MATCHES something) works for either 
strings or variable names.  The way that works is by checking to see 
if there is a variable defined by the string given to if.  Even if 
that string is in quotes, it can still be treated like a variable.


So, in this case cmake looks up "CFLAGS" and finds that there is a 
variable of that name, and uses that value for the MATCHES statement. 
Basically ending up with if("happyjoy" MATCHES "CFLAGS").  You can 
verify this by commenting out set(CFLAGS happyjoy) so that CFLAGS does 
not have a definition, then your code works.


Yes, I figured that out. Hmm... at least it's documented, if annoying.

After poking at this further, there seems to be a bug here... we've 
established that 'if(CFLAGS MATCHES CFLAGS)' expands the variable on the 
LHS. That being the case, then it seems - from my reading of the doc - 
that 'if(CFLAGS STREQUAL CFLAGS)' should be doing likewise, i.e. both 
should be false. Further, it seems that 'if(bar MATCHES "CFLAGS")' does 
*not* expand bar... why?



I agree this is confusing...  Perhaps there should be some new if
arguments that are always string based, and never look up variables.


What about simply inhibiting "expansion" when the LHS is quoted? (I 
guess the concern would be compatibility? But given that the current 
behavior seems buggy - i.e. inconsistent - already...) Since variable 
names can't contain spaces (ah, they can't, right? :-) ), it seems 
reasonable that if you are trying to dereference a variable that is 
supposed to contain the name of another variable, whose value you want 
to use, that this seems to make sense.


OTOH, given that '${${bar}}' is a legal construct that does exactly what 
you'd expect (namely, expand the variable whose name is the expansion of 
bar), I'm inclined to question using implicit expansion at all. But... 
it can be convenient, so maybe that would be too much. Inhibiting 
"expansion" in quoted-strings seems reasonable, though. (After all, 
who's putting things that are supposed to be variable names in quotes?)


ping?

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Microsoft, electricity, network connectivity. For a secure system pick 
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] 'unset' not in --help-commands-list (also, attn: neundorf)

[Matthew Woehlke]

Philip Lowman wrote:

On Tue, Nov 18, 2008 at 6:39 PM, Matthew Woehlke  wrote:

Need a bug opened for this or is it trivial enough to fix on the spot?


unset appears to be in --help-commands and --help-command-list.  Was this a
bug?  If so, how was it fixed?


Not for me it doesn't?

$ cmake --help-command unset
cmake version 2.6-patch 2
Argument "unset" to --help-command is not a CMake command.  Use 
--help-command-list to see all commands.

$ rpm -q cmake
cmake-2.6.2-1.fc10.x86_64

What version of cmake are you looking at? Maybe I am wrong what version 
introduces 'unset'?


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Microsoft, electricity, network connectivity. For a secure system pick 
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about transitive dependencies

[Robert Dailey]

On Thu, Dec 4, 2008 at 4:20 PM, Bill Hoffman <[EMAIL PROTECTED]>wrote:

> Robert Dailey wrote:
>
>  On Thu, Dec 4, 2008 at 4:06 PM, Alexander Neundorf <
>> [EMAIL PROTECTED] > wrote:
>>
>>But, if you do in cmake:
>>target_link_libraries(staticLibB staticLibA)
>>this will not really link (as it would for a shared lib), but it will
>>nevertheless keep track of the dependencies.
>>So when liking
>>target_link_libraries(myApp staticLibB)
>>cmake knows that it has to add staticLibA to the linker command.
>>
>>
>> But that's one of the things that really bothers me. This is that
>> redundancy I was talking about earlier. If I do:
>>
>> add_dependencies( C B )
>> target_link_libraries( C staticLibB )
>>
>> It's a bit pointless. For example, CMake should be smart enough to know
>> that by adding a dependency to B, it should look at the library that it is
>> outputting (In this case, staticLibB.lib) and add that to an implicit call
>> to target_link_libraries(). I only want to use target_link_libraries() to
>> link against external third party libraries that aren't explicitly
>> represented as a project in my CMake build process.
>>
>> If I decide to change the output name for the static library B outputs,
>> I'm forced to then revisit all of the target_link_libraries() calls and
>> rename staticLibB. This is a management issue (amongst other things).
>>
>>
>>  You are missing something.  The output name has nothing to do with the
> name used in target_link_libraries.  add_dependencies has nothing to do with
> linking.   It adds an artificial depend between two targets to make sure one
> is built before the other one for whatever reason needed.   If you want to
> link something, you should use target_link_libraries.  For arguments to
> target_link_libraries you should use the name of the target.
>
>
> add_library(A ...)
> add_library(B ...)
> target_link_libraries(B A)
> add_executable(C ...)
> target_link_libraries(C B)
>
> The above will link C to B and A.   The output names of B and A will be
> correctly used when linking C.


In your sample code above, I noticed you didn't use add_dependencies(). Does
target_link_libraries() guarantee build order when targets are specified
instead of libraries?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about transitive dependencies

[Bill Hoffman]

Robert Dailey wrote:
On Thu, Dec 4, 2008 at 4:06 PM, Alexander Neundorf 
<[EMAIL PROTECTED] > wrote:


But, if you do in cmake:
target_link_libraries(staticLibB staticLibA)
this will not really link (as it would for a shared lib), but it will
nevertheless keep track of the dependencies.
So when liking
target_link_libraries(myApp staticLibB)
cmake knows that it has to add staticLibA to the linker command.


But that's one of the things that really bothers me. This is that 
redundancy I was talking about earlier. If I do:


add_dependencies( C B )
target_link_libraries( C staticLibB )

It's a bit pointless. For example, CMake should be smart enough to know 
that by adding a dependency to B, it should look at the library that it 
is outputting (In this case, staticLibB.lib) and add that to an implicit 
call to target_link_libraries(). I only want to use 
target_link_libraries() to link against external third party libraries 
that aren't explicitly represented as a project in my CMake build process.


If I decide to change the output name for the static library B outputs, 
I'm forced to then revisit all of the target_link_libraries() calls and 
rename staticLibB. This is a management issue (amongst other things).



You are missing something.  The output name has nothing to do with the 
name used in target_link_libraries.  add_dependencies has nothing to do 
with linking.   It adds an artificial depend between two targets to make 
sure one is built before the other one for whatever reason needed.   If 
you want to link something, you should use target_link_libraries.  For 
arguments to target_link_libraries you should use the name of the target.



add_library(A ...)
add_library(B ...)
target_link_libraries(B A)
add_executable(C ...)
target_link_libraries(C B)

The above will link C to B and A.   The output names of B and A will be 
correctly used when linking C.


-Bill

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about transitive dependencies

[David Cole]

target_link_libraries takes target names as its arguments as well as full
paths to libraries. Just use CMake target names in target_link_libraries
calls and do NOT use add_dependencies for libraries.
add_dependencies is very useful for custom targets and custom commands to
guarantee build order. I have never heard of anybody else using it to add
library-to-library or executable-to-library dependencies.

target_link_libraries is really the way to go.


On Thu, Dec 4, 2008 at 5:12 PM, Robert Dailey <[EMAIL PROTECTED]> wrote:

> On Thu, Dec 4, 2008 at 4:06 PM, Alexander Neundorf <
> [EMAIL PROTECTED]> wrote:
>
>> But, if you do in cmake:
>> target_link_libraries(staticLibB staticLibA)
>> this will not really link (as it would for a shared lib), but it will
>> nevertheless keep track of the dependencies.
>> So when liking
>> target_link_libraries(myApp staticLibB)
>> cmake knows that it has to add staticLibA to the linker command.
>
>
> But that's one of the things that really bothers me. This is that
> redundancy I was talking about earlier. If I do:
>
> add_dependencies( C B )
> target_link_libraries( C staticLibB )
>
> It's a bit pointless. For example, CMake should be smart enough to know
> that by adding a dependency to B, it should look at the library that it is
> outputting (In this case, staticLibB.lib) and add that to an implicit call
> to target_link_libraries(). I only want to use target_link_libraries() to
> link against external third party libraries that aren't explicitly
> represented as a project in my CMake build process.
>
> If I decide to change the output name for the static library B outputs, I'm
> forced to then revisit all of the target_link_libraries() calls and rename
> staticLibB. This is a management issue (amongst other things).
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [Fwd: Re: Why does dependency scanning in version 2.6 seem so slow?]

[Jose Luis Blanco]

These are my results: All the details go below, but in two computers, both
with cmake 2.6.0 (from the Ubuntu repositories), it takes ~ 50sec vs. 19sec
to recompile when only one file changes... and the longest delay happens in
the better PC, though the CPU's are very similar in speeds. Both cases are
local file systems (through ntfs, but the same in both cases).

In addition, I started with a fresh CMAKE_BINARY_DIR directory in both
cases.

Please, let me know if I can do any more logging.

Regards,
JL


=
PC #1
DESKTOP PC, QuadCore 2.4Ghz:
=

==> touch'ing just one .cpp file in the project, the "time make VERBOSE=1"
gives:   49.882s

cd /home/jlblanco/code/mrpt-release && /usr/local/bin/cmake -E cmake_depends
"Unix Makefiles" /home/jlblanco/code/mrpt-src
/home/jlblanco/code/mrpt-src/src/core /home/jlblanco/code/mrpt-release
/home/jlblanco/code/mrpt-release/src/core
/home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/DependInfo.cmake
--color=

Most of the time goes in these 3 steps:

Dependee "/home/jlblanco/code/mrpt-src/src/core/math/CMatrix.cpp" is newer
than depender "src/core/CMakeFiles/mrpt-core.dir/math/CMatrix.o".
Clearing dependencies in
"/home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/depend.make".

Clearing dependencies in
"/home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/depend.make".

Scanning dependencies of target mrpt-core   Longest task

real0m49.882s
user0m5.424s
sys0m7.064s


==> without touching (just realizing there's nothing to do):  12.89s

Most of the time goes in:

cd /home/jlblanco/code/mrpt-release && /usr/local/bin/cmake -E cmake_depends
"Unix Makefiles" /home/jlblanco/code/mrpt-src
/home/jlblanco/code/mrpt-src/src/core /home/jlblanco/code/mrpt-release
/home/jlblanco/code/mrpt-release/src/core
/home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/DependInfo.cmake
--color=

real0m12.896s
user0m1.384s
sys0m1.560s


=
PC # 2
LAPTOP PC, DualCore 2.0Ghz:
=

==> touch'ing just one .cpp file in the project, the "time make VERBOSE=1"
gives:   18.78s

Most of the tiime goes to:

cd /home/jlblanco/code/mrpt-release && /usr/bin/cmake -E cmake_depends "Unix
Makefiles" /home/jlblanco/code/mrpt-src
/home/jlblanco/code/mrpt-src/src/core /home/jlblanco/code/mrpt-release
/home/jlblanco/code/mrpt-release/src/core
/home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/DependInfo.cmake
--color=
Dependee "/home/jlblanco/code/mrpt-src/src/core/utils/CMRPTImage.cpp" is
newer than depender "src/core/CMakeFiles/mrpt-core.dir/utils/CMRPTImage.o".
Clearing dependencies in
"/home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/depend.make".
Scanning dependencies of target mrpt-core

real0m18.788s
user0m7.456s
sys0m4.552s



==> without touching (just realizing there's nothing to do):  2.23s

real0m2.234s
user0m1.468s
sys0m0.528s






On Thu, Dec 4, 2008 at 4:02 AM, Bill Hoffman <[EMAIL PROTECTED]>wrote:

> Jose Luis Blanco wrote:
>
>> If this helps anyone, I'm working on a large project using CMake and in
>> two different computers, both with the same version of Ubuntu and cmake, it
>> is *REALLY SLOW* in only one of them while scanning dependencies, but it's
>> not in the other laptop.  (The "slow" dep. scanning is ~1 min. too)
>>
>> I'd be happy to help debugging this, because it's really annoying :-(
>>
>>  I wonder if it is hitting a network mount disk or something like that...
>  Are the same versions of cmake identical binaries?
>
> -Bill
>



-- 

___

Jose-Luis Blanco-Claraco  Phone: +34 952 132848
Dpto. Ingenieria de Sistemas y Automatica
E.T.S.I. Telecomunicacion   Fax: +34 952 133361
Universidad de Malaga
Campus Universitario de Teatinos
29071 Malaga, Spain

http://www.isa.uma.es/jlblanco
___
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about transitive dependencies

[Robert Dailey]

On Thu, Dec 4, 2008 at 4:06 PM, Alexander Neundorf
<[EMAIL PROTECTED]>wrote:

> But, if you do in cmake:
> target_link_libraries(staticLibB staticLibA)
> this will not really link (as it would for a shared lib), but it will
> nevertheless keep track of the dependencies.
> So when liking
> target_link_libraries(myApp staticLibB)
> cmake knows that it has to add staticLibA to the linker command.


But that's one of the things that really bothers me. This is that redundancy
I was talking about earlier. If I do:

add_dependencies( C B )
target_link_libraries( C staticLibB )

It's a bit pointless. For example, CMake should be smart enough to know that
by adding a dependency to B, it should look at the library that it is
outputting (In this case, staticLibB.lib) and add that to an implicit call
to target_link_libraries(). I only want to use target_link_libraries() to
link against external third party libraries that aren't explicitly
represented as a project in my CMake build process.

If I decide to change the output name for the static library B outputs, I'm
forced to then revisit all of the target_link_libraries() calls and rename
staticLibB. This is a management issue (amongst other things).
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about transitive dependencies

[Alexander Neundorf]

On Thursday 04 December 2008, John Doe wrote:
> Hello,
>
> This discussion is based on my knowledge of the Gnu Compiler Collection.
>
> My understanding of the linking process is that B will never link
> against A, because static libraries don't link against other static
> libraries.  Library B will have unresolved symbols when linking C.

That's correct.

> You must therefore add a dependency between C and A.
>
> Therefore:
> C links against B and A
> B doesn't link against anything
> B needs the header information for the functions of A.

That's also correct.
But, if you do in cmake:
target_link_libraries(staticLibB staticLibA)
this will not really link (as it would for a shared lib), but it will 
nevertheless keep track of the dependencies.
So when liking
target_link_libraries(myApp staticLibB)
cmake knows that it has to add staticLibA to the linker command.

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about transitive dependencies

[Robert Dailey]

On Thu, Dec 4, 2008 at 3:47 PM, David Cole <[EMAIL PROTECTED]> wrote:

> I think you're looking at Visual Studio project dependencies and not link
> dependencies. It should not build *without* target_link_libraries calls.
> They are necessary to get correct linker command lines. add_dependencies
> does not link any libraries to anything, it just guarantees project building
> order...


However, visual studio's option to "Link Library Dependencies" is enabled
for project C, so this shows up as my command line for project C:

*/OUT:"C:\IT\work\cmaketest\Debug\C.exe" /VERSION:0.0 /INCREMENTAL /NOLOGO
/LIBPATH:".\Debug" /LIBPATH:"." /MANIFEST
/MANIFESTFILE:"C.dir\Debug\C.exe.intermediate.manifest"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG
/PDB:"C:/IT/work/cmaketest/Debug/C.pdb" /SUBSYSTEM:CONSOLE /DYNAMICBASE
/NXCOMPAT /IMPLIB:"C:\IT\work\cmaketest\Debug\C.lib" /ERRORREPORT:PROMPT
kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  myClb.lib ".\debug\b.lib"
".\debug\z.lib" ".\debug\a.lib"*

Notice that both b.lib, z.lib, and a.lib are linked to C here. I'm only
using add_dependencies() and this happens. You state that it only guarantees
project building order, but why (for visual studio, at least) is it
providing link dependencies as well? Is this just an artifact of visual
studio? Can I expect this behavior to be portable to other CMake outputs?

I've also noticed another weird behavior that I can't seem to work around.
I've modified the code I previously posted to this:

cmake_minimum_required( VERSION 2.6 )

link_directories( ${CMAKE_CURRENT_SOURCE_DIR} )

project( Z )
add_library( Z STATIC Z.cpp )
target_link_libraries( Z Zlb )

project( A )
add_library( A STATIC A.cpp )
add_dependencies( A Z )

project( B )
add_library( B STATIC B.cpp )
add_dependencies( B A Z )
target_link_libraries( B Blb Bfoo )

project( C )
add_executable( C C.cpp )
add_dependencies( C B )
target_link_libraries( C myClb )

If you look at the command line I pasted earlier for project C, notice that
only myClb.lib is on the command line. I'm expecting to see Blb.lib,
Bfoo.lib, and Zlb.lib there as well. If I go to project B's command line, I
only see this:

*/OUT:"C:\IT\work\cmaketest\Debug\B.lib" /NOLOGO*

It's not even linking against Blb.lib or Bfoo.lib! Why are these target link
libraries being ignored?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about transitive dependencies

[David Cole]

I think you're looking at Visual Studio project dependencies and not link
dependencies. It should not build *without* target_link_libraries calls.
They are necessary to get correct linker command lines. add_dependencies
does not link any libraries to anything, it just guarantees project building
order...



On Thu, Dec 4, 2008 at 4:43 PM, Robert Dailey <[EMAIL PROTECTED]> wrote:

> On Thu, Dec 4, 2008 at 3:38 PM, Bill Hoffman <[EMAIL PROTECTED]>wrote:
>
>> Robert Dailey wrote:
>>
>>> Hi,
>>>
>>> Currently I have 3 projects named A, B, and C. A and B are both static
>>> libraries, and C is an executable. B depends on A, and C depends on B via
>>> add_dependencies(). When I generate a visual studio 9 project from this
>>> setup, how will the libraries be linked? The way I want this to work is for
>>> C to link against both A and B, and B will not link against A (Since B's
>>> dependencies should transfer to C). Is there a way to accomplish this
>>> behavior? I want to avoid using target_link_libraries for the most part
>>> because it's redundant. I'm already specifying B as a dependency of C
>>> through add_dependency(), why should I have to list B's static library file
>>> as a dependency of C's executable? Can't CMake pull this information from
>>> the call to add_dependency()?
>>>
>>>
>> Sounds like you should be using target_link_libraries instead of
>> add_dependency.
>
>
> I use target_link_libraries for only the case when I'm linking against
> libraries that are not part of the CMake project itself. After a quick test
> I found that John Doe's description of how this functions is correct. I
> tried the following CMake script:
>
> cmake_minimum_required( VERSION 2.6 )
>
> project( Z )
> add_library( Z STATIC Z.cpp )
>
> project( A )
> add_library( A STATIC A.cpp )
> add_dependencies( A Z )
>
> project( B )
> add_library( B STATIC B.cpp )
> add_dependencies( B A;Z )
>
> project( C )
> add_executable( C C.cpp )
> add_dependencies( C B )
>
> In this case, visual studio shows C to be linking against Z, A, and B. Both
> A and B, however, do not link against Z, which is exactly what I wanted.
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about transitive dependencies

[Robert Dailey]

On Thu, Dec 4, 2008 at 3:38 PM, Bill Hoffman <[EMAIL PROTECTED]>wrote:

> Robert Dailey wrote:
>
>> Hi,
>>
>> Currently I have 3 projects named A, B, and C. A and B are both static
>> libraries, and C is an executable. B depends on A, and C depends on B via
>> add_dependencies(). When I generate a visual studio 9 project from this
>> setup, how will the libraries be linked? The way I want this to work is for
>> C to link against both A and B, and B will not link against A (Since B's
>> dependencies should transfer to C). Is there a way to accomplish this
>> behavior? I want to avoid using target_link_libraries for the most part
>> because it's redundant. I'm already specifying B as a dependency of C
>> through add_dependency(), why should I have to list B's static library file
>> as a dependency of C's executable? Can't CMake pull this information from
>> the call to add_dependency()?
>>
>>
> Sounds like you should be using target_link_libraries instead of
> add_dependency.


I use target_link_libraries for only the case when I'm linking against
libraries that are not part of the CMake project itself. After a quick test
I found that John Doe's description of how this functions is correct. I
tried the following CMake script:

cmake_minimum_required( VERSION 2.6 )

project( Z )
add_library( Z STATIC Z.cpp )

project( A )
add_library( A STATIC A.cpp )
add_dependencies( A Z )

project( B )
add_library( B STATIC B.cpp )
add_dependencies( B A;Z )

project( C )
add_executable( C C.cpp )
add_dependencies( C B )

In this case, visual studio shows C to be linking against Z, A, and B. Both
A and B, however, do not link against Z, which is exactly what I wanted.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about transitive dependencies

[Bill Hoffman]

Robert Dailey wrote:

Hi,

Currently I have 3 projects named A, B, and C. A and B are both static 
libraries, and C is an executable. B depends on A, and C depends on B 
via add_dependencies(). When I generate a visual studio 9 project from 
this setup, how will the libraries be linked? The way I want this to 
work is for C to link against both A and B, and B will not link against 
A (Since B's dependencies should transfer to C). Is there a way to 
accomplish this behavior? I want to avoid using target_link_libraries 
for the most part because it's redundant. I'm already specifying B as a 
dependency of C through add_dependency(), why should I have to list B's 
static library file as a dependency of C's executable? Can't CMake pull 
this information from the call to add_dependency()?




Sounds like you should be using target_link_libraries instead of 
add_dependency.


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about transitive dependencies

[John Doe]

Hello,

This discussion is based on my knowledge of the Gnu Compiler Collection.

My understanding of the linking process is that B will never link
against A, because static libraries don't link against other static
libraries.  Library B will have unresolved symbols when linking C.
You must therefore add a dependency between C and A.

Therefore:
C links against B and A
B doesn't link against anything
B needs the header information for the functions of A.

I never use shared libraries, but I think the dynamic linker may need
to resolve a dynamic B against a dynamic A.

Juan

On Thu, Dec 4, 2008 at 3:25 PM, Robert Dailey <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Currently I have 3 projects named A, B, and C. A and B are both static
> libraries, and C is an executable. B depends on A, and C depends on B via
> add_dependencies(). When I generate a visual studio 9 project from this
> setup, how will the libraries be linked? The way I want this to work is for
> C to link against both A and B, and B will not link against A (Since B's
> dependencies should transfer to C). Is there a way to accomplish this
> behavior? I want to avoid using target_link_libraries for the most part
> because it's redundant. I'm already specifying B as a dependency of C
> through add_dependency(), why should I have to list B's static library file
> as a dependency of C's executable? Can't CMake pull this information from
> the call to add_dependency()?
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about transitive dependencies

[Alexander Neundorf]

On Thursday 04 December 2008, Robert Dailey wrote:
> Hi,
>
> Currently I have 3 projects named A, B, and C. A and B are both static
> libraries, and C is an executable. B depends on A, and C depends on B via
> add_dependencies(). When I generate a visual studio 9 project from this
> setup, how will the libraries be linked? The way I want this to work is for
> C to link against both A and B, and B will not link against A (Since B's
> dependencies should transfer to C). Is there a way to accomplish this
> behavior? I want to avoid using target_link_libraries for the most part
> because it's redundant. I'm already specifying B as a dependency of C
> through add_dependency(), why should I have to list B's static library file
> as a dependency of C's executable? Can't CMake pull this information from
> the call to add_dependency()?

target_link_libraries(B A)
...
target_link_libraries(C B)

should do it.
Doesn't it ?

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Question about transitive dependencies

[Robert Dailey]

Hi,

Currently I have 3 projects named A, B, and C. A and B are both static
libraries, and C is an executable. B depends on A, and C depends on B via
add_dependencies(). When I generate a visual studio 9 project from this
setup, how will the libraries be linked? The way I want this to work is for
C to link against both A and B, and B will not link against A (Since B's
dependencies should transfer to C). Is there a way to accomplish this
behavior? I want to avoid using target_link_libraries for the most part
because it's redundant. I'm already specifying B as a dependency of C
through add_dependency(), why should I have to list B's static library file
as a dependency of C's executable? Can't CMake pull this information from
the call to add_dependency()?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] general question on documenting modules using the new FooConfig.cmake files

[Alexander Neundorf]

Hi,

I've got a general question.
Regular cmake FindFoo.cmake modules are documented by putting the docs at the 
top of the file.
This documentation should list the variables, macros etc. provided by that 
module.

Now if I switch to using FooConfig.cmake files and just very simple 
FindFoo.cmake files (basically only for getting some nicer messages etc.), 
how do I do this then ?
I still could put the documentation in the FindFoo.cmake file, but this 
documentation would be for stuff which is in the FooConfig.cmake file, which 
is loaded later.
While this is no technical problem, there is the real problem that the 
contents of the FooConfig.cmake file can change, i.e. a new variable can be 
added. But this doesn't necessarily mean that also the FindFoo.cmake changes. 
But if it doesn't, then the documentation is out of date.

So, what would you prefer where to put the documentation ?
In the FooConfig.cmake file, which is relatively hidden ?
Or in the FindFoo.cmake file, which can get out of sync to the contents of the 
FooConfig.cmake file ?

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to make ctest not buffer its output?

[Alexander Neundorf]

On Thursday 04 December 2008, Hugo Heden wrote:
> Good day all,
>
> I use ctest --build-and-test to do some stuff that takes a long time.
> It seems that ctest buffers the output of its subcommands so that
> nothing is written (to the "terminal") until at the end. This is a
> little unconvenient -- as a human I feel more comfortable actually
> seeing that "something is happening".
>
> Is there a way I can force ctest to not buffer the output of
> subcommands, but rather just flush it?

Does ctest -VV do what you want ?
It switches to "extra verbose" mode.

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [Fwd: Re: Why does dependency scanning in version 2.6 seem so slow?]

[Alexander Neundorf]

On Thursday 04 December 2008, Jose Luis Blanco wrote:
> If this helps anyone, I'm working on a large project using CMake and in two
> different computers, both with the same version of Ubuntu and cmake, it is
> *REALLY SLOW* in only one of them while scanning dependencies, but it's not
> in the other laptop.  (The "slow" dep. scanning is ~1 min. too)
>
> I'd be happy to help debugging this, because it's really annoying :-(

Running it in valgrind/callgrind to get some profiling information may help. 
Do a "make VERBOSE=1" and write down the command which does the dependency 
scanning (cmake -E cmake_depends or something)
Then run this exact command with valgrind:
$ valgrind --tool=callgrind cmake -E cmake_depends ...the remaining argsuments

Using kcachegrind you can analyze the resulting log file very nicely.
Do this on both the fast and the slow machine and see if there are significant 
differences.

I think it won't show you if you hit I/O delay, e.g. caused by a network as 
Bill suspects.

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Getting a list of the defined CMake cache variables along with properties and documentation?

[Alexander Neundorf]

On Thursday 04 December 2008, Bartlett, Roscoe A wrote:
> Hello,
>
> Is there a way in a CMakeLists.txt file to get a list of all of the defined
> CMake cache variables, get their properties, and their documentation?  I
> would like to have this so that I can build more general documentation for
> our CMake project.  I could of course just parse the CMakeCache.txt file
> myself but if there is a way to do this in CMake then that might be better.
>  Otherwise, I will need to create a tool that would do a configure, then
> read the CMakeCache.txt file and build documentation output like you would
> see for our current autotools build system.

If you want documentation for your custom cmake modules, this is possible.
You can run cmake with the --help-custom-modules argument and it will generate 
the documentation for your custom cmake modules. You just have to tell cmake 
where they are:
$ cmake -DCMAKE_MODULE_PATH=/opt/kdelibs/share/apps/cmake/modules\
  --help-custom-modules 

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Why does dependency scanning in version 2.6 seem so slow?

[Alexander Neundorf]

On Wednesday 03 December 2008, Senanu Pearson wrote:
> Hi folks,
>
> Is there a way to speed up the dependency scan in version 2.6?
>
> I recently installed a new Linux OS (Mandriva 2009) which included an
> upgrade to cmake 2.6 (I _think_ I had version 2.4 before). However, when

If I remember correctly, I think in some 2.2.x version the dependency scanning 
got slower, but since then has been optimized again (may have been related to 
the makefile generator version 2 or 3).
So maybe if you updated from 2.0 there would be a slowdown, from 2.4 there 
shouldn't be.

Patches to speed it up would of course be welcome :-)
But I'm afraid that won't be very easy.
Maybe it could be multithreaded to scan multiple files at once ?

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] source_group() and solution directories

[Robert Dailey]

Hi,

Is it possible to have source_group() place files into a "solution
directory"? This would be a folder directly under the solution instead of
inside of a project.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] list( LENGTH ) problem

[Eric NOULARD]

Le Wed, 3 Dec 2008 10:09:56 -0600,
"Robert Dailey" <[EMAIL PROTECTED]> a écrit :

> On Tue, Dec 2, 2008 at 3:00 PM, Alexander Neundorf
> <[EMAIL PROTECTED]>wrote:
> 
> > It expects a variable which holds a list:
> >
> > set(myList foo bar)
> > list( LENGTH myList listlen )
> > message( ${listlen} )
> >
> > (didn't test or check docs, but I think that should be it)
> 
> 
> Why did you do:
> 
> list( LENGTH myList listlen )
> 
> instead of:
> 
> list( LENGTH ${myList} listlen ) 
> 
> This seems pretty inconsistent with how I pass variables into
> functions in other places, like message() for example.

Nope it is consistent.
"list" command is working on the "object" list whereas
message is generally interested in the "value" of your "object".

There is the same idea/issue/feature with "if" command which can
work either on content (i.e. value) or on the variable itself (object).

if(variable STRLESS string)
if(string STRLESS string)

I do attach a file for playing with value and object try
to execute it with cmake -P  playing_with_value_and_object.cmake.

You may eventually find it interesting.


-- 
Erk

# classic VAR
SET(VALUE "Value")
SET(NAME  "Name")
# use value for VAR name
SET(Toto.${VALUE} "another value")
SET(Toto.${NAME}  "nice name")

# use those in message
MESSAGE(VALUE=${VALUE})
MESSAGE(NAME=${NAME})
MESSAGE(Toto.${VALUE}=${Toto.${VALUE}})
MESSAGE(Toto.${NAME}=${Toto.${NAME}})

# Now with list
SET(MyList1 a b c)
SET(MyList2 a d)

IF(UNIX) 
  SET(C MyList1)
ELSE(UNIX)
  SET(C MyList2)
ENDIF(UNIX)

LIST(LENGTH ${C} len)
MESSAGE(len = ${len})
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] How to make ctest not buffer its output?

[Hugo Heden]

Good day all,

I use ctest --build-and-test to do some stuff that takes a long time.
It seems that ctest buffers the output of its subcommands so that
nothing is written (to the "terminal") until at the end. This is a
little unconvenient -- as a human I feel more comfortable actually
seeing that "something is happening".

Is there a way I can force ctest to not buffer the output of
subcommands, but rather just flush it?

Best regards

Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invoke a target on a separate project in a generic way?

[Hugo Heden]

2008/12/4 Bill Hoffman <[EMAIL PROTECTED]>:
> Hugo Heden wrote:
>>
>> Good day all,
>>
>> I am looking for a way within a CMakeLists.txt make sure that:
>>
>> -- at *build* time
>>
>> -- cmake is invoked on a *separate* project, and then also the
>> "all"-target is invoked
>>
>> How do I do that?
>>
>> The following is a first rough sketch (that is not good enough, I
>> believe):
>>
>> ADD_CUSTOM_TARGET(
>>  build_separate_project
>>  WORKING_DIRECTORY separate_project/build
>>  COMMAND ${CMAKE_COMMAND} ../src
>>  COMMAND ${CMAKE_BUILD_TOOL} all
>> )
>>
>> -- The above only works for a ${CMAKE_BUILD_TOOL} that happens to
>> accept a commandline that contains a target and nothing else (like
>> GNU-make does).
>>
>> So is there a more *generic* way to, at build time, invoke cmake and
>> then the "all"-target on a separate project?
>>
>> (The following is a bit of background: We have a project called "FOO"
>> that generates source code that eventually also needs to be compiled.
>> The generated source files end up in a *directory* that is known
>> CMake-time, but the *filenames* are not known until *build*-time. Thus
>> there is no way with in project "FOO" to create a target to compile
>> the generated source-code. (Doing FILE(GLOB...) within project FOO
>> will not work, because the globbing will take place at cmake-time, at
>> which time there are no files there). Therefore, together with the
>> generated source files we generate a CMakeLists.txt that defines a
>> *separate* project called "BAR" that contains a target to compile the
>> generated source code. Hence the question above -- how do I invoke the
>> all target in the BAR project in a way that works for all build-tools,
>> not only GNU-make?)
>>
>
> You should look at ctest --build-and-test.  It can do what you want, and
> invoke all build systems supported by CMake.  It is used in the testing of
> CMake.  See CMake/Tests/CMakeLists.txt, and ctest --help for information.
>

Aha, yes, that's it! Thank you!

/Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How does ctest impose CVS checkout time?

[Bill Hoffman]

Bartlett, Roscoe A wrote:

Hello,
 
Does anyone know how CTest is able to set the CVS checkout time (with 
the -D option I would guess) when I am the one that provides the CVS 
checkout command in my Ctest script file by setting CTEST_CVS_CHECKOUT 
or CTEST_CVS_COMMAND?  Is the CVS checkout followed by some sort of 'cvs 
update -D ' command to set the date or something?  This information 
is not being eched with 'ctest -S xxx -VV'.  In my opinon, the verbose 
option should show *all* the major commands that are being made to the 
system so that I can debug problems when they occur.
 

It comes from CTestConfig.cmake for the project.

set(CTEST_NIGHTLY_START_TIME "21:00:00 EDT")


Can Ctest be modified to or a new super-verbose option be added to show 
me all of the major commands that it runs?


ctest --debug -VV


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Can't get include() to work!

[Robert Dailey]

On Thu, Dec 4, 2008 at 6:53 AM, Bill Hoffman <[EMAIL PROTECTED]>wrote:

> Robert Dailey wrote:
>
>
>> The problem isn't about MAC line endings not working. I could care less
>> about line ending requirements, I'll go with whatever works. The main
>> problem I have is that CMake didn't TELL me what the problem was. It should
>> have said, "Hey dummy, your line endings are unacceptable. Please change
>> them to LINUX line endings". That would have saved me hours of time!
>>
>
> Sure, it is just that you are the very first person to run  into this in
> the last 8 years.  I am curious how you created the file. I will try to come
> up with a way to detect mac files and issue an error.


I used Notepad++ to edit my file. I didn't change line endings manually, so
MAC must be set as the default for some reason. Notepad++ has some great
syntax highlighting for CMake scripts.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Pre-chekout configure vs. post-checkout configure

[Bartlett, Roscoe A]

Hello,

One of my nightly tests just failed last night because it tried to do a 
configure using outdated CMake files after I had enabled new options that 
caused it to fail.  I need to understand how to make the nightly testing 
scripts more robust.  Perhaps using extended Ctest scripting is the way to go?

- Ross






___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] How does ctest impose CVS checkout time?

[Bartlett, Roscoe A]

Hello,

Does anyone know how CTest is able to set the CVS checkout time (with the -D 
option I would guess) when I am the one that provides the CVS checkout command 
in my Ctest script file by setting CTEST_CVS_CHECKOUT or CTEST_CVS_COMMAND?  Is 
the CVS checkout followed by some sort of 'cvs update -D ' command to set 
the date or something?  This information is not being eched with 'ctest -S xxx 
-VV'.  In my opinon, the verbose option should show *all* the major commands 
that are being made to the system so that I can debug problems when they occur.

Can Ctest be modified to or a new super-verbose option be added to show me all 
of the major commands that it runs?

Thanks,

- Ross


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] absolute include paths to resource compiler

[Jesper Eskilson]

>> Due to some weirdness in Visual Studio, I need to be able to give the
>> resource compiler an absolute path:
>> 
>>   rc ... -I${CMAKE_SOURCE_DIR}/include
>> 
>> If I put
>> 
>>   include_directories(${CMAKE_SOURCE_DIR}/include)
>> 
>> CMake converts the absolute path to a relative one.
>> 
>> 
>What is the weirdness?   It should work without a full path?

Building works, but the resource view in Visual Studio can for some
reason not locate the resource file (in
${CMAKE_SOURCE_DIR}/include). It seems as if Visual Studio does not
always expand relative paths the same way. The result is that we can't
edit our resource files in Visual Studio, since Visual Studio can't
find them.

-- 
/Jesper

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invoke a target on a separate project in a generic way?

[Bill Hoffman]

Hugo Heden wrote:

Good day all,

I am looking for a way within a CMakeLists.txt make sure that:

-- at *build* time

-- cmake is invoked on a *separate* project, and then also the
"all"-target is invoked

How do I do that?

The following is a first rough sketch (that is not good enough, I believe):

ADD_CUSTOM_TARGET(
  build_separate_project
  WORKING_DIRECTORY separate_project/build
  COMMAND ${CMAKE_COMMAND} ../src
  COMMAND ${CMAKE_BUILD_TOOL} all
)

-- The above only works for a ${CMAKE_BUILD_TOOL} that happens to
accept a commandline that contains a target and nothing else (like
GNU-make does).

So is there a more *generic* way to, at build time, invoke cmake and
then the "all"-target on a separate project?

(The following is a bit of background: We have a project called "FOO"
that generates source code that eventually also needs to be compiled.
The generated source files end up in a *directory* that is known
CMake-time, but the *filenames* are not known until *build*-time. Thus
there is no way with in project "FOO" to create a target to compile
the generated source-code. (Doing FILE(GLOB...) within project FOO
will not work, because the globbing will take place at cmake-time, at
which time there are no files there). Therefore, together with the
generated source files we generate a CMakeLists.txt that defines a
*separate* project called "BAR" that contains a target to compile the
generated source code. Hence the question above -- how do I invoke the
all target in the BAR project in a way that works for all build-tools,
not only GNU-make?)



You should look at ctest --build-and-test.  It can do what you want, and 
invoke all build systems supported by CMake.  It is used in the testing 
of CMake.  See CMake/Tests/CMakeLists.txt, and ctest --help for information.



-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] absolute include paths to resource compiler

[Bill Hoffman]

[EMAIL PROTECTED] wrote:

Due to some weirdness in Visual Studio, I need to be able to give the
resource compiler an absolute path:

  rc ... -I${CMAKE_SOURCE_DIR}/include

If I put

  include_directories(${CMAKE_SOURCE_DIR}/include)

CMake converts the absolute path to a relative one.



What is the weirdness?   It should work without a full path?

-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to find fortran library

[Bill Hoffman]

Javier Gonzalez wrote:

Maik Beckmann wrote:

Am Mittwoch, 3. Dezember 2008 schrieb Javier Gonzalez:
  

Hi all,

I have a project that links to another project built with Fortran. My
own project is a C++ project and I usually need to link against a
fortran library of some sort to use the first one. I use gcc, so it
usually is libgfortran or libg2c.

Now my question is: if I enable Fortran, will there be a variable that
tells me the location of the library I need to link to?

No.  The compiler frontend (gfortran, g77, ...) makes the decision which 
system and compiler libraries have to be linked in.  

If you or cmake link an fortran executable with 
  g77 -o myapp a.o b.o ..

libg2c will be linked in by g77.  When doing
  g77 -o myapp a.o b.o ..
libgfortran will be linked in by gfortran.

The same is true for g++, which links in libstdc++ by default.

  

What I do at the moment is that I guess which library I need to link to
based on the Fortran compiler's name and, since I use gcc, try to find
it in the path given by 'gcc -print-search-dirs'. Is this the right way?
I would expect that cmake defines a variable with this information
somewhere.

This is the right way.  Maybe an effort to write cmake module which handles 
this task is worthy.


Best,
 -- Maik


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

  

I see.

Later I saw Bill's message about the new release. One of the changes in
2.6.3 RC5 is:
- Add FortranCInterface.cmake module to discover Fortran/C interfaces

I wonder if that is precisely what I was looking for so I will check it out.

No not really.  That module figures out the name mangling scheme of the 
fortran compiler.   It does not figure out the run time libraries.


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Getting a list of the defined CMake cache variables along with properties and documentation?

[Bill Hoffman]

Philip Lowman wrote:

1. A chicken and the egg problem, a configure has to occur and 
CMakeCache.txt created first before you can even parse it for 
documentation.  Depending on the system being configured generation of a 
CMakeCache.txt can take some time due to all of the time needed to do 
compilation checks, etc.  It's not as if the user is going to be able to 
run "cmake --configure-help ." and have it immediately spit out 
documentation like GNU AutoTools prior to the user even configuring the 
build.  There would have to be an initial delay as the cache is 
created.  Obviously there is the apriori option here though (distribute 
configuration help ahead of time or require the user to configure 
manually first).


2. The generated documentation (as Bill alluded to) would be dependent 
on which branches were taken during the configure




Every time we talk about this, I think the only way to solve it is to 
have all the options in some central place.   Basically add some sort of 
argv/argc handler code into CMake.   It would be up to the project 
maintainer to put the publishable options into that file.   Any sort of 
code that makes all if statement branches true will just not work, and 
will be a huge hack.


Something like:
ProjectOptions.cmake
add_option(enable-testing "Enable the testing part of the project" 
ENABLE_TESTING)

add_option(build-with-mpi "Use MPI with this project" BUILD_WITH_MPI)

The option would have a command line option, the documentation, and the 
cache variable.   A documentation feature could search the project 
source tree for PRojectOptions.cmake files and quickly find them all.


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Can't get include() to work!

[Bill Hoffman]

Robert Dailey wrote:



The problem isn't about MAC line endings not working. I could care less 
about line ending requirements, I'll go with whatever works. The main 
problem I have is that CMake didn't TELL me what the problem was. It 
should have said, "Hey dummy, your line endings are unacceptable. Please 
change them to LINUX line endings". That would have saved me hours of time!


Sure, it is just that you are the very first person to run  into this in 
the last 8 years.  I am curious how you created the file. I will try to 
come up with a way to detect mac files and issue an error.


-Bill

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Future of debian package generator?

[Mathieu Malaterre]

On Mon, Dec 1, 2008 at 2:38 PM, Johannes Dohmen <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> ok, my question is already in the subject.
>
> After some tests I like the idea of packaging debs with cmake [0] very much,
> but I would like to know how the future plans for this feature are.
>
> I will describe why I'm uncertain of it's future:
> AFAIK Mathieu Malaterre implemented the packaging of debs for cmake (thank
> you very much!) and was criticized by the debian developers for not doing it
> the "right" way.
> Mathieu tried to improve the packaging for getting more accordance by the
> debian developers. All this can be read in the debian-devel mailing list.
> The last mail from Mathieu at this list with reference to cmake was this:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg261679.html
>
> I did not find anything regards the future of the debian packaging on the
> cmake website or the mailing-list so far...
>
> So will there be a deb-packer in cmake 2.8?

I am pretty sure there will be. Kitware (esp. CMake) has a pretty darn
good backward compatibility policy.

> Is there any hope to get the
> blessing of the debian developers for it?

Yeah, that's a whole lot different story, I doubt anyone can answer
here. You'll need to be some kind of DD mentor...

Anyway long story short. The debian binary package generator works for
us. It will do the simple job of packaging binaries generated by cmake
into a so-called "deb" bundle, which will allows you to redistribute
it within your small organization to remote station.
It will *never* replace what is being done by the dpkg-* tools. If you
are planning on releasing any kind of project as a mainstream open
source package to the debian project, then stop right now, and start
using the default debian/* files. You are of course free to call cmake
within the debian/rules file.

Hope this answer your questions,

-- 
Mathieu
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invoke a target on a separate project in a generic way?

[Hugo Heden]

2008/12/4 Hugo Heden <[EMAIL PROTECTED]>:
> Good day all,
>
> I am looking for a way within a CMakeLists.txt make sure that:
>
> -- at *build* time
>
> -- cmake is invoked on a *separate* project, and then also the
> "all"-target is invoked
>
> How do I do that?
>

Before anyone else answers this: I think I should be looking at
try_compile, it seems to do what I am looking for. (I will get back
here and report, for future reference if nothing else.)

http://cmake.org/cmake/help/cmake2.6docs.html#command:try_compile


try_compile: Try compiling some code.

  try_compile(RESULT_VAR bindir srcdir
  projectName  [CMAKE_FLAGS ]
  [OUTPUT_VARIABLE var])

Try compiling a program. In this form, srcdir should contain a
complete CMake project with a CMakeLists.txt file and all sources. The
bindir and srcdir will not be deleted after this command is run. If
 is specified then build just that target otherwise the
all or ALL_BUILD target is built.
...
...






> The following is a first rough sketch (that is not good enough, I believe):
>
> ADD_CUSTOM_TARGET(
>  build_separate_project
>  WORKING_DIRECTORY separate_project/build
>  COMMAND ${CMAKE_COMMAND} ../src
>  COMMAND ${CMAKE_BUILD_TOOL} all
> )
>
> -- The above only works for a ${CMAKE_BUILD_TOOL} that happens to
> accept a commandline that contains a target and nothing else (like
> GNU-make does).
>
> So is there a more *generic* way to, at build time, invoke cmake and
> then the "all"-target on a separate project?
>
> (The following is a bit of background: We have a project called "FOO"
> that generates source code that eventually also needs to be compiled.
> The generated source files end up in a *directory* that is known
> CMake-time, but the *filenames* are not known until *build*-time. Thus
> there is no way with in project "FOO" to create a target to compile
> the generated source-code. (Doing FILE(GLOB...) within project FOO
> will not work, because the globbing will take place at cmake-time, at
> which time there are no files there). Therefore, together with the
> generated source files we generate a CMakeLists.txt that defines a
> *separate* project called "BAR" that contains a target to compile the
> generated source code. Hence the question above -- how do I invoke the
> all target in the BAR project in a way that works for all build-tools,
> not only GNU-make?)
>
> Best Regards
>
> Hugo Heden
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Invoke a target on a separate project in a generic way?

[Hugo Heden]

Good day all,

I am looking for a way within a CMakeLists.txt make sure that:

-- at *build* time

-- cmake is invoked on a *separate* project, and then also the
"all"-target is invoked

How do I do that?

The following is a first rough sketch (that is not good enough, I believe):

ADD_CUSTOM_TARGET(
  build_separate_project
  WORKING_DIRECTORY separate_project/build
  COMMAND ${CMAKE_COMMAND} ../src
  COMMAND ${CMAKE_BUILD_TOOL} all
)

-- The above only works for a ${CMAKE_BUILD_TOOL} that happens to
accept a commandline that contains a target and nothing else (like
GNU-make does).

So is there a more *generic* way to, at build time, invoke cmake and
then the "all"-target on a separate project?

(The following is a bit of background: We have a project called "FOO"
that generates source code that eventually also needs to be compiled.
The generated source files end up in a *directory* that is known
CMake-time, but the *filenames* are not known until *build*-time. Thus
there is no way with in project "FOO" to create a target to compile
the generated source-code. (Doing FILE(GLOB...) within project FOO
will not work, because the globbing will take place at cmake-time, at
which time there are no files there). Therefore, together with the
generated source files we generate a CMakeLists.txt that defines a
*separate* project called "BAR" that contains a target to compile the
generated source code. Hence the question above -- how do I invoke the
all target in the BAR project in a way that works for all build-tools,
not only GNU-make?)

Best Regards

Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] absolute include paths to resource compiler

[jesper]

Due to some weirdness in Visual Studio, I need to be able to give the
resource compiler an absolute path:

  rc ... -I${CMAKE_SOURCE_DIR}/include

If I put

  include_directories(${CMAKE_SOURCE_DIR}/include)

CMake converts the absolute path to a relative one.


-- 
/Jesper

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] absolute include paths to resource compiler

[jesper]

Due to some weirdness in Visual Studio, I need to be able to give the
resource compiler an absolute path:

  rc ... -I${CMAKE_SOURCE_DIR}/include

If I put

  include_directories(${CMAKE_SOURCE_DIR}/include)

CMake converts the CMAKE_SOURCE_DIR absolute path to a relative
one. Why? And how do I get around it. I can't find any flags for
setting resource compiler options.

-- 
/Jesper

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] MSVC100?

[Philip Lowman]

I think this came up on the mailing list recently but I didn't couldn't find
the thread

To prevent the above abomination of a variable name ever being created by
CMake when Microsoft releases version 10 of their wonderful compiler, I
suggest doing away with the whole MSVC60 / MSVC70 / MSVC71 / MSVC80 / MSVC90
thing for future releases and creating a new variable and setting it to the
current major & minor point release version of Microsoft's compiler:

SET(MSVC_DECIMAL_VERSION  9.0)

Yes, I realize that MSVC_VERSION exists, but seriously who wants to do
integer comparison with confusing values like 1310 and 1400 that require a
search engine to fathom to say nothing of the fact that computers seem to
have floating point processors in them these days.

I will happily submit a patch for this (which shouldn't take long to fix)
provided someone with commit rights can tell me what variable name to use.
CMake seems divided on the whole should we use "CMAKE_COMPILER_2005" or
"MSVC80";  "MSVC" vs."CMAKE_COMPILER_IS_GNUCC";  "MINGW" or
"CMAKE_COMPILER_IS_MINGW".  Not to start a flamewar or anything but this is
awefully bizarre and confusing nomenclature.  Is "CMAKE_COMPILER_..." the
path forward or is it obsolete?

Also, CMAKE_COMPILER_2005 seems to be true on VS9/2008 at least with the
NMake generator.  Not sure if this is a documentation bug or a real bug.

-- 
Philip Lowman
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to find fortran library

[Javier Gonzalez]

Maik Beckmann wrote:
> Am Mittwoch, 3. Dezember 2008 schrieb Javier Gonzalez:
>   
>> Hi all,
>>
>> I have a project that links to another project built with Fortran. My
>> own project is a C++ project and I usually need to link against a
>> fortran library of some sort to use the first one. I use gcc, so it
>> usually is libgfortran or libg2c.
>>
>> Now my question is: if I enable Fortran, will there be a variable that
>> tells me the location of the library I need to link to?
>> 
>
> No.  The compiler frontend (gfortran, g77, ...) makes the decision which 
> system and compiler libraries have to be linked in.  
>
> If you or cmake link an fortran executable with 
>   g77 -o myapp a.o b.o ..
> libg2c will be linked in by g77.  When doing
>   g77 -o myapp a.o b.o ..
> libgfortran will be linked in by gfortran.
>
> The same is true for g++, which links in libstdc++ by default.
>
>   
>> What I do at the moment is that I guess which library I need to link to
>> based on the Fortran compiler's name and, since I use gcc, try to find
>> it in the path given by 'gcc -print-search-dirs'. Is this the right way?
>> I would expect that cmake defines a variable with this information
>> somewhere.
>> 
>
> This is the right way.  Maybe an effort to write cmake module which handles 
> this task is worthy.
>
> Best,
>  -- Maik
>
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
>   
I see.

Later I saw Bill's message about the new release. One of the changes in
2.6.3 RC5 is:
- Add FortranCInterface.cmake module to discover Fortran/C interfaces

I wonder if that is precisely what I was looking for so I will check it out.

thanks,
Javier
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake