Re: [CMake] link_libraries vs target_link_libraries

[Hendrik Sattler]

Colin D Bennett schrieb:
 However, I would argue that target_link_libraries vs.
 link_libraries is more important than the possible
 target_include_directories vs. include_directories, since the linked
 libraries will directly affect the generated output (linking to
 unnecessary libraries is wasteful). In contrast, including unused
 include-file-directories in the search path for the compiler will not
 affect the output (assuming there are no duplicated header file names
 in different paths, which I would argue should not be allowed).

Actually, it's possible that those duplicated names exist. The problem
comes up if they have the same API but a different ABI, thus the linking
will possibly fail.
However, doesn't include_directories() only affect the current dir and
the subdirs? It would be a very rare case to have two apps in the same
dir that use two different types/versions of the same include files.

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

[CMake] Pure template libraries

[Cristóvão Sousa]

Hi,

I'm having some trouble about creating the correct CMakeLists.txt files to 
deal with pure template libraries (header files only).

A simple sample:

I have 3 directories with a file in each one:
- Libbase
'- base.hpp 
- Libderiv
 '- deriv.hpp
- Exec
 '- main.cpp

File main.cpp includes file deriv.hpp;
File deriv.hpp includes file base.hpp:
main.cpp -- deriv.hpp -- base.hpp


Right now I have the following cmake files:

root CMakeLists.txt :
add_subdirectory(Libbase)
add_subdirectory(Libderiv)
add_subdirectory(Exec)

Libbase/CMakeLists.txt :
#empty

Libderiv/CMakeLists.txt :
#empty

Exec/CMakeLists.txt :
set(exec_SRCS main.cpp)
add_executable(exec ${exec_SRCS})
include_directories(${PROJECT_SOURCE_DIR}/base)
include_directories(${PROJECT_SOURCE_DIR}/deriv)


This works fine, but is a little bit annoying having to place  
include_directories(${PROJECT_SOURCE_DIR}/base)
in the Exec/CMakeLists.txt file. (because in the real project
I use a lot of pure template libraries which include a lot of 
other libraries, and often I don't remember them all.)

1- Is it possible to create a pure headers library with add_library?
   I tried passing only the header fine name but it complains about not
   knowing how to compile it.

2- And how can we make a include_directory be transitive, i.e.
   having a library XZY which include_directory( ABC_DIR ),
   automatically do the include_directory( ABC_DIR ) on any
   target_link_libraries( EXECTARG XYZ)?


I hope I'd been clear.


Thanks,
Cristóvão Sousa


















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

Re: [CMake] link_libraries vs target_link_libraries

[Bill Hoffman]

So, I guess I will comment on this...  :)

Originally CMake was directory based.  We are moving towards being 
target based.   For directories, targets, and projects, there should be 
a way to set:


- defines
- includes
- link libraries
- compiler flags


Currently you can set:

compiler flags:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_FLAGS

define symbols:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:DEFINE_SYMBOL

libraries with target_link_libraries.

config based compile defines:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_DEFINITIONS_CONFIG

include_directories can only be set on a per directory basis.  At some 
point a target will have all the links, includes, and flags required to 
use it stored somewhere, and that will come with the target.   This can 
be done now with macros and functions, the new CMake build for boost 
does some of this.   If someone wants to a bug entry could be created 
for target specific include files, that would be good.


As for the title of the thread target_link_libraries should be used in 
most cases.  However link_libraries could still be a useful short cut.


Note, CMake does use the link libraries for a target transitively.  If 
you do not want that, you can use:

http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LINK_INTERFACE_LIBRARIES



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

Re: [CMake] link_libraries vs target_link_libraries

[Fernando Cacciola]

Hi Bill,


Fernando Cacciola wrote:


Ha I see... that is 2.6 specific right?

There are still too many 2.4 versions shiped with Linux et al, and we 
don't want to ask our users to *manually* upgrade cmake when they 
already have one installed, so I'm keeping all compatible with at 
least 2.4.5


Well, not much we can do about that but wait...  :)
\


Indeed :)


We are telling our users to do:

 find_packge( CGAL REQUIRED components )

 include( ${CGAL_USE_FILE} )

 
 add_executable( program ... )

 target_link_libraries
   ( program ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )

But then I wondered: why am I bothering them with that last line while 
everything else is hidden in UseCGAL?  After all if they do not won't 
to link with that, which would be really odd, they better don't use 
UseCGAL at all and rather just use the outcome of FindCGAL manually.


So IMO UseCGAL should be all or nothing. Wouldn't you agree?
For an executable is it not as important since there is no transitive 
linking.  However, link_libraries is a bit of a blunt instrument as it 
will link with all the executables and libraries after it is called into 
sub directories.  So, I still think linking just specific libraries is 
better than not.  Also, it will be one less thing you have to change 
when 2.6 comes out.  What if the project had program1 and program2, and 
program2 used VTK and CGAL, but program1 only used CGAL?  Then the 
link_libraries approach would link too much.  The extra includes should 
not hurt because VTK and CGAL should not have conflicting headers.  So, 
there is a still a benefit to specifically linking libraries.


In our case this scenario is just not possible at all since UseCGAL 
overrides flags, so everything following UseCGAL must actually use CGAL 
in all its glory :)


We tell our users to arrange CMakeLists.txt appropiately taking the 
global side effects of UseCGAL into account.


Best

Fernando


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

[CMake] LIBRARY_OUTPUT_DIRECTORY or CMAKE_LIBRARY_OUTPUT_DIRECTORY

[Michael Jackson]

The below is from the CMake 2.6.2 documentation:
===

• LIBRARY_OUTPUT_PATH: Old library location variable.
This variable should no longer be used as of CMake 2.6. Use the  
ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and  
RUNTIME_OUTPUT_DIRECTORY target properties instead. They will override  
this variable if they are set.


If set, this is the directory where all the libraries built during the  
build process will be placed.


===

When I go looking for documentation on LIBRARY_OUTPUT_DIRECTORY I  
don't seem to find anything but I do find  
CMAKE_LIBRARY_OUTPUT_DIRECTORY. Which one is correct and which one  
should I be using?


I currently use something like:

# -- Setup output Directories -
SET (LIBRARY_OUTPUT_PATH
  ${PROJECT_BINARY_DIR}/lib
  CACHE PATH
  Directory for all Libraries
  )

# - Setup the Executable output Directory -
SET (EXECUTABLE_OUTPUT_PATH
  ${PROJECT_BINARY_DIR}/bin
  CACHE PATH
  Directory for all Executables.
  )

Which evidently is being deprecated in favor of  
LIBRARY_OUTPUT_DIRECTORY or CMAKE_LIBRARY_OUTPUT_DIRECTORY.


Comments?

_

Mike Jackson  [EMAIL PROTECTED]
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer  Dayton, Ohio



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

Re: [CMake] Addressing an external MS project as target

[Floca Ralf Omar]

 Bill Hoffman wrote:
 
  So, this might work:
  include_external_msproject(B /some/path)
  add_dependencies(A B)
 
 I meant to say this:
 
   add_dependencies(A INCLUDE_EXTERNAL_MSPROJECT_B)
 
 
 -Bill


Thank you very much for your help and the quick response. It works
perfectly now.

Kind regards,

Ralf Floca
 
--
Ralf Floca
DKFZ
German Cancer Research Center (Deutsches Krebsforschungszentrum) 
Member of the Helmholtz Association
E071 Research Group
Software Development for Integrated Diagnostics and Therapy (SIDT)

Im Neuenheimer Feld 280
D-69120 Heidelberg

Telefon: +49 (6221) 42 3021
E-Mail: [EMAIL PROTECTED]
Web: www.dkfz.de
--
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Ctest + Post command

[David Cole]

What does the script that you run by cron look like?
Is it a declarative(/old-style) ctest script or a command-based(/new-style)
ctest script?Or something else?

In a command-based ctest script (one that uses CTEST_BUILD(), CTEST_TEST()
and CTEST_SUBMIT(), for example) you could add EXECUTE_PROCESS calls at the
bottom of the script after the submission.

In a declarative style ctest script, you could set CTEST_COMMAND to be a
list of multiple commands, rather than just a ctest -D call, as exemplified
by this VTK build script:
http://www.cdash.org/CDash/viewNotes.php?buildid=212772
(In the example, the dashboard is run by a ctest -D command, and then a
memcheck dashboard is run after that...)


HTH,
David


On Wed, Nov 12, 2008 at 9:31 AM, [EMAIL PROTECTED] wrote:

 Hi list,

 I have got here a script which is invoked by cron job. During that all will
 be checked out and compiled, tested and uploaded to Cdash server.
 What I want to do now is to add a post command to my script so that I can
 run a profiling tool. Additionally I want to use in the post script also the
 svn command in order to tag my currently tested results.

 Is there any possibilty to solve that?

 Thanks for your info.

 Greetings

 Alexander


 
 Please note: This e-mail may contain confidential information
 intended solely for the addressee. If you have received this
 e-mail in error, please do not disclose it to anyone, notify
 the sender promptly, and delete the message from your system.
 Thank you.


 ___
 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] LIBRARY_OUTPUT_DIRECTORY or CMAKE_LIBRARY_OUTPUT_DIRECTORY

[Michael Jackson]

Ahh.. I didn't see the new property documentation options. I use my  
QtAssistant Script to generate easy to read/search documentation and I  
needed to update the script. I'll update the wiki also in case anyone  
else wants to use it.


Thanks for the heads up.

Mike

On Nov 12, 2008, at 9:58 AM, David Cole wrote:


From the cmake 2.6 docs online:

http://www.cmake.org/cmake/help/ 
cmake2.6docs.html#variable:CMAKE_LIBRARY_OUTPUT_DIRECTORY
http://www.cmake.org/cmake/help/ 
cmake2.6docs.html#prop_tgt:LIBRARY_OUTPUT_DIRECTORY


CMAKE_LIBRARY_OUTPUT_DIRECTORY is a global variable.
LIBRARY_OUTPUT_DIRECTORY is a target property that gets its default  
value, if any, from the global variable.




On Wed, Nov 12, 2008 at 9:24 AM, Michael Jackson [EMAIL PROTECTED] 
 wrote:

The below is from the CMake 2.6.2 documentation:
===

   • LIBRARY_OUTPUT_PATH: Old library location variable.
This variable should no longer be used as of CMake 2.6. Use the  
ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and  
RUNTIME_OUTPUT_DIRECTORY target properties instead. They will  
override this variable if they are set.


If set, this is the directory where all the libraries built during  
the build process will be placed.


===

When I go looking for documentation on LIBRARY_OUTPUT_DIRECTORY I  
don't seem to find anything but I do find  
CMAKE_LIBRARY_OUTPUT_DIRECTORY. Which one is correct and which one  
should I be using?


I currently use something like:

# -- Setup output Directories -
SET (LIBRARY_OUTPUT_PATH
 ${PROJECT_BINARY_DIR}/lib
 CACHE PATH
 Directory for all Libraries
 )

# - Setup the Executable output Directory -
SET (EXECUTABLE_OUTPUT_PATH
 ${PROJECT_BINARY_DIR}/bin
 CACHE PATH
 Directory for all Executables.
 )

Which evidently is being deprecated in favor of  
LIBRARY_OUTPUT_DIRECTORY or CMAKE_LIBRARY_OUTPUT_DIRECTORY.


Comments?

_

Mike Jackson  [EMAIL PROTECTED]




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

Re: [CMake] link_libraries vs target_link_libraries

[Hendrik Sattler]

Bill Hoffman schrieb:
 OTOH, it could make sense to do the following:

  find_packge( CGAL REQUIRED components )

  include( ${CGAL_USE_FILE} )

  
  add_executable( program ... )

  use_CGAL( program )

 so it works now with 2.4, and eventually upgrade it to use target
 properties instead.
 
 That sounds like a good way to go, and is similar to what the boost
 folks are doing.

But it is not backwards-compatible and will fail to link on the new
version while it worked fine on the old version.
Additionally, that would make ${CGAL_USE_FILE} obsolete as you can put
the macro into FindCGAL.cmake.

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

Re: [CMake] link_libraries vs target_link_libraries

[Fernando Cacciola]

Hendrik Sattler wrote:

Bill Hoffman schrieb:

OTOH, it could make sense to do the following:

 find_packge( CGAL REQUIRED components )

 include( ${CGAL_USE_FILE} )

 
 add_executable( program ... )

 use_CGAL( program )

so it works now with 2.4, and eventually upgrade it to use target
properties instead.

That sounds like a good way to go, and is similar to what the boost
folks are doing.


But it is not backwards-compatible and will fail to link on the new
version while it worked fine on the old version.


Why??


Additionally, that would make ${CGAL_USE_FILE} obsolete as you can put
the macro into FindCGAL.cmake.


Which is far from being a problem, or is it?

Best

Fernando

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

Re: [CMake] link_libraries vs target_link_libraries

[Hendrik Sattler]

Fernando Cacciola schrieb:
 Hendrik Sattler wrote:
 Bill Hoffman schrieb:
 OTOH, it could make sense to do the following:

  find_packge( CGAL REQUIRED components )

  include( ${CGAL_USE_FILE} )

  
  add_executable( program ... )

  use_CGAL( program )

 so it works now with 2.4, and eventually upgrade it to use target
 properties instead.
 That sounds like a good way to go, and is similar to what the boost
 folks are doing.

 But it is not backwards-compatible and will fail to link on the new
 version while it worked fine on the old version.
 
 Why??

Because if the ${FOO_USE_FILE} doesn't do what it always does (globally
adding this stuff), you _have_ to insert the new macro call to make it
compile again. OTOH, this macro call will fail on the old version
because it doesn't exist.
(Assumed that FindFoo.cmake and ${FOO_USE_FILE} are shipped with cmake)

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

[CMake] Pure template libraries

[Eric Noulard]

2008/11/12 Cristóvão Sousa [EMAIL PROTECTED]:
 On Wednesday 12 November 2008 12:58:08 Eric Noulard [EMAIL PROTECTED]
 wrote:
 2008/11/12 Cristóvão Sousa [EMAIL PROTECTED]:
 
  This works fine, but is a little bit annoying having to place
  include_directories(${PROJECT_SOURCE_DIR}/base)
  in the Exec/CMakeLists.txt file. (because in the real project
  I use a lot of pure template libraries which include a lot of
  other libraries, and often I don't remember them all.)
 


 1) add them explicitely to your exe sources files:

 2) Or may be defining template lib

 This two doesn't help because I also need to know which are the hpp files
 included by the one the executable includes. (This is true for compiled
 libraries too, right?)

Yes, when executable uses classical lib you have to:

TARGET_LINK_LIBRARIES(YOUR_EXE_TARGET YOURLIB1 YOURLIB2) etc...

 3) export them somewhere in your build tree and include_directory  the
 choosen place:

Libbase/CMakeLists.txt :
CONFIGURE_FILE(base.hpp build_include)

this is a mistake one should read:

  CONFIGURE_FILE(base.hpp build_include/base.hpp @COPYONLY)


Libderiv/CMakeLists.txt :
CONFIGURE_FILE(deriv.hpp build_include)

same here:

  CONFIGURE_FILE(deriv.hpp build_include/deriv.hpp @COPYONLY)

Exec/CMakeLists.txt :
include_directories(build_include)
set(exec_SRCS main.cpp)
add_executable(exec ${exec_SRCS})

 This is a little better, however I cannot managed to define build_include

build_include in my example was meant to be a directory name located
in the build tree.
CONFIGURE_FILE(deriv.hpp build_include/deriv.hpp @COPYONLY)
should create the directory if needed, if it is not the case you should
file(MAKE_DIRECTORY build_include) before
CONFIGURE_FILE(...

You may specify it using absolute path:

${CMAKE_BINARY_DIR}/build_include

 correctly. I set(BUILD_INCS_DIR ./build_incs), but no good...

Sorry for the wrong tips


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

Re: [CMake] Ctest + Post command

[Alexander.Camek]

Hi David,

 David Cole wrote:
 
 What does the script that you run by cron look like?
 Is it a declarative(/old-style) ctest script or a 
 command-based(/new-style) ctest script?
 Or something else?

It is an old-styled one. Do I need something special to use the new-style?
 
 In a declarative style ctest script, you could set 
 CTEST_COMMAND to be a list of multiple commands, rather than 
 just a ctest -D call, as exemplified by this VTK build script:
 http://www.cdash.org/CDash/viewNotes.php?buildid=212772
 (In the example, the dashboard is run by a ctest -D command, 
 and then a memcheck dashboard is run after that...)

So when I have something like:
SET(CTEST_COMMAND ctest -D Nightly FOO)
First the ctest will be run (here a nightly build) and after that FOO.

Greetings

Alexander 



Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

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

Re: [CMake] link_libraries vs target_link_libraries

[Fernando Cacciola]

Hi Hendrik,


But it is not backwards-compatible and will fail to link on the new
version while it worked fine on the old version.

Why??


Because if the ${FOO_USE_FILE} doesn't do what it always does (globally
adding this stuff), you _have_ to insert the new macro call to make it
compile again. OTOH, this macro call will fail on the old version
because it doesn't exist.
(Assumed that FindFoo.cmake and ${FOO_USE_FILE} are shipped with cmake)


So you where referring to some existing UseFOO then?

UseCGAL doesn't really exist yet (we haven't released it), so at this 
point I can do the right thing :)


Fernando

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

[CMake] Ctest + Post command

[Alexander.Camek]

Hi list,

I have got here a script which is invoked by cron job. During that all will be 
checked out and compiled, tested and uploaded to Cdash server.
What I want to do now is to add a post command to my script so that I can run a 
profiling tool. Additionally I want to use in the post script also the svn 
command in order to tag my currently tested results. 

Is there any possibilty to solve that?

Thanks for your info.

Greetings

Alexander



Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

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

Re: [CMake] Pure template libraries

[Cristóvão Sousa]

On Wednesday 12 November 2008 16:00:32 Eric Noulard wrote:
 2008/11/12 Cristóvão Sousa [EMAIL PROTECTED]:
 
  This two doesn't help because I also need to know which are the hpp files
  included by the one the executable includes. (This is true for compiled
  libraries too, right?)

 Yes, when executable uses classical lib you have to:

 TARGET_LINK_LIBRARIES(YOUR_EXE_TARGET YOURLIB1 YOURLIB2) etc...

But if in YOURLIB1 I do 
TARGET_LINK_LIBRARIES(YOURLIB1 YOURLIB2)

then in YOUR_EXE_TARGET I only need to do
TARGET_LINK_LIBRARIES(YOUR_EXE_TARGET YOURLIB1)

So, in one hand, I don't need to know that YOURLIB1 needs YOURLIB2.
OTHO, I have to know, because of the include files... Taking headers files 
into account, the sample above will be

For YOURLIB1:
INCLUDE_DIRECTORIES( YOURLIB2_DIR )
TARGET_LINK_LIBRARIES( YOURLIB1 YOURLIB2 )

For YOUR_EXE_TARGET:
# Here I have to include YOURLIB2_DIR
INCLUDE_DIRECTORIES( YOURLIB2_DIR YOURLIB1_DIR )
TARGET_LINK_LIBRARIES( YOUR_EXE_TARGET YOURLIB1 )



What I said is correct, isn't it?




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

Re: [CMake] LIBRARY_OUTPUT_DIRECTORY or CMAKE_LIBRARY_OUTPUT_DIRECTORY

[David Cole]

From the cmake 2.6 docs online:

http://www.cmake.org/cmake/help/cmake2.6docs.html#variable:CMAKE_LIBRARY_OUTPUT_DIRECTORY
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LIBRARY_OUTPUT_DIRECTORY
CMAKE_LIBRARY_OUTPUT_DIRECTORY is a global variable.
LIBRARY_OUTPUT_DIRECTORY is a target property that gets its default value,
if any, from the global variable.



On Wed, Nov 12, 2008 at 9:24 AM, Michael Jackson 
[EMAIL PROTECTED] wrote:

 The below is from the CMake 2.6.2 documentation:
 ===

• LIBRARY_OUTPUT_PATH: Old library location variable.
 This variable should no longer be used as of CMake 2.6. Use the
 ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and
 RUNTIME_OUTPUT_DIRECTORY target properties instead. They will override this
 variable if they are set.

 If set, this is the directory where all the libraries built during the
 build process will be placed.

 ===

 When I go looking for documentation on LIBRARY_OUTPUT_DIRECTORY I don't
 seem to find anything but I do find CMAKE_LIBRARY_OUTPUT_DIRECTORY. Which
 one is correct and which one should I be using?

 I currently use something like:

 # -- Setup output Directories -
 SET (LIBRARY_OUTPUT_PATH
  ${PROJECT_BINARY_DIR}/lib
  CACHE PATH
  Directory for all Libraries
  )

 # - Setup the Executable output Directory -
 SET (EXECUTABLE_OUTPUT_PATH
  ${PROJECT_BINARY_DIR}/bin
  CACHE PATH
  Directory for all Executables.
  )

 Which evidently is being deprecated in favor of LIBRARY_OUTPUT_DIRECTORY or
 CMAKE_LIBRARY_OUTPUT_DIRECTORY.

 Comments?

 _

 Mike Jackson  [EMAIL PROTECTED]
 BlueQuartz Softwarewww.bluequartz.net
 Principal Software Engineer  Dayton, Ohio



 ___
 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] link_libraries vs target_link_libraries

[Fernando Cacciola]

Hi Colin,

On Tue, 11 Nov 2008 16:13:43 -0200
Fernando Cacciola
[EMAIL PROTECTED] wrote:


Hi Andreas,
On 11 Nov 2008 18:12:33 +0100,  Andreas Pakulat wrote:

In fact I don't understand why include_directories and
add_definitions are not deprecated as well

Which is precisely my point!! :)

target_link_libraries, which is GREAT, is actually pretty useless 
without target_include_directories, target_add_definitions and 
TARGET_CMAKE_CXX_FLAGS.


Yet OTOH given that those do not exists, it is just plain silly to 
recommend not using link_libraries, because it gets less than half

the story right.


I agree. There should be a target_include_directories.  This has
bothered me as well.

However, I would argue that target_link_libraries vs.
link_libraries is more important than the possible
target_include_directories vs. include_directories, since the linked
libraries will directly affect the generated output (linking to
unnecessary libraries is wasteful). 


Agreed, though definitions and, most important of all by far, compiler 
and linker flags are much more critical.


And UseVTK, for example, changes compiler flags FOR EVERYTHING THAT 
FOLLOWS, even totally unrelated PARENT directories (because of the ways 
of the cache).
So if target_link_libraries makes sense (and it sure does), imagine 
TARGET_CMAKE_CXX_FLAGS (or even better target_add_compiler|linker_flags)



In contrast, including unused
include-file-directories in the search path for the compiler will not
affect the output (assuming there are no duplicated header file names
in different paths, which I would argue should not be allowed).

Except of course that you can't disallow it in all cases since 
completely different libraries cannot possibly prevent clashing with 
each other, and that would happen if you have find_package(X) then 
find_package(Y).


But granted, if you have those two lines in the same cmake scripts you 
are likely to need both X and Y in the same target, so this is an 
unlikely scenario.



So, I think that target_link_libraries is more important than
target_include_directories, but we still should have a
target_include_directories for the sake of consistency, clarity
(specifically show what include directories are used by what files),
and robustness.

And as I said far much more important: target_add_definitions and a way 
to target compilers and linker flags, which is something Use files also 
define globally now.



Another aspect of this is that perhaps 'target_include_directories' is
not the right concept, but rather, since include files are needed by
source code (not compiled targets), the
following:

  source_include_directories(source-files ... 
 INCLUDES include-dirs ...)


I wonder if this would be useful in practice?

I'm not sure it makes sense to draw a disctinction between stuff needed 
by source files and compiled targets. While in a makefile these all go 
as command line parameters to the compiler source by source, in a 
project files these are global properties of a target within the 
project, so IMO the conceptual entity the encapsulates all these is the 
target, not the source files.


Best

Fernando



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

Re: [CMake] link_libraries vs target_link_libraries

[Hendrik Sattler]

Am Wednesday 12 November 2008 17:03:04 schrieb Fernando Cacciola:
 Hi Hendrik,

  But it is not backwards-compatible and will fail to link on the new
  version while it worked fine on the old version.
 
  Why??
 
  Because if the ${FOO_USE_FILE} doesn't do what it always does (globally
  adding this stuff), you _have_ to insert the new macro call to make it
  compile again. OTOH, this macro call will fail on the old version
  because it doesn't exist.
  (Assumed that FindFoo.cmake and ${FOO_USE_FILE} are shipped with cmake)

 So you where referring to some existing UseFOO then?

 UseCGAL doesn't really exist yet (we haven't released it), so at this
 point I can do the right thing :)

Sure but if this stuff is to be consistent with the other modules doing the 
USE_FILE thing, then this is a problem.

HS

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

Re: [CMake] Ctest + Post command

[David Cole]

On Wed, Nov 12, 2008 at 11:02 AM, [EMAIL PROTECTED] wrote:


 So when I have something like:
 SET(CTEST_COMMAND ctest -D Nightly FOO)
 First the ctest will be run (here a nightly build) and after that FOO.


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

Re: [CMake] link_libraries vs target_link_libraries

[Bill Hoffman]

Fernando Cacciola wrote:


Ha I see... that is 2.6 specific right?

There are still too many 2.4 versions shiped with Linux et al, and we 
don't want to ask our users to *manually* upgrade cmake when they 
already have one installed, so I'm keeping all compatible with at least 
2.4.5


Well, not much we can do about that but wait...  :)
\

We are telling our users to do:

 find_packge( CGAL REQUIRED components )

 include( ${CGAL_USE_FILE} )

 
 add_executable( program ... )

 target_link_libraries
   ( program ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )

But then I wondered: why am I bothering them with that last line while 
everything else is hidden in UseCGAL?  After all if they do not won't to 
link with that, which would be really odd, they better don't use UseCGAL 
at all and rather just use the outcome of FindCGAL manually.


So IMO UseCGAL should be all or nothing. Wouldn't you agree?
For an executable is it not as important since there is no transitive 
linking.  However, link_libraries is a bit of a blunt instrument as it 
will link with all the executables and libraries after it is called into 
sub directories.  So, I still think linking just specific libraries is 
better than not.  Also, it will be one less thing you have to change 
when 2.6 comes out.  What if the project had program1 and program2, and 
program2 used VTK and CGAL, but program1 only used CGAL?  Then the 
link_libraries approach would link too much.  The extra includes should 
not hurt because VTK and CGAL should not have conflicting headers.  So, 
there is a still a benefit to specifically linking libraries.



OTOH, it could make sense to do the following:

 find_packge( CGAL REQUIRED components )

 include( ${CGAL_USE_FILE} )

 
 add_executable( program ... )

 use_CGAL( program )

so it works now with 2.4, and eventually upgrade it to use target 
properties instead.


That sounds like a good way to go, and is similar to what the boost 
folks are doing.



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

Re: [CMake] making Nightly builds easier to setup

[Alexander Neundorf]

On Monday 10 November 2008, Martin Apel wrote:
...
 I recently played around with nightly builds as well. I used to have a
 setup for experimental builds, but never could get the svn checkout to
 run. With the approach described above, I was finally able
 to run checkout from svn from within ctest. Unfortunately it seems that
 some variables are not used anymore with this approach of generating
 builds. I found that CTEST_INITIAL_CACHE 

I plan to do something about this.

 as well as CTEST_ENVIRONMENT seem

This one probably too.

Which other problems do you have in detail ?

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

Re: [CMake] Pure template libraries

[Eric Noulard]

2008/11/12 Cristóvão Sousa [EMAIL PROTECTED]:
 Hi,

 I'm having some trouble about creating the correct CMakeLists.txt files to
 deal with pure template libraries (header files only).

 A simple sample:

 I have 3 directories with a file in each one:
 - Libbase
'- base.hpp
 - Libderiv
 '- deriv.hpp
 - Exec
 '- main.cpp

 File main.cpp includes file deriv.hpp;
 File deriv.hpp includes file base.hpp:
 main.cpp -- deriv.hpp -- base.hpp


 Right now I have the following cmake files:

 root CMakeLists.txt :
add_subdirectory(Libbase)
add_subdirectory(Libderiv)
add_subdirectory(Exec)

 Libbase/CMakeLists.txt :
 #empty

 Libderiv/CMakeLists.txt :
 #empty

 Exec/CMakeLists.txt :
 set(exec_SRCS main.cpp)
 add_executable(exec ${exec_SRCS})
 include_directories(${PROJECT_SOURCE_DIR}/base)
 include_directories(${PROJECT_SOURCE_DIR}/deriv)


 This works fine, but is a little bit annoying having to place
 include_directories(${PROJECT_SOURCE_DIR}/base)
 in the Exec/CMakeLists.txt file. (because in the real project
 I use a lot of pure template libraries which include a lot of
 other libraries, and often I don't remember them all.)

 1- Is it possible to create a pure headers library with add_library?
   I tried passing only the header fine name but it complains about not
   knowing how to compile it.

 2- And how can we make a include_directory be transitive, i.e.
   having a library XZY which include_directory( ABC_DIR ),
   automatically do the include_directory( ABC_DIR ) on any
   target_link_libraries( EXECTARG XYZ)?

If your header are somehow public since they must be included by other part
of the porject you may either:

1) add them explicitely to your exe sources files:

   set(exec_SRCS main.cpp ../ Libbase/base.hpp ../Libderiv/deriv.hpp)

2) Or may be defining template lib like (note the PARENT_SCOPE in SET)
   Libbase/CMakeLists.txt :
   SET(TLIB_BASE ${CMAKE_CURRENT_SOURCE_DIR}/base.hpp PARENT_SCOPE)

   Libderiv/CMakeLists.txt :
   SET(TLIB_DERIV ${CMAKE_CURRENT_SOURCE_DIR}/deriv.hpp PARENT_SCOPE)

   Exec/CMakeLists.txt :
   set(exec_SRCS main.cpp ${TLIB_BASE} ${TLIB_DERIV})
   add_executable(exec ${exec_SRCS})

3) export them somewhere in your build tree and include_directory  the
choosen place:

   Libbase/CMakeLists.txt :
   CONFIGURE_FILE(base.hpp build_include)

   Libderiv/CMakeLists.txt :
   CONFIGURE_FILE(deriv.hpp build_include)

   Exec/CMakeLists.txt :
   include_directories(build_include)
   set(exec_SRCS main.cpp)
   add_executable(exec ${exec_SRCS})


I did not test my proposal, but I think they should work.

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

Re: [CMake] link_libraries vs target_link_libraries

[Alexander Neundorf]

On Wednesday 12 November 2008, Fernando Cacciola wrote:
 Hi Bill,
...
 Ha I see... that is 2.6 specific right?

 There are still too many 2.4 versions shiped with Linux et al, and we
 don't want to ask our users to *manually* upgrade cmake when they
 already have one installed, so I'm keeping all compatible with at least
 2.4.5

KDE 4.2 (will be released early next year) will require cmake 2.6.2 (KDE svn 
trunk does since this monday), so distributions will adapt :-)

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

Re: [CMake] link_libraries vs target_link_libraries

[Fernando Cacciola]

Hi Bill,


So, I guess I will comment on this...  :)


:)

Originally CMake was directory based.  We are moving towards being 
target based.   For directories, targets, and projects, there should be 
a way to set:


- defines
- includes
- link libraries
- compiler flags


Hard to argue with that :)


Currently you can set:

compiler flags:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_FLAGS

define symbols:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:DEFINE_SYMBOL

libraries with target_link_libraries.

config based compile defines:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_DEFINITIONS_CONFIG 


Ha I see... that is 2.6 specific right?

There are still too many 2.4 versions shiped with Linux et al, and we 
don't want to ask our users to *manually* upgrade cmake when they 
already have one installed, so I'm keeping all compatible with at least 
2.4.5




include_directories can only be set on a per directory basis.  At some 
point a target will have all the links, includes, and flags required to 
use it stored somewhere, and that will come with the target.   This can 
be done now with macros and functions, the new CMake build for boost 
does some of this.   If someone wants to a bug entry could be created 
for target specific include files, that would be good.


As for the title of the thread target_link_libraries should be used in 
most cases.  However link_libraries could still be a useful short cut.


The *practical* problem I have with target_link_libraries and which 
originated this thread is the following:


We are telling our users to do:

 find_packge( CGAL REQUIRED components )

 include( ${CGAL_USE_FILE} )

 
 add_executable( program ... )

 target_link_libraries
   ( program ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )

But then I wondered: why am I bothering them with that last line while 
everything else is hidden in UseCGAL?  After all if they do not won't to 
link with that, which would be really odd, they better don't use UseCGAL 
at all and rather just use the outcome of FindCGAL manually.


So IMO UseCGAL should be all or nothing. Wouldn't you agree?


OTOH, it could make sense to do the following:

 find_packge( CGAL REQUIRED components )

 include( ${CGAL_USE_FILE} )

 
 add_executable( program ... )

 use_CGAL( program )


In this case, the use_CGAL macro would set includes, definitions, 
libraries etc, but for the specified target as much as possible 
(depending on the current cmake support).


IIUC I can easily write the use_CGAL macro as:

  include_directories
( ${CGAL_3RD_PARTY_INCLUDE_DIRS}   ${CGAL_INCLUDE_DIRS}  )

  add_definitions
( ${CGAL_3RD_PARTY_DEFINITIONS}${CGAL_DEFINITIONS}   )

  link_directories
( ${CGAL_3RD_PARTY_LIBRARIES_DIRS} ${CGAL_LIBRARIES_DIR} )

  target_link_libraries
 ( ${TARGET} ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )

so it works now with 2.4, and eventually upgrade it to use target 
properties instead.


What do yo think?



Note, CMake does use the link libraries for a target transitively.  If 
you do not want that, you can use:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LINK_INTERFACE_LIBRARIES 


Ha, interesting.. didn't know that.


Fernando

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

[CMake] [PATCH] support for CTEST_INITIAL_CACHE in new-style ctest script

[Alexander Neundorf]

Hi,

the attached patch adds support for the CTEST_INITIAL_CACHE variable when 
using new-style ctest commands.
Now ctest_configure() checks the CTEST_INITIAL_CACHE variable and if it is not 
empty, AND there is no CMakeCache.txt yet, it writes the initial 
CMakeCache.txt
I had a look at the code of the old-style ctest script, it seems there any 
existing CMakeCache.txt is overwritten if CTEST_INITIAL_CACHE is set. Is this 
correct ? Is this behaviour also wanted for the new-style commands ?
I think it is not necessary, because if I want to have a fresh cmake run, I 
can use ctest_empty_binary_directory() before, then I will also get the 
initial cache again.

What do you think ?
Ok to commit ?

Alex
Index: CTest/cmCTestConfigureCommand.cxx
===
RCS file: /cvsroot/CMake/CMake/Source/CTest/cmCTestConfigureCommand.cxx,v
retrieving revision 1.11
diff -b -u -p -r1.11 cmCTestConfigureCommand.cxx
--- CTest/cmCTestConfigureCommand.cxx	11 Jul 2006 19:58:07 -	1.11
+++ CTest/cmCTestConfigureCommand.cxx	13 Nov 2008 00:20:26 -
@@ -3,7 +3,7 @@
   Program:   CMake - Cross-Platform Makefile Generator
   Module:$RCSfile: cmCTestConfigureCommand.cxx,v $
   Language:  C++
-  Date:  $Date: 2006-07-11 19:58:07 $
+  Date:  $Date: 2006/07/11 19:58:07 $
   Version:   $Revision: 1.11 $
 
   Copyright (c) 2002 Kitware, Inc., Insight Consortium.  All rights reserved.
@@ -53,6 +53,14 @@ cmCTestGenericHandler* cmCTestConfigureC
 return 0;
 }
 
+  const char* ctestInitialCache
+= this-Makefile-GetDefinition(CTEST_INITIAL_CACHE);
+  if ( ctestInitialCache  *ctestInitialCache )
+{
+this-CTest-SetCTestConfiguration(InitialCache,
+  ctestInitialCache);
+}
+
   const char* ctestConfigureCommand
 = this-Makefile-GetDefinition(CTEST_CONFIGURE_COMMAND);
   if ( ctestConfigureCommand  *ctestConfigureCommand )
Index: CTest/cmCTestConfigureHandler.cxx
===
RCS file: /cvsroot/CMake/CMake/Source/CTest/cmCTestConfigureHandler.cxx,v
retrieving revision 1.14
diff -b -u -p -r1.14 cmCTestConfigureHandler.cxx
--- CTest/cmCTestConfigureHandler.cxx	30 Jan 2008 16:17:36 -	1.14
+++ CTest/cmCTestConfigureHandler.cxx	13 Nov 2008 00:20:26 -
@@ -3,7 +3,7 @@
   Program:   CMake - Cross-Platform Makefile Generator
   Module:$RCSfile: cmCTestConfigureHandler.cxx,v $
   Language:  C++
-  Date:  $Date: 2008-01-30 16:17:36 $
+  Date:  $Date: 2008/01/30 16:17:36 $
   Version:   $Revision: 1.14 $
 
   Copyright (c) 2002 Kitware, Inc., Insight Consortium.  All rights reserved.
@@ -18,6 +18,7 @@
 #include cmCTestConfigureHandler.h
 
 #include cmCTest.h
+#include cmCTestScriptHandler.h
 #include cmGeneratedFileStream.h
 #include cmake.h
 #include cmsys/Process.h
@@ -79,6 +80,28 @@ int cmCTestConfigureHandler::ProcessHand
 
 cmGeneratedFileStream ofs;
 this-StartLogFile(Configure, ofs);
+
+  // write the initial cache if
+  // * CTEST_INITIAL_CACHE was set and
+  // * CMakeCache.txt doesn't exist yet
+  std::string initialCache
+= this-CTest-GetCTestConfiguration(InitialCache);
+  if (initialCache.size() != 0)
+{
+if (!cmSystemTools::FileExists((buildDirectory+/CMakeCache.txt).c_str()))
+  {
+  cmCTestLog(this-CTest, HANDLER_VERBOSE_OUTPUT, 
+ Creating initial CMakeCache.txt  std::endl);
+  if (!cmCTestScriptHandler::WriteInitialCache(buildDirectory.c_str(), 
+   initialCache.c_str()))
+{
+cmCTestLog(this-CTest, ERROR_MESSAGE,
+   Cannot write initial CMakeCache.txt  std::endl);
+return -1;
+}
+  }
+}
+
 cmCTestLog(this-CTest, HANDLER_VERBOSE_OUTPUT, Configure with command: 
cCommand.c_str()  std::endl);
 res = this-CTest-RunMakeCommand(cCommand.c_str(), output,
Index: CTest/cmCTestScriptHandler.cxx
===
RCS file: /cvsroot/CMake/CMake/Source/CTest/cmCTestScriptHandler.cxx,v
retrieving revision 1.44
diff -b -u -p -r1.44 cmCTestScriptHandler.cxx
--- CTest/cmCTestScriptHandler.cxx	7 Nov 2008 20:56:54 -	1.44
+++ CTest/cmCTestScriptHandler.cxx	13 Nov 2008 00:20:26 -
@@ -117,7 +117,7 @@ void cmCTestScriptHandler::Initialize()
   this-CTestCmd = ;
   this-UpdateCmd = ;
   this-CTestEnv = ;
-  this-InitCache = ;
+  this-InitialCache = ;
   this-CMakeCmd = ;
   this-CMOutFile = ;
   this-ExtraUpdates.clear();
@@ -443,7 +443,7 @@ int cmCTestScriptHandler::ExtractVariabl
 }
   this-CTestEnv
 = this-Makefile-GetSafeDefinition(CTEST_ENVIRONMENT);
-  this-InitCache
+  this-InitialCache
 = this-Makefile-GetSafeDefinition(CTEST_INITIAL_CACHE);
   this-CMakeCmd
 = this-Makefile-GetSafeDefinition(CTEST_CMAKE_COMMAND);
@@ -834,24 +834,14 @@ int cmCTestScriptHandler::RunConfigurati
 }
 
   // put the initial cache into the bin dir
-  if 

Re: [CMake] [PATCH] support for CTEST_INITIAL_CACHE in new-style ctest script

[Bill Hoffman]

Alexander Neundorf wrote:

Hi,

the attached patch adds support for the CTEST_INITIAL_CACHE variable when 
using new-style ctest commands.
Now ctest_configure() checks the CTEST_INITIAL_CACHE variable and if it is not 
empty, AND there is no CMakeCache.txt yet, it writes the initial 
CMakeCache.txt
I had a look at the code of the old-style ctest script, it seems there any 
existing CMakeCache.txt is overwritten if CTEST_INITIAL_CACHE is set. Is this 
correct ? Is this behaviour also wanted for the new-style commands ?
I think it is not necessary, because if I want to have a fresh cmake run, I 
can use ctest_empty_binary_directory() before, then I will also get the 
initial cache again.


What do you think ?
Ok to commit ?



I am not sure I like the idea.  The old style ctest was declarative in 
nature.  The new one is procedural.  I am not sure I like magic global 
variables affecting commands.   A better way to do this would be to add 
an optional argument to ctest_configure that allows an initial cache to 
be passed into the function.


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