Re: [CMake] Building Boost as an ExternalProject

2017-10-03 Thread Knox, Kent
Hi Michael~

> That does seem to be the rub, at least on a Windows build. Something about 
> ExternalProject_Add ain't quite kosher with what the Boost build system 
> expects and it needs a little help.

> Using ExternalProject_Add, it succeeds, to a point. Then it falls over 
> looking for b2 no matter how I try to persuade it:

> ExternalProject_Add (boost
>PREFIX ${CMAKE_CURRENT_BINARY_DIR}/boost
>GIT_REPOSITORY g...@github.com:boostorg/boost.git
>GIT_TAG boost-${BOOST_VERSION}
>GIT_PROGRESS 1
>UPDATE_COMMAND ${BOOST_BOOTSTRAP_CMD}
>CONFIGURE_COMMAND ""
>BUILD_COMMAND ${BOOST_BUILD_CMD} stage
>INSTALL_COMMAND ""
>LOG_DOWNLOAD 1
>LOG_UPDATE 1
>LOG_CONFIGURE 1
>LOG_BUILD 1
>LOG_INSTALL 1
> )

I think you need to add the following to your ExternalProject_Add ()
BUILD_IN_SOURCE  1

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


Re: [CMake] Building with Cmake using Boost problem (Karel Geiregat)

2016-03-18 Thread Knox, Kent
It looks like you built static libraries with b2:
PS D:\software\boost_1_60_0\stage\lib> Get-ChildItem libboost_filesystem*
> -name
> libboost_filesystem-vc140-mt-1_60.lib
> libboost_filesystem-vc140-mt-gd-1_60.lib

But I believe you are telling cmake (or boost preprocessor?) to search for 
dynamic libraries:
> add_definitions (
> -DBOOST_REGEX_DYN_LINK
> -DBOOST_FILESYSTEM_DYN_LINK
> -DBOOST_SYSTEM_DYN_LINK

Try building dynamic (.dll w/ import libs) boost libraries and see if cmake 
finds them.

Kent

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


Re: [CMake] ExternalProject_Add with flexible install commands

2016-02-25 Thread Knox, Kent
I don't need to use indirection, but the reason I decided to try was to 
simplify my code.  I could either wrap the ExternalProject_Add() call in a 
branch/switch or a single set() call.  

I am using your 'hack' thusly:
set( libxxx_inst_comm INSTALL_COMMAND ${CMAKE_COMMAND} -E echo_append )

and it's working great for me.  I have no problem documenting what i'm doing in 
my code.

Thank you for your input!

K

From: David Cole <dlrd...@aol.com>
Sent: Thursday, February 25, 2016 10:57 AM
To: Knox, Kent
Cc: Petr Kmoch; cmake@cmake.org
Subject: Re: [CMake] ExternalProject_Add with flexible install commands

Do you need to do it indirectly through a variable like this?

If you just use:
  INSTALL_COMMAND ""

directly in the ExternalProject_Add call, it will work.

If you really need to do it indirectly, there's probably a way, but it
will also probably be more confusing for people reading the code in
the future. Not sure it's worth that trade-off. You could always
"cheat" and execute a no-op command for the install step rather than
"skipping" it. i.e. INSTALL_COMMAND ${CMAKE_COMMAND} -E echo
NoInstallStep ...


HTH,
David C.




On Thu, Feb 25, 2016 at 11:03 AM, Knox, Kent <kent.k...@amd.com> wrote:
> Hi Petr~
>
> Thanks for your reply.
>
>
> These set statements do not appear to work.  Either the command 'installs'
> the dependency, or an error pops up.
>
>
> set( rocblas_INSTALL_COMMAND INSTALL_COMMAND "" )
> --> this installs the dependency
>
> set( rocblas_INSTALL_COMMAND INSTALL_COMMAND " " )
> --> /bin/sh: 1:  : not found
>
> set( rocblas_INSTALL_COMMAND INSTALL_COMMAND """" )
> --> CMake Warning (dev) in CMakeLists.txt
> --> Argument not separated from preceding token by whitespace.
>
> Kent
>
> 
> From: Petr Kmoch <petr.km...@gmail.com>
> Sent: Thursday, February 25, 2016 2:46 AM
> To: Knox, Kent
> Cc: cmake@cmake.org
> Subject: Re: [CMake] ExternalProject_Add with flexible install commands
>
> Hi Kent,
>
> I believe it's not "empty quotes" that disables the install command, it's
> the empty string. So you should not escape the quotes:
>
> ###
>
> # Default behavior is to NOT install library, empty quotes should disable
> install
> set( libxxx_inst_comm INSTALL_COMMAND "" )
>
> # Build the library as an external project
>   ExternalProject_Add( libxxx
> SOURCE_DIR ${PROJECT_SOURCE_DIR}/src
> ${libxxx_inst_comm}
>   )
> ###
>
> Petr
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


Re: [CMake] ExternalProject_Add with flexible install commands

2016-02-25 Thread Knox, Kent
Hi Petr~

Thanks for your reply.


These set statements do not appear to work.  Either the command 'installs' the 
dependency, or an error pops up.


set( rocblas_INSTALL_COMMAND INSTALL_COMMAND "" )
--> this installs the dependency

set( rocblas_INSTALL_COMMAND INSTALL_COMMAND " " )
--> /bin/sh: 1:  : not found

set( rocblas_INSTALL_COMMAND INSTALL_COMMAND """" )
--> CMake Warning (dev) in CMakeLists.txt
--> Argument not separated from preceding token by whitespace.

Kent


From: Petr Kmoch <petr.km...@gmail.com>
Sent: Thursday, February 25, 2016 2:46 AM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Re: [CMake] ExternalProject_Add with flexible install commands

Hi Kent,

I believe it's not "empty quotes" that disables the install command, it's the 
empty string. So you should not escape the quotes:


###

# Default behavior is to NOT install library, empty quotes should disable 
install
set( libxxx_inst_comm INSTALL_COMMAND "" )

# Build the library as an external project
  ExternalProject_Add( libxxx
SOURCE_DIR ${PROJECT_SOURCE_DIR}/src
${libxxx_inst_comm}
  )
###

Petr

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] ExternalProject_Add with flexible install commands

2016-02-25 Thread Knox, Kent
I am having a problem passing parameters as a variable into 
ExternalProject_Add(). I seem to be fighting syntax, i've tried many different 
variants with the set() statement


###

# Default behavior is to NOT install library, empty quotes should disable 
install
set( libxxx_inst_comm INSTALL_COMMAND "\"\"" )

# Build the library as an external project
  ExternalProject_Add( libxxx
SOURCE_DIR ${PROJECT_SOURCE_DIR}/src
${libxxx_inst_comm}
  )
###

I get this message, which appears to be within ExternalProject_add() using 
add_custom_command.  Is there a way around this?


CMake Error at 
/opt/homebrew-cask/Caskroom/cmake/3.2.2/CMake.app/Contents/share/cmake-3.2/Modules/ExternalProject.cmake:1487
 (add_custom_command):

  COMMAND may not contain literal quotes:


""

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] SuperProject package/install

2015-11-12 Thread Knox, Kent
[rm] Right now, the Main ExternalProject_add INSTALL_COMMAND is "".  How can I 
change this (or add another step) to build the package target (I don't want to 
just hard-code make package, as it should work with MSVC too).  I've tried 
things like '${CMAKE_COMMAND} cmake--build package' but haven't had any luck.

[kk]  'package' is a target of your generated build environment.  You can 
specify to 'cmake --build' a target of your choosing.  Look at the '--build' 
docs here:
https://cmake.org/cmake/help/v3.3/manual/cmake.1.html

BUILD_COMMAND ${CMAKE_COMMAND} --build  --target package

[rm] Once I get package running, how can I get the system to copy the resulting 
*.zip file out to the top level directory? 

[kk]  Add a custom step to your external project, which depends on the 
build/install step to finish to copy whatever you want

ExternalProject_Add_Step( myEPname copyPackage
  COMMAND ${CMAKE_COMMAND} -E copy_directory ${myLibDir} 
${packageDir}/${LIB_DIR}
  COMMAND ${CMAKE_COMMAND} -E copy_directory /include 
${packageDir}/include
  DEPENDEES build
)

--

Message: 1
Date: Wed, 11 Nov 2015 11:04:13 -0800
From: Rob McDonald 
To: CMake ML 
Subject: [CMake] SuperProject package/install
Message-ID:

Content-Type: text/plain; charset=UTF-8

All,

I have a SuperProject set up with ExternalProject_add the way some
other projects do.

The SuperProject has two EP's -- Libraries and Main.  Libraries has a
bunch of its own EP's.  Main is my core project.

When some users use this setup, they're confused at the end --
everything has worked, but the project hasn't been installed, and the
results of compilation are buried several directories deep.

My Main project has a 'package' target set up by CPack.  I'd like the
SuperProject to conclude by executing that build target, and then
copying the resulting file to the top-level build directory from the
SuperProject.  To complicate things, the target file name is not
fixed, it uses the version number -- which is not known to the
SuperProject level.

Right now, the Main ExternalProject_add INSTALL_COMMAND is "".  How
can I change this (or add another step) to build the package target (I
don't want to just hard-code make package, as it should work with MSVC
too).  I've tried things like '${CMAKE_COMMAND} cmake--build package'
but haven't had any luck.

Once I get package running, how can I get the system to copy the
resulting *.zip file out to the top level directory?  I'd like it to
end up in the CMake build directory at the top of the SuperProject,
but I haven't figured out how to make that happen yet.

Thanks,

Rob
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


Re: [CMake] Modern superbuild template including support for

2015-08-21 Thread Knox, Kent
I think I have a different perspective.  I don't want Boost or gmock to be 
considered a part of clsparse in any visible way (I don't want them in my IDE); 
I want them truly separate and external.  I like cmake to download and build 
dependencies for me in an automated fashion, but I don't want the requirement 
to either check in the source of the dependency, or to set up my git repository 
to use submodules.  I shouldn't rebuild dependencies when I rebuild my project. 
 Superbuilds have been working quite nicely for me in these ways.  

-Original Message-
From: Andrey Pokrovskiy [mailto:wonder.m...@gmail.com] 
Sent: Thursday, August 20, 2015 7:31 PM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Re: [CMake] Modern superbuild template including support for

 After the first build of the superbuild, close the superbuild solution as 
 it's job is done.
 ...
 Open the solution file for the clsparse library, which was generated 
 as part of the superbuild and is the 'meat' of the project.

Heh, that's exactly what I meant - superbuilds don't work with IDE (meaning 
that CMake doesn't adds anything valuable in terms of integration of several 
CMake based packages here).
You are still working with each sub-project (solution) individually as it was 
an independent project.
For that reason I try to use add_subdirectory() for CMake-based 3rd-party 
dependencies (some make it incredibly hard though).
Maybe I didn't worked with CMake that much, but I consider superbuilds a 
hackish solution. I know there is no a better one, though :)



-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


Re: [CMake] Modern superbuild template including support for

2015-08-20 Thread Knox, Kent
And are you able to browse the source code of all your dependencies
(that were downloaded)?
When you open the generated solution file to the superbuild, targets are made 
for all dependencies (in my case: boost, gmock, clsparse).  From the superbuild 
view, you can not browse the source of the dependencies (the source is not even 
present until you build the first time).  You build the solution, cmake merrily 
downloads the code for the dependencies (aside from clsparse that lives in the 
same repository) and builds the dependencies according the build instructions 
in the cmake/External*.cmake files.  After the first build of the superbuild, 
close the superbuild solution as it's job is done.

Open the solution file for the clsparse library, which was generated as part of 
the superbuild and is the 'meat' of the project. This solution file contains 
browse-able source code to all the files in the clsparse project.  The Boost 
and gmock files are not directly browse-able (i.e. files listed in the 
solution/project), because do not want to rebuild dependencies if rebuilding 
the clsparse project (the dependencies change very seldom).  However, visual 
studio's intellisense does start indexing boost and gmock because they are 
included in clsparse like any other header file or library, so they become 
'browseable' through the IDE.  I believe the same behavior happens with xcode.  


From: Andrey Pokrovskiy [wonder.m...@gmail.com]
Sent: Thursday, August 20, 2015 5:35 PM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Re: [CMake] Modern superbuild template including support for

Hm, I don't understand how that possibly could work (maybe there some
explicit support for that in the project generator for MSVS).
And are you able to browse the source code of all your dependencies
(that were downloaded)?
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


Re: [CMake] Modern superbuild template including support for

2015-08-20 Thread Knox, Kent
I can vouch that the superbuild project works fine both for visual studio and 
for xcode.  Using visual studio as an example, you generate a visual studio 
solution which downloads and compiles all dependencies, inclulding the library. 
 After the initial build, you just use the solution file generated for the 
library thereafter.  I've not tested QT Creater, but I'll see if I can verify 
your difficulties next week.

From: Andrey Pokrovskiy [wonder.m...@gmail.com]
Sent: Thursday, August 20, 2015 2:29 PM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Re: [CMake] Modern superbuild template including support for

Such approach doesn't work with IDE. For example, when I open main
CMakeLists.txt in Qt Creator I only see two *.cmake files. Superbuilds
use ExternalProject_Add() which kills a lot CMake benefits when used
for CMake project from CMake project.

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


Re: [CMake] Modern superbuild template including support for

2015-08-20 Thread Knox, Kent
 I'm looking for a template or example project that shows the how to
 setup a cmake-based project in the cleanest and simplest way (i.e.
 using all the latest features of 3.3 release) and with support for the
 following build features:

I waited a few days to see if anybody else would volunteer their project, 
but I'm happy to ask for critique of the superbuild approach I set up
recently.  This is for an opencl sparse matrix library:
https://github.com/clMathLibraries/clSPARSE
Build instructions:
https://github.com/clMathLibraries/clSPARSE/wiki/Build

I think I only require features up to 2.8.12.  
I have 2 dependencies that I configure/build with the superbuild: 
boost  googlemock.  The main clsparse library is also set up as an 
external dependency, so that it could be used independently.

The root CMakeLists.txt file defines the superbuild, the cmake/External*.cmake
files house the ExternalProject_Add() commands, and the library/CMakeLists.txt 
defines the library build.

Would welcome comments/critiques from anybody with time.

Kent
--
Message: 6
Date: Mon, 17 Aug 2015 10:43:46 -0400
From: Taylor Braun-Jones tay...@braun-jones.org
To: cmake cmake@cmake.org
Subject: [CMake] Modern superbuild template including support for
module  dependencies
Message-ID:
cakfkjysaaxnhrgpxa7uxn7ncykwpir3xhhl51hngkwzz9yu...@mail.gmail.com
Content-Type: text/plain; charset=UTF-8

Hi all,

I'm looking for a template or example project that shows the how to
setup a cmake-based project in the cleanest and simplest way (i.e.
using all the latest features of 3.3 release) and with support for the
following build features:

- Superbuild mode that can be turned on or off (on by default)

- Simple system for defining modules (libraries that get built either
as static or dynamic libraries) and their dependencies.

- install target that works with good default behaviors so that the
CMakeLists.txt for modules and applications need minimal extra
configuration. Should work in both superbuild mode (the project and
all external projects get installed to the same
CMAKE_INSTALL_PREFIX/DESTDIR when invoked at the top superbuild level)
and in non-superbuild mode

I've seen many examples of projects like this but my impression is
that they have been around since long before the latest CMake releases
and therefore weren't designed to take advantage of all the latest
CMake features. My current attempt to setup a cmake-based build with
these features is based on the MITK cmake build system[1] since it's
something I was already familiar with. I have something that mostly
works, but the number of lines of cmake code to make it all happen
with simple interfaces like mitk_create_module, mitk_create_executable
seems more than should be necessary which is going to make switching
to CMake harder for me to sell to my team.

I found this very simplistic CMake project example[2] but the
resulting CMakeLists.txt to build an executable in that project looks
like this:

find_package (Threads REQUIRED)

set (Boost_USE_STATIC_LIBS ON)
# set (Boost_NO_SYSTEM_PATHS ON)
find_package (Boost 1.55.0 REQUIRED COMPONENTS date_time filesystem system)

include_directories (${Boost_INCLUDE_DIRS})

add_executable (blah
  main.cpp)

target_link_libraries (blah
  ${Boost_LIBRARIES}
  ${CMAKE_THREAD_LIBS_INIT})


Whereas I'm looking for something that would allow me to write
something like this:

xxx_add_executable(blah
  PACKAGE_DEPENDS Boost
  DEPENDS mymodule
  main.cpp)

(or some other similarly simple interface)

Thanks in advance,
Taylor

[1] https://github.com/MITK/MITK
[2] https://github.com/Sarcasm/cmake-superbuild
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


Re: [CMake] CMake Digest, Vol 134, Issue 1

2015-06-02 Thread Knox, Kent
Hi Daniel~

 Suppose you have libA that optionally uses zip functionality (say by some 
option USE_ZLIB in libA's CMakeLists.txt). This means libA will optionally have 
-lz in its INTERFACE_LINK_LIBRARIES (exported into liba-config.cmake).

I think the best way to handle this is to turn 'transitive library linking' 
off.  It seems to me that the use of zip functionality is an implementation 
detail of libA, that no clients should be aware of.  I do this in my projects 
with a special form of the target_link_libraries( ) command:
`target_link_libraries( libA PRIVATE ${ZLIB_LIBRARIES} )`

I believe PRIVATE, PUBLIC, INTERFACE keywards were added in cmake 2.8.12

Kent
--

Message: 4
Date: Mon, 01 Jun 2015 11:03:53 +0200
From: Daniel Wirtz daniel.wi...@simtech.uni-stuttgart.de
To: cmake@cmake.org
Subject: [CMake] Conditional transitive link libraries
Message-ID: 556c1ff9.6040...@simtech.uni-stuttgart.de
Content-Type: text/plain; charset=utf-8; format=flowed

Hello all,

I'm struggling with the CMake Config-based package description when using two 
depending packages where the upstream package has optional link libraries.

Suppose you have libA that optionally uses zip functionality (say by some 
option USE_ZLIB in libA's CMakeLists.txt). This means libA will optionally have 
-lz in its INTERFACE_LINK_LIBRARIES (exported into liba-config.cmake).
Now, if you have a libB using libA via find_package(libA), how do you know if 
libA has been built with or without zlib support when both libraries are 
installed and exported with CMake's package config system?

I know that the link library information is treated transitively and will be 
propagated to the link libraries of libB, hence -lz will appear whenever 
linking against libB. However, the PATH to libz is nowhere included; 
consequently, the link fails with could not find library z 
unless you magically knew that libz is a dependent link library of libA and 
where to include it from. Including the absolute path to libz in libA's config 
is also not the way to go, as it ruins the portability over different systems.

Is there a native CMake way?

Thanks!

--
Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a
+49 711 685 60044



-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


[CMake] Resolving CMP0026 warnings

2015-02-05 Thread Knox, Kent
Hi all~

I have a question similar to one recently asked by NoRulez about CMP0026.  I've 
been working on updating my legacy cmake code to compile without warnings with 
the 3.x series.

When I install my projects, I want to copy my 'non-system' target dependencies 
to help debug on non-development machines.  A while back, I stumbled on the 
get_prerequisites( ) cmake function, which helps me enumerate target 
dependencies.  http://www.cmake.org/cmake/help/v3.1/module/GetPrerequisites.html

My code is based on the solution posted by a Timothy M. Shead here:
http://www.cmake.org/pipermail/cmake/2009-June/029975.html

The problem is that get_prerequisites( ) needs a path to the target.  How do I 
now get this path without calling the LOCATION property?  I don't know where I 
can use a generator expression.

=
CMakeLists.txt

get_target_property( libraryLocation myHumbleLibrary LOCATION )

configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/copyLibraryDependencies.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/copyLibraryDependencies.cmake
@ONLY
)

# Register script at run at install time to analyze the executable and copy 
dependencies into package
install( SCRIPT ${CMAKE_CURRENT_BINARY_DIR}/copyLibraryDependencies.cmake )

=
copyLibraryDependencies.cmake.in
=
# The Microsoft IDE presents a challenge because the full configuration is not 
known at cmake time
# This logic allows us to 'substitute' the proper configuration at install time
if( ${CMAKE_INSTALL_CONFIG_NAME} MATCHES Debug )
string( REPLACE \$(Configuration) Debug fixedLibraryLocation 
@libraryLocation@ )
endif( )

...

# This retrieves a list of shared library dependencies from the target; they 
are not full path names
# Skip system dependencies and skip recursion
get_prerequisites( ${fixedLibraryLocation} libraryDependencies 1 0   )

# Loop on queried library dependencies and copy them into package
foreach( dep ${libraryDependencies} )
...
endforeach( )

Thanks for any help,
Kent
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] ExternalProject_Add with gtest and vs2012

2012-07-10 Thread Knox, Kent
Hi all~

I would like to add gtest to my project with ExternalProject_Add(), and I'm 
using the vs2012 RC compiler to compile everything.  I'm getting compile errors 
related to gtest using tuples:

4H:\perforce\bin\vs11x64.SuperBuild\external\gtest\src\gTest\include\gtest/gtest-printers.h(550):
 error C2977: 'std::tuple' : too many template arguments
4
4  2  C:\Program Files (x86)\Microsoft Visual Studio 
11.0\VC\include\utility(73) : see declaration of 'std::tuple'
4
4H:\perforce\bin\vs11x64.SuperBuild\external\gtest\src\gTest\include\gtest/gtest-printers.h(558):
 error C2977: 'std::tuple' : too many template arguments
4
4  2  C:\Program Files (x86)\Microsoft Visual Studio 
11.0\VC\include\utility(73) : see declaration of 'std::tuple'

This is a known problem with gtest and visual studio 2012, as noted here:
http://stackoverflow.com/questions/8274588/c2977-stdtuple-too-many-template-arguments-msvc11
http://code.google.com/p/googletest/issues/detail?id=412

I would like to define the _VARIADIC_MAX=10 preprocessor definition for the 
gtest cmake project, such that when my ExternalProject_Add() compiles gtest, 
this preprocessor symbol is defined and gtest compiles correctly.  I manually 
tested that the preprocessor definition works.  So how to pass the preprocessor 
definition though ExternalProject_Add()?  Any ideas?

I would like to avoid having to use the PATCH_COMMAND to patch the gtest cmake 
files.

Thanks for your ideas,
Kent
--

Powered by www.kitware.com

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

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

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

[CMake] ExternalProject_Add and Boost

2012-06-18 Thread Knox, Kent
Hi all~

I have been experimenting in my project with using ExternalProject_Add.  My 
goal is to make our build process more automated, with less headache to get up 
and started developing on a fresh system.  I decided that boost would be a 
great dependency to automate, which I successfully completed and is a HUGE 
help. I would like also like to ask the community to code review what I did, 
and possibly offer feedback.  I also have my own comments with the experience.

My code for review (this was developed only for windows, for now):

include( ExternalProject )

set( Boost_Version 1.49.0 )
string( REPLACE . _ Boost_Version_Underscore ${Boost_Version} )

message( STATUS Boost_Version:  ${Boost_Version} )

# Below is a CMake command to download, build and install Boost on the user's 
computer
ExternalProject_Add(
Boost
PREFIX ${CMAKE_CURRENT_BINARY_DIR}/external/boost
URL 
http://downloads.sourceforge.net/project/boost/boost/${Boost_Version}/boost_${Boost_Version_Underscore}.zip
URL_MD5 854dcbbff31b896c85c38247060b7713
UPDATE_COMMAND bootstrap.bat
CONFIGURE_COMMAND 
BUILD_COMMAND bjam --with-program_options address-model=64 
toolset=msvc-11.0 link=static stage
BUILD_IN_SOURCE 1
INSTALL_COMMAND 
)

set_property( TARGET Boost PROPERTY FOLDER Externals)

ExternalProject_Get_Property( Boost source_dir )
ExternalProject_Get_Property( Boost binary_dir )
set( Boost_INCLUDE_DIRS ${source_dir} )
set( Boost_LIBRARIES 
debug;${binary_dir}/stage/lib/libboost_program_options-vc110-mt-gd-1_49.lib;optimized;${binary_dir}/stage/lib/libboost_program_options-vc110-mt-1_49.lib
 )

A few of my comments while developing this.   Boost's native build system is 
called Jam.  However, there are efforts to port Boost to cmake, available 
either on github or gitorious.  I would rather stick with one build system and 
use cmake, but I could not use either of these repositories with 
ExternalProject_Add.

1.   Github appears to only use the https protocol, and the cmake file( 
download ... ) command does not appear to handle this protocol.  So, I think 
GitHub is verboten for any ExternalProject_Add.  Am I right, or am I missing 
something?  Any plans to add https support?

2.   ExternalProject_Add checks the file extension of the URL download, to 
'verify' the download is a supported package.  I would actually like to request 
that it not verify the file extension.  A lot of these public code repositories 
offer tarball and zipball downloads, but the links they provide are forwarding 
scripts (and they don't offer you direct links), and oftentimes the URL to use 
has no extension.  I had this problem with both github and gitorious.  I think 
it has to be left to the user to verify that the link they use if valid.

3.   The official subversion repository of boost offers .7z packages to 
download.  These packages are about half the size of .zips.  Will cmake add 
decompression support for 7z archives in the near future?

4.   ExternalProject_Add will download, configure and build projects at 
'build' time.  From the documentation, this sounded like a design decision.  
However, this means that you can't use the already robust and mature 
findboost() module to configure the Boost project.  Would it be possible to add 
support to ExternalProject_Add to work at 'configure' time?  Maybe a flag to 
choose when to pay the build cost?  This would help me abstract the differences 
between linux and windows, for instance.  I understand that some people care 
that 'configure' is fast, but I would prefer not to rewrite the logic already 
in the findboost packge.  Also, if ExternalProject_Add worked at 'configure' 
time, then I would think that it would be possible for the findboost package 
maintainer to incorporate ExternalProject_Add into the find module itself.  
Then, users could pass a possible flag into findBoost that says, 'if you don't 
find boost locally on the system, just download the lastest version of boost 
for me and proceed with configuring.'

Thanks in advance for comments,
Kent
--

Powered by www.kitware.com

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

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

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

Re: [CMake] ExternalProject_Add and Boost

2012-06-18 Thread Knox, Kent
That is an interesting approach; if this 'superbuild' cmake project downloaded 
and built all the external dependencies first, then my project could find those 
dependencies with the appropriate find module?  I suppose that the 'superbuild' 
could set the BOOST_ROOT variable (or other appropriate variables) for my real 
project.  I'll play around with this idea when I get some time, thanks for the 
comment!

-Original Message-
From: Ben Medina [mailto:ben.med...@gmail.com] 
Sent: Monday, June 18, 2012 11:59 AM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Re: [CMake] ExternalProject_Add and Boost

 4.   ExternalProject_Add will download, configure and build projects at
 'build' time.  From the documentation, this sounded like a design decision.
 However, this means that you can't use the already robust and mature
 findboost() module to configure the Boost project.  Would it be 
 possible to add support to ExternalProject_Add to work at 'configure' time?

The approach that seems most common is to create a superbuilder
project that builds your dependencies as external projects, then builds your 
own project (also as an external project) at the end.



--

Powered by www.kitware.com

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

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

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


Re: [CMake] ExternalProject_Add and Boost

2012-06-18 Thread Knox, Kent
I'll check out the reference to b2, thanks for the heads up.



My own project is hosted with SVN, not GIT, so I did not want to require my 
developers to find and install a git client to get the build to work; that is 
why I wanted to choose the zipball.





--

Message: 3

Date: Mon, 18 Jun 2012 10:55:50 +0200

From: Mathias Gaunard 
mathias.gaun...@ens-lyon.orgmailto:mathias.gaun...@ens-lyon.org

Subject: Re: [CMake] ExternalProject_Add and Boost

To: cmake@cmake.orgmailto:cmake@cmake.org

Message-ID: 
4fdeed16.4020...@ens-lyon.orgmailto:4fdeed16.4020...@ens-lyon.org

Content-Type: text/plain; charset=windows-1252; format=flowed



On 18/06/2012 08:42, Knox, Kent wrote:



 BUILD_COMMAND bjam --with-program_options address-model=64

 toolset=msvc-11.0 link=static stage



Two comments here:

  - bjam has been renamed to b2 since Boost 1.47

  - this probably uses the bjam/b2 in the path, rather than the one that you 
just built with bootstrap.bat, which is just asking for problems





 1.Github appears to only use the https protocol, and the cmake file(

 download ? ) command does not appear to handle this protocol. So, I

 think GitHub is verboten for any ExternalProject_Add. Am I right, or am

 I missing something? Any plans to add https support?



Github also provides the git protocol, or did you just mean the zip

download function?





--

Powered by www.kitware.com

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

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

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

[CMake] RPATH/RUNPATH

2011-08-17 Thread Knox, Kent
Is there any support or planned support in CMake for RUNPATH?  On a related 
note, is it possible for CMake to set the RPATH/RUNPATH using $ORIGIN on 'make 
install'?  This way the install directory can be self-referential and moved as 
a unit around the filesystem?

Kent

___
Powered by www.kitware.com

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

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

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


Re: [CMake] RPATH/RUNPATH

2011-08-17 Thread Knox, Kent
Yes, I have read this link (before my list inquiry) and it does not answer my 
questions.  At least, I could not derive anything from it relating to RUNPATH 
or $ORIGIN support.  Thanks for the answer though.

-Original Message-
From: David Cole [mailto:david.c...@kitware.com] 
Sent: Wednesday, August 17, 2011 11:37 AM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Re: [CMake] RPATH/RUNPATH

Perhaps try googling cmake rpath ... ?

  http://www.cmake.org/Wiki/CMake_RPATH_handling


On Wed, Aug 17, 2011 at 12:03 PM, Knox, Kent kent.k...@amd.com wrote:
 Is there any support or planned support in CMake for RUNPATH?  On a related 
 note, is it possible for CMake to set the RPATH/RUNPATH using $ORIGIN on 
 'make install'?  This way the install directory can be self-referential and 
 moved as a unit around the filesystem?

 Kent

 ___
 Powered by www.kitware.com

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

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

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



___
Powered by www.kitware.com

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

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

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


Re: [CMake] RPATH/RUNPATH

2011-08-17 Thread Knox, Kent
Any comments on CMake support or planned support for RUNPATH?

-Original Message-
From: David Cole [mailto:david.c...@kitware.com] 
Sent: Wednesday, August 17, 2011 1:57 PM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Re: [CMake] RPATH/RUNPATH

You can use CMake's RPATH related properties to put a path containing $ORIGIN 
into the final installed executable, and it will work as long as the underlying 
OS library loader supports ORIGIN. From what I understand, ORIGIN support is 
not uniformly available in all loaders...

Does that answer your question?


On Wed, Aug 17, 2011 at 2:19 PM, Knox, Kent kent.k...@amd.com wrote:
 Yes, I have read this link (before my list inquiry) and it does not answer my 
 questions.  At least, I could not derive anything from it relating to RUNPATH 
 or $ORIGIN support.  Thanks for the answer though.

 -Original Message-
 From: David Cole [mailto:david.c...@kitware.com]
 Sent: Wednesday, August 17, 2011 11:37 AM
 To: Knox, Kent
 Cc: cmake@cmake.org
 Subject: Re: [CMake] RPATH/RUNPATH

 Perhaps try googling cmake rpath ... ?

  http://www.cmake.org/Wiki/CMake_RPATH_handling


 On Wed, Aug 17, 2011 at 12:03 PM, Knox, Kent kent.k...@amd.com wrote:
 Is there any support or planned support in CMake for RUNPATH?  On a related 
 note, is it possible for CMake to set the RPATH/RUNPATH using $ORIGIN on 
 'make install'?  This way the install directory can be self-referential and 
 moved as a unit around the filesystem?

 Kent


___
Powered by www.kitware.com

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

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

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


Re: [CMake] Linking Boost on Linux on 64bit host and 32bit

2010-11-04 Thread Knox, Kent
Hi Andreas~

[Andreas]
Did you try to print out the value of Boost_LIBRARIES? Does that contain the 
proper absolute path to the boost library? Are you actually using that variable 
for your target_link_libraries call? The make-output looks like either the 
variable doesn't get the right value which shouldn't happen as its set using 
find_library or you're not using the variable but instead simply pass 
program_options to the target_link_libraries call. Oh and whats the value of 
Boost_program_options_LIBRARY?

[Kent]
To answer your questions, one at a time:

[Andreas] Did you try to print out the value of Boost_LIBRARIES?
-- Boost_LIBRARIES: /usr/lib/libboost_program_options-mt.a

[Kent] That looks wrong right there, I would expect it to be pointing to the 
value of my BOOST_ROOT and BOOST_LIBRARYDIR.

[Andreas] Are you actually using that variable for your target_link_libraries 
call?
IF( WIN32 )
target_link_libraries( clAmd.Client clAmd.Runtime ${Boost_LIBRARIES} 
OpenCL.lib )
ELSEIF( UNIX )
message( STATUS Boost_LIBRARIES: ${Boost_LIBRARIES} )
message( STATUS Boost_program_options_LIBRARY: 
${Boost_program_options_LIBRARY} )
target_link_libraries( clAmd.Client clAmd.Runtime ${Boost_LIBRARIES} 
OpenCL.so )
ENDIF()

[Andreas] Oh and whats the value of Boost_program_options_LIBRARY?
-- Boost_program_options_LIBRARY:

[Kent] Nothing was set



___
Powered by www.kitware.com

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

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

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


Re: [CMake] Linking Boost on Linux on 64bit host and 32bit target

2010-11-04 Thread Knox, Kent
Hi Adam~

[Adam]
Are you sure this logic is right? It looks very odd. Does CMake set WIN32 for a 
64-bit Windows toolchain? Didn't you say you were building on Linux?

[Kent]
My software compiles cross platform, and we support windows too.  WIN32 is set 
for 64bit platforms.  I do have the windows build compiling properly with 
boost.  I'm specifically having problems with linux.

[Adam]
You don't set ADDITIONAL_VERSIONS. That's probably not the problem.
IIRC, it's:
set(Boost_ADDITIONAL_VERSIONS 1.44 1.44.0)

[Kent]
I did not originally set Boost_ADDITIONAL_VERSIONS.  I did set it now, and ran 
a clean recompile, but no change.  My Boost_LIBRARIES still came out as:
-- Boost_LIBRARIES: /usr/lib/libboost_program_options-mt.a

Even though I've specified BOOST_LIBRARYDIR as:
BOOST_LIBRARYDIR = /home/kknox/sdk/boost_1_44_0/stage/lib

Kent

-Original Message-
From: Adam J Richardson [mailto:fat...@crackmonkey.us] 
Sent: Thursday, November 04, 2010 4:56 AM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Linking Boost on Linux on 64bit host and 32bit target

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 04 Nov 2010 04:35:57 -0400
cmake-requ...@cmake.org wrote:
 Hi all~

Hi Kent.

 I have a project using Boost that should compile for both 64bit and 
 32bit on a 64bit host.  This works fine for a 64bit target, but I 
 can't get this to work for a 32bit target.

I'm having problems linking Boost too. But enough about me.

 In order to compile for 32bit on a 64bit host, I have a -D parameter 
 called BUILD64.  Here is my logic to initialize this var:
 
 if( WIN32 )
   set( BUILD64 ${CMAKE_CL_64} )
 else()
   option( BUILD64 Build a 64-bit product OFF )
   if( BUILD64 )
   message( STATUS 64-bit build )
   endif( )
 endif()

Are you sure this logic is right? It looks very odd. Does CMake set
WIN32 for a 64-bit Windows toolchain? Didn't you say you were building on Linux?

 The syntax for finding boost is thus:
 set( Boost_USE_MULTITHREADED ON )
 set( Boost_USE_STATIC_LIBS   ON )
 set( Boost_DETAILED_FAILURE_MSG   ON )
 # set( Boost_DEBUG ON )
 find_package( Boost 1.33.0 COMPONENTS program_options )

You don't set ADDITIONAL_VERSIONS. That's probably not the problem.
IIRC, it's:

set(Boost_ADDITIONAL_VERSIONS 1.44 1.44.0)

... if you wanted to try it anyway.

Regards,
Adam J Richardson
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkzSgx0ACgkQSUH6dLOqvqmfKwCg6qttDVOXnpqHYoZwfjzUyHax
ubMAniQAF6EYxsIUYkqXPQiMwFxop6uB
=ngaQ
-END PGP SIGNATURE-

___
Powered by www.kitware.com

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

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

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


Re: [CMake] Linking Boost on Linux on 64bit host and 32bit

2010-11-04 Thread Knox, Kent
[Michael]
# set( Boost_DEBUG ON )
Uncomment that and send the output. Yes, it will be A LOT of output but I am 
trying to figure out what is going wrong.

[Kent] I took out the explicit setting of BOOST_LIBRARYDIR:

kk...@ux2 ~/code/clAMD/trunk/bin/linux32
561  InitCmake.sh
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- UNICODE feature disabled on linux
-- 64-bit build
-- [ FindBoost.cmake:373 ] Boost not in cache
-- [ FindBoost.cmake:376 ] _boost_TEST_VERSIONS = 
1.44;1.44.0;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
-- [ FindBoost.cmake:378 ] Boost_USE_MULTITHREADED = ON
-- [ FindBoost.cmake:380 ] Boost_USE_STATIC_LIBS = ON
-- [ FindBoost.cmake:439 ] Declared as CMake or Environmental Variables:
-- [ FindBoost.cmake:441 ]   BOOST_ROOT = /home/kknox/sdk/boost_1_44_0
-- [ FindBoost.cmake:443 ]   BOOST_INCLUDEDIR =
-- [ FindBoost.cmake:445 ]   BOOST_LIBRARYDIR =
-- [ FindBoost.cmake:447 ] _boost_TEST_VERSIONS = 
1.44;1.44.0;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
-- [FindBoost.cmake:496 ] Include debugging info:
-- [FindBoost.cmake:498 ]   _boost_INCLUDE_SEARCH_DIRS = 
/home/kknox/sdk/boost_1_44_0/include;/home/kknox/sdk/boost_1_44_0;C:/boost/include;C:/boost;/boost/include;/boost;/sw/local/include
-- [ FindBoost.cmake:500 ]   _boost_PATH_SUFFIXES = 
boost-1_44;boost-1_44_0;boost-1_41_0;boost-1_41;boost-1_40_0;boost-1_40;boost-1_39_0;boost-1_39;boost-1_38_0;boost-1_38;boost-1_37_0;boost-1_37;boost-1_36_1;boost-1_36_0;boost-1_36;boost-1_35_1;boost-1_35_0;boost-1_35;boost-1_34_1;boost-1_34_0;boost-1_34;boost-1_33_1;boost-1_33_0;boost-1_33
-- [FindBoost.cmake:524 ] location of version.hpp: 
/home/kknox/sdk/boost_1_44_0/boost/version.hpp
-- [FindBoost.cmake:543 ] version.hpp reveals boost 1.44.0
-- [FindBoost.cmake:634 ] guessed _boost_COMPILER = -gcc44
-- [FindBoost.cmake:644 ] _boost_MULTITHREADED = -mt
-- [FindBoost.cmake:661 ] _boost_STATIC_TAG =
-- [FindBoost.cmake:663 ] _boost_ABI_TAG = d
-- [FindBoost.cmake:696 ] _boost_LIBRARIES_SEARCH_DIRS = 
/home/kknox/sdk/boost_1_44_0/lib;/home/kknox/sdk/boost_1_44_0/stage/lib;/home/kknox/sdk/boost_1_44_0/lib;/home/kknox/sdk/boost_1_44_0/../lib;C:/boost/lib;C:/boost;/boost

/boost_1_44_0/lib;/boost/boost_1_44/lib;/boost/lib;/boost;/sw/local/lib
-- [ FindBoost.cmake:830 ] Boost_FOUND = TRUE
-- Boost version: 1.44.0
-- Found the following Boost libraries:
--   program_options
-- Boost_PROGRAM_OPTIONS_LIBRARY: /usr/lib/libboost_program_options-mt.a
-- Found FFTW: /usr/lib/libfftw3f.so
-- Found GTest: /usr/lib/libgtest.so
-- Detected GNU fortran compiler.
-- CMAKE_CXX_COMPILER flags: -m64
-- CMAKE_CXX_COMPILER debug flags: -g
-- CMAKE_CXX_COMPILER release flags: -O3 -DNDEBUG
-- CMAKE_CXX_COMPILER relwithdebinfo flags: -O2 -g
-- CMAKE_EXE_LINKER link flags:
-- Boost_LIBRARIES: /usr/lib/libboost_program_options-mt.a
-- Boost_PROGRAM_OPTIONS_LIBRARY: /usr/lib/libboost_program_options-mt.a
-- Configuring done
-- Generating done
-- Build files have been written to: /home/kknox/code/clAMD/trunk /bin/linux32

I've shortened the FindBoost.cmake path to make it more readable: originally 
[/home/kknox/bin/cmake-2.8.2-Linux-i386/share/cmake-2.8/Modules/FindBoost.cmake]

Kent



___
Powered by www.kitware.com

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

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

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


Re: [CMake] Linking Boost on Linux on 64bit host and 32bit target

2010-11-03 Thread Knox, Kent
/clTest/trunk/clFFT/bin/linux32/library:
/usr/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../libboost_program_options-mt.a when 
searching for -lboost_program_options-mt
/usr/bin/ld: skipping incompatible /usr/lib/libboost_program_options-mt.a when 
searching for -lboost_program_options-mt
/usr/bin/ld: cannot find -lboost_program_options-mt

Notice, that the link step does NOT use the paths that I specified, but instead 
uses '-Wl,-Bstatic -lboost_program_options-mt', which is using the boost that 
is installed in /usr/lib.  This is a problem because it is the wrong bitness.

Sorry for the big mess of output text, hope it is readable.  Does anybody know 
what to do?

Kent

-Original Message-
From: Knox, Kent 
Sent: Friday, October 29, 2010 4:40 PM
To: 'cmake@cmake.org'
Subject: Linking Boost on Linux on 64bit host and 32bit target

Hi all~

I have a project using Boost that should compile for both 64bit and 32bit on a 
64bit host.  This works fine for a 64bit target, but I can't get this to work 
for a 32bit target.  I've done a fair share of googling to find this answer, 
but have not stumbled across anything that helps.  In fact, the only flag that 
I can find to distinguish between 32bit build and 64bit builds only applies to 
windows with ${CMAKE_CL_64}.

In order to compile for 32bit on a 64bit host, I have a -D parameter called 
BUILD64.  Here is my logic to initialize this var:

if( WIN32 )
set( BUILD64 ${CMAKE_CL_64} )
else()
option( BUILD64 Build a 64-bit product OFF )
if( BUILD64 )
message( STATUS 64-bit build )
endif( )
endif()

The syntax for finding boost is thus:
set( Boost_USE_MULTITHREADED ON )
set( Boost_USE_STATIC_LIBS   ON )
set( Boost_DETAILED_FAILURE_MSG   ON )
# set( Boost_DEBUG ON )
find_package( Boost 1.33.0 COMPONENTS program_options )

The boost find package module doesn't appear at a glance to distinguish between 
64bit and 32bit builds;  I don't understand how it is supposed to work.  I have 
a feeling that it is expected that find_library is supposed to distinguish the 
path behavior, but I don't have it set up right.

When I compile and link for 32bit, I get:

Scanning dependencies of target Foo
[ 72%] Building CXX object client/CMakeFiles/Foo.dir/Foo.cpp.o
[ 81%] Building CXX object client/CMakeFiles/Foo.dir/openCL.cpp.o
[ 90%] Building CXX object client/CMakeFiles/Foo.dir/StatisticalTimer.cpp.o
[100%] Building CXX object client/CMakeFiles/Foo.dir/stdafx.cpp.o
Linking CXX executable Foo
/usr/bin/ld: warning: i386:x86-64 architecture of input file 
`/usr/local/boost_1_44_0/lib64/libboost_program_options.a(cmdline.o)' is 
incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file 
`/usr/local/boost_1_44_0/lib64/libboost_program_options.a(options_description.o)'
 is incompatible with i386 output

As you can see, it is looking in lib64 instead of lib.  How do I change that 
behavior?

Thanks for any help,
Kent

___
Powered by www.kitware.com

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

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

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


[CMake] Linking Boost on Linux on 64bit host and 32bit target

2010-10-29 Thread Knox, Kent
Hi all~

I have a project using Boost that should compile for both 64bit and 32bit on a 
64bit host.  This works fine for a 64bit target, but I can't get this to work 
for a 32bit target.  I've done a fair share of googling to find this answer, 
but have not stumbled across anything that helps.  In fact, the only flag that 
I can find to distinguish between 32bit build and 64bit builds only applies to 
windows with ${CMAKE_CL_64}.

In order to compile for 32bit on a 64bit host, I have a -D parameter called 
BUILD64.  Here is my logic to initialize this var:

if( WIN32 )
set( BUILD64 ${CMAKE_CL_64} )
else()
option( BUILD64 Build a 64-bit product OFF )
if( BUILD64 )
message( STATUS 64-bit build )
endif( )
endif()

The syntax for finding boost is thus:
set( Boost_USE_MULTITHREADED ON )
set( Boost_USE_STATIC_LIBS   ON )
set( Boost_DETAILED_FAILURE_MSG   ON )
# set( Boost_DEBUG ON )
find_package( Boost 1.33.0 COMPONENTS program_options )

The boost find package module doesn't appear at a glance to distinguish between 
64bit and 32bit builds;  I don't understand how it is supposed to work.  I have 
a feeling that it is expected that find_library is supposed to distinguish the 
path behavior, but I don't have it set up right.

When I compile and link for 32bit, I get:

Scanning dependencies of target Foo
[ 72%] Building CXX object client/CMakeFiles/Foo.dir/Foo.cpp.o
[ 81%] Building CXX object client/CMakeFiles/Foo.dir/openCL.cpp.o
[ 90%] Building CXX object client/CMakeFiles/Foo.dir/StatisticalTimer.cpp.o
[100%] Building CXX object client/CMakeFiles/Foo.dir/stdafx.cpp.o
Linking CXX executable Foo
/usr/bin/ld: warning: i386:x86-64 architecture of input file 
`/usr/local/boost_1_44_0/lib64/libboost_program_options.a(cmdline.o)' is 
incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file 
`/usr/local/boost_1_44_0/lib64/libboost_program_options.a(options_description.o)'
 is incompatible with i386 output

As you can see, it is looking in lib64 instead of lib.  How do I change that 
behavior?

Thanks for any help,
Kent

___
Powered by www.kitware.com

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

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

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


Re: [CMake] several questions about cmake

2010-08-26 Thread Knox, Kent
 1) The default install directory on Windows is C:\Program Files, or

 C:\Program Files (x86) on 64 bit. ?This default will not work on

 Windows 7 (and perhaps Vista), because the user isn't running as

 administrator anymore, and only administrators can modify that

 directory. ?There should probably be a warning to that effect on

 windows systems; otherwise, there are painful ways to run install, but

 they are painful.



Most developers run as administrator so I don't think there should be a 
warning.

As a matter of fact, most developers do NOT run as administrator on Win7 and 
Vista; default users start with a split security token and you have to elevate 
permissions to write to the 'program files' directory.  The only way around 
this is to turn off UAC; that's an individual decision whether one feels safe 
doing that.

I would also like to see the default install directory for cmake change.  In 
the meantime, I have my cmake script itself change the default:

# On windows, it's convenient to change the default install prefix such that it 
does NOT point to 'program files'
if( WIN32 AND CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT )
set( CMAKE_INSTALL_PREFIX ${PROJECT_BINARY_DIR}/install CACHE 
PATH Install path prefix, prepended onto install directories FORCE )
endif( )



___
Powered by www.kitware.com

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

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

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

[CMake] Windows debugger command project settings

2010-08-20 Thread Knox, Kent
My current codebase produces an executable with several dynamically linked 
libraries.  I can't step through the code under the debugger until I've built 
the 'install' project, which copies all the binaries into the same output 
directory; they then can find each other.  Of course, at this point I need to 
change the debugger command path to point to the 'install' directory to find my 
executable in its new home.

Is there a way to configure cmake and visual studio projects such that they 
know to debug the applications built in the install directory?

Kent
___
Powered by www.kitware.com

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

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

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

Re: [CMake] CPACK_SOURCE_IGNORE_FILES

2009-06-30 Thread Knox, Kent
Yes, thank you for the response; I am in the process of moving my project from 
MSVC solution to out-of-source cmake builds.

Please ignore the fact that I used a generated file in my previous example, 
that's tangential to the problem I'm reporting.  Pretend that the set statement 
is: 

set( CPACK_SOURCE_IGNORE_FILES /Build/;/.hg/;/.svn/;/.txt/ )

I still can't get this to work.  I am wondering if I have the slashes right.  
The funny thing is, it does properly exclude my .svn folder.

Kent

-Original Message-
From: John Drescher [mailto:dresche...@gmail.com] 
Sent: Monday, June 29, 2009 9:14 PM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Re: [CMake] CPACK_SOURCE_IGNORE_FILES

On Mon, Jun 29, 2009 at 9:18 PM, Knox, Kentkent.k...@amd.com wrote:
 I'm integrating CPack into my build system, and can't quite get
 CPACK_SOURCE_IGNORE_FILES to work right.

 I want to cull individual files from the source package, like .ncb files
 and .pdb files and such.  It seems as though CPACK_SOURCE_IGNORE_FILES
 honors the directories that I want to exclude, but not individual files.
 For instance:

 set( CPACK_SOURCE_IGNORE_FILES
 /Build/;/.hg/;/.svn/;/.ncb$/ )

 will ignore the Build directory, as well as the .svn directory, but
 happily includes the .ncb files, even though I don't want them.

 I found a related post on stackoverflow.com from another user who seems
 to be experiencing the same problem:
 http://stackoverflow.com/questions/727075/regular-expression-for-hidden
 -files-under-unix

 Thx in advance.


My advice is to use out of source builds so that no generated files
like .ncb .. are mixed in with your source.

John


___
Powered by www.kitware.com

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

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

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


Re: [CMake] CPACK_SOURCE_IGNORE_FILES

2009-06-30 Thread Knox, Kent
Yes, I did try to escape the $; no joy.

No, I'm not against leaving the $ out, but I can't get it to work
anyway.

Kent
-Original Message-
From: Tyler Roscoe [mailto:ty...@cryptio.net] 
Sent: Monday, June 29, 2009 10:10 PM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Re: [CMake] CPACK_SOURCE_IGNORE_FILES

On Mon, Jun 29, 2009 at 08:18:35PM -0500, Knox, Kent wrote:
 set( CPACK_SOURCE_IGNORE_FILES
 /Build/;/.hg/;/.svn/;/.ncb$/ )

Have you tried escaping the $ ?

Have you tried just leaving the $ out, or do you really need to exclude
foo.ncb while including bar.ncbsomethingelse?

tyler


___
Powered by www.kitware.com

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

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

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


Re: [CMake] CPACK_SOURCE_IGNORE_FILES

2009-06-30 Thread Knox, Kent
Yes, this was the trick.  Thank you to Eric Noulard and David Cole

With the expression the way it is, you're trying to exclude things that
have literal /.txt in them. What you want is .txt right?

I suppose that I'm a little confused by the RegEx.  So with the '/'
characters, was I literally looking for a '/' characters in my search
patterns?  Is that why they work in the directory filters?  I was
thinking that they were the delimiters of a regex expression.

Thanks for your time.

Kent

-Original Message-
From: David Cole [mailto:david.c...@kitware.com] 
Sent: Tuesday, June 30, 2009 10:21 AM
To: Knox, Kent
Cc: John Drescher; cmake@cmake.org
Subject: Re: [CMake] CPACK_SOURCE_IGNORE_FILES

It's the leading / in the txt portion of the expression. get rid
of it.

(Eric already pointed this out in his reply to this email...)


With the expression the way it is, you're trying to exclude things that
have literal /.txt in them. What you want is .txt right?


On Tue, Jun 30, 2009 at 11:14 AM, Knox, Kent kent.k...@amd.com wrote:


Yes, thank you for the response; I am in the process of moving
my project from MSVC solution to out-of-source cmake builds.

Please ignore the fact that I used a generated file in my
previous example, that's tangential to the problem I'm reporting.
Pretend that the set statement is:

set( CPACK_SOURCE_IGNORE_FILES
/Build/;/.hg/;/.svn/;/.txt/ )

I still can't get this to work.  I am wondering if I have the
slashes right.  The funny thing is, it does properly exclude my .svn
folder.

Kent


-Original Message-
From: John Drescher [mailto:dresche...@gmail.com]
Sent: Monday, June 29, 2009 9:14 PM
To: Knox, Kent
Cc: cmake@cmake.org
Subject: Re: [CMake] CPACK_SOURCE_IGNORE_FILES

On Mon, Jun 29, 2009 at 9:18 PM, Knox, Kentkent.k...@amd.com
wrote:
 I'm integrating CPack into my build system, and can't quite
get
 CPACK_SOURCE_IGNORE_FILES to work right.

 I want to cull individual files from the source package, like
.ncb files
 and .pdb files and such.  It seems as though
CPACK_SOURCE_IGNORE_FILES
 honors the directories that I want to exclude, but not
individual files.
 For instance:

 set( CPACK_SOURCE_IGNORE_FILES
 /Build/;/.hg/;/.svn/;/.ncb$/ )

 will ignore the Build directory, as well as the .svn
directory, but
 happily includes the .ncb files, even though I don't want
them.

 I found a related post on stackoverflow.com from another user
who seems
 to be experiencing the same problem:

http://stackoverflow.com/questions/727075/regular-expression-for-hidden
 -files-under-unix

 Thx in advance.


My advice is to use out of source builds so that no generated
files
like .ncb .. are mixed in with your source.

John


___
Powered by www.kitware.com

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

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

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




___
Powered by www.kitware.com

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

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

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


[CMake] Re-defining CMAKE_CXX_FLAGS with /TP for cl.exe

2009-06-29 Thread Knox, Kent
I've just stumbled across some surprising cl.exe behavior, and I would like to 
see if the collective minds of this dist list has come across this before.

In my c++ project, I override CMAKE_CXX_FLAGS with my own flags, including /TP. 
 Using an nmake based build, this causes the linking step to bomb.  Enabling 
verbose mode for nMake, I saw that /TP was actually being defined twice, once 
by me and I suppose cMake did too for good measure.  By eliminating my flags 
one by one, I found that my /TP caused the link problem.

This is using cmake 2.6.4, 64bit MSVC tools and nmake generator.  Snippet of 
error log below.  Does this make sense to anybody?

Kent


[100%] Building CXX object foobar/CMakeFiles/foobar.dir/blahManager.cpp.obj
cd C:\Programming\foobar\nMake\foobar
C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe  @C:\Users\kknox\AppData\Loca
l\Temp\nm26C5.tmp
Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

cl   /DWIN32 /D_CONSOLE /EHsc /RTC1 /W3 /TP /DUNICODE /D_UNICODE /Od /D_DEBUG 
/MDd /Zi 
-IC:\Programming\boost_1_39_0  /TP /FoCMakeFiles\foobar.dir\blahManager.cpp.obj 
/FdC:\Programming\foobar\nMake\foobar\foobar.pdb -c 
C:\Programming\foobar\foobar\blahManager.cpp

blahManager.cpp
cd C:\Programming\foobar\nMake
Linking CXX executable foobar.exe
cd C:\Programming\foobar\nMake\foobar
C:\Utils\cmake-2.6.4-win32-x86\bin\cmake.exe -E vs_link_exe C:\PROGRA~2\
MICROS~1.0\VC\bin\amd64\cl.exe   @CMakeFiles\foobar.dir\objects1.rsp @C:\
Users\kknox\AppData\Local\Temp\nm2E55.tmp
Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

cl CMakeFiles\foobar.dir\foobar.cpp.obj 
CMakeFiles\foobar.dir\fooService.cpp.obj CMakeFiles\foobar.dir\stdafx.cpp.obj 
CMakeFiles\
foobar.dir\barService.cpp.obj CMakeFiles\foobar.dir\blahManager.cpp.obj

foobar.cpp.obj
CMakeFiles\foobar.dir\foobar.cpp.obj(2) : error C2146: syntax error : missing 
';' before identifier '¶8IJoí'
CMakeFiles\foobar.dir\foobar.cpp.obj(2) : error C4430: missing type specifier - 
int assumed. Note: C++ does not support default-int
CMakeFiles\foobar.dir\foobar.cpp.obj(2) : error C2146: syntax error : missing 
';' before identifier 'y'
CMakeFiles\foobar.dir\foobar.cpp.obj(2) : error C4430: missing type specifier - 
int assumed. Note: C++ does not support default-int
CMakeFiles\foobar.dir\foobar.cpp.obj(2) : error C2143: syntax error : missing 
';' before '%'
CMakeFiles\foobar.dir\foobar.cpp.obj(2) : error C4430: missing type specifier - 
int assumed. Note: C++ does not support default-int
CMakeFiles\foobar.dir\foobar.cpp.obj(2) : error C3193: '%' : requires '/clr' 
command line option
CMakeFiles\foobar.dir\foobar.cpp.obj(2) : error C2059: syntax error : '.'
CMakeFiles\foobar.dir\foobar.cpp.obj(2) : error C2018: unknown character '0x2'
CMakeFiles\foobar.dir\foobar.cpp.obj(2) : error C2018: unknown character '0x1'
CMakeFiles\foobar.dir\foobar.cpp.obj(3) : error C2018: unknown character '0x10'
CMakeFiles\foobar.dir\foobar.cpp.obj(3) : error C2018: unknown character '0x1'

___
Powered by www.kitware.com

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

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

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


[CMake] CPACK_SOURCE_IGNORE_FILES

2009-06-29 Thread Knox, Kent
I'm integrating CPack into my build system, and can't quite get
CPACK_SOURCE_IGNORE_FILES to work right.

I want to cull individual files from the source package, like .ncb files
and .pdb files and such.  It seems as though CPACK_SOURCE_IGNORE_FILES
honors the directories that I want to exclude, but not individual files.
For instance:

set( CPACK_SOURCE_IGNORE_FILES
/Build/;/.hg/;/.svn/;/.ncb$/ )

will ignore the Build directory, as well as the .svn directory, but
happily includes the .ncb files, even though I don't want them.

I found a related post on stackoverflow.com from another user who seems
to be experiencing the same problem:
http://stackoverflow.com/questions/727075/regular-expression-for-hidden
-files-under-unix

Thx in advance.

___
Powered by www.kitware.com

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

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

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


[CMake] subsystem questions for win ifort

2009-03-18 Thread Knox, Kent
Hi all~

I'm having trouble figuring out how to select the appropriate subsystem
for my cmake windows ifort project, with the IDE build environment.

By default, unless otherwise specified, intel's Fortran runtime file are
linked in statically.  Everything works fine statically; no errors.  I
prefer dynamically linked runtimes, and I have defined FFLAGS as so:

set( CMAKE_Fortran_FLAGS_DEBUG /Zi /Od /traceback /check:bounds
/libs:dll /threads /dbglibs /gen-interfaces /warn:interfaces )

The appropriate dynamic runtime options being /libs:dll /threads
/dbglibs.  At this point, the compiler fails with the message:
LINK : fatal error LNK1561: entry point must be defined

I've found that this is because /subsystem:console is not being
generated in the IDE project files.  Curiously enough, on an nMake
build, everything links fine.

I'm not sure what the proper way in Cmake is to specify the subsystem.
In the docs, I see a WIN32_PROPERTY, but no corresponding
CONSOLE_PROPERTY.  

I've hacked around this with info I found on this wiki page:
http://www.cmake.org/Wiki/VSConfigSpecificSettings

Which helped me to manually set a LINK FLAGS property.  It doesn't feel
proper though.

Another question:  I would like to see the flags that are being sent to
the ifort compiler/linker.  It appears that cmake/nmake puts all
compiler options into a tmp file, executes the compiler with the
response file, then promptly erases the tmp file.  How do I keep these
tmp files around so I can examine them?

Kent

___
Powered by www.kitware.com

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

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

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