[cmake-developers] Should CMAKE_LINK_DEPENDS_NO_SHARED be on by default?

2013-02-24 Thread Stephen Kelly

Hi,

CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by 
default. It seems useful enough to be on by default. Is there any reason not 
to enable it by default?

Thanks,

Steve.


--

Powered by www.kitware.com

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

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

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


[cmake-developers] [CMake 0013948]: Physfs version checking

2013-02-24 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=13948 
== 
Reported By:Vittorio Giovara
Assigned To:
== 
Project:CMake
Issue ID:   13948
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-02-24 18:05 EST
Last Modified:  2013-02-24 18:05 EST
== 
Summary:Physfs version checking
Description: 
It would be nice to have version checking support for PhysFS module.

Steps to Reproduce: 
find_package(PhysFS 2.1) - no effect

Additional Information: 
I had to implement this in a rough way,
https://code.google.com/p/hedgewars/source/browse/CMakeLists.txt#271 , an
integrated solution would be appreciated.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-02-24 18:05 Vittorio GiovaraNew Issue
==

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[cmake-developers] [CMake 0013949]: FAIL_REGULAR_EXPRESSION doesn't match beginning-of-line properly

2013-02-24 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=13949 
== 
Reported By:Dave Abrahams
Assigned To:
== 
Project:CMake
Issue ID:   13949
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2013-02-25 01:46 EST
Last Modified:  2013-02-25 01:46 EST
== 
Summary:FAIL_REGULAR_EXPRESSION doesn't match
beginning-of-line properly
Description: 
I ended up doing:

set_tests_properties(conversion PROPERTIES 
  DEPENDS prepare
  FAIL_REGULAR_EXPRESSION (^|
)[+][+] WARNING: 
  )

because this wasn't working:

set_tests_properties(conversion PROPERTIES 
  DEPENDS prepare
  FAIL_REGULAR_EXPRESSION ^[+][+] WARNING: 
  )

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-02-25 01:46 Dave Abrahams  New Issue
==

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [CMake] Please critique my hello world CMakeLists.txt and Config.cmake

2013-02-24 Thread Alexander Neundorf
Hi Chris,

On Sunday 24 February 2013, Chris Stankevitz wrote:
 Hello,
 
 Would you please critique my CMakeLists.txt and helloConfig.cmake.in
 files?  I am particularly interested in comments that will help me fix
 these problems:
 
 - In helloConfig.cmake.in, I assume static libraries will be built
 (.a).  I imaging a better approach would make no assumptions about
 this.
 
 - In helloConfig.cmake.in, I assume ${PREFIX} will expand to the
 installed prefix, but it does not.


Yes.
You should
* export the target (use the EXPORT option in install(TARGETS))
* the install this export, using install(EXPORT ...), this will install a 
cmake script file
* include() this export-file in the Config.cmake file
* use configure_package_config_file() instead of the plain configure_file() to 
configure the file. This will help with absolute and relative paths etc.

You may want to have a look at an example for this, e.g. here:
http://quickgit.kde.org/?p=kdelibs.gita=treeh=734d0c1887c89dd8260e67f912f026723226ff88hb=e3f5b30fd287e83f32c2cc756fc3ea4a17358ef7f=tier1%2Fitemmodels
(you can ignore ecm_setup_version() )
 
 - I type the same expression many times:
 hello-${hello_VERSION_MAJOR}.${hello_VERSION_MINOR}.  I imagine the
 better approach would derive this expression from some built-in cmake
 variables or from a variable I create.

It's ok.
Of course you can do
set(helloSubDir hello-${hello_VERSION_MAJOR}.${hello_VERSION_MINOR})
and then use that.
 
 - INSTALL is looking for helloConfig.cmake in the source directory but
 it is in the build directory.

install( ... ${CMAKE_CURRENT_BINARY_DIR}/hellConfig.cmake  )

and maybe also use the full path in configure_file():

configure_file(helloConfig.cmake.in
   ${CMAKE_CURRENT_BINARY_DIR}/helloConfig.cmake)

Alex
--

Powered by www.kitware.com

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

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

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


Re: [CMake] Please critique my hello world CMakeLists.txt and Config.cmake

2013-02-24 Thread Ansis Māliņš
# You don't need the .in file.

CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

PROJECT(hello)

set (hello_VERSION_MAJOR 1)
set (hello_VERSION_MINOR 1)

ENABLE_TESTING()

ADD_LIBRARY(hello hello.cpp)

# This works just the same. Unless I'm missing something.
SET(hello_INCLUDE_DIRS

${CMAKE_INSTALL_PREFIX}/include/hello-${hello_VERSION_MAJOR}.${hello_VERSION_MINOR})
SET(hello_LIBRARIES

${CMAKE_INSTALL_PREFIX}/lib/hello-${hello_VERSION_MAJOR}.${hello_VERSION_MINOR}/libhello.a)

INSTALL(TARGETS hello DESTINATION
  lib/hello-${hello_VERSION_MAJOR}.${hello_VERSION_MINOR})

INSTALL(FILES helloConfig.cmake DESTINATION
  lib/hello-${hello_VERSION_MAJOR}.${hello_VERSION_MINOR})

INSTALL(FILES hello.h DESTINATION
  include/hello-${hello_VERSION_MAJOR}.${hello_VERSION_MINOR})
--

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] Please critique my hello world CMakeLists.txt and Config.cmake

2013-02-24 Thread J Decker
On Sun, Feb 24, 2013 at 2:23 AM, Ansis Māliņš ansis.mal...@gmail.comwrote:

 # You don't need the .in file.

 CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

 PROJECT(hello)

 set (hello_VERSION_MAJOR 1)
 set (hello_VERSION_MINOR 1)

 ENABLE_TESTING()

 ADD_LIBRARY(hello hello.cpp)

 # This works just the same. Unless I'm missing something.
 SET(hello_INCLUDE_DIRS

 ${CMAKE_INSTALL_PREFIX}/include/hello-${hello_VERSION_MAJOR}.${hello_VERSION_MINOR})
 SET(hello_LIBRARIES

 ${CMAKE_INSTALL_PREFIX}/lib/hello-${hello_VERSION_MAJOR}.${hello_VERSION_MINOR}/libhello.a)


s/lib/${CMAKE_STATIC_LIBRARY_PREFIX}/
s/.a/${CMAKE_STATIC_LIBRARY_SUFFIX}/

also available ${CMAKE_EXECUTABLE_SUFFIX}  would be blank in your case, but
not always.

${CMAKE_SHARED_LIBRARY_PREFX}
${CMAKE_SHARED_LIBRARY_SUFFX}

PREFIX will be blank for windows platforms and SUFFIX appropriate .lib or
.dll (.a, .so )


 INSTALL(TARGETS hello DESTINATION
   lib/hello-${hello_VERSION_MAJOR}.${hello_VERSION_MINOR})

 INSTALL(FILES helloConfig.cmake DESTINATION
   lib/hello-${hello_VERSION_MAJOR}.${hello_VERSION_MINOR})

 INSTALL(FILES hello.h DESTINATION
   include/hello-${hello_VERSION_MAJOR}.${hello_VERSION_MINOR})

 --

 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] Please critique my hello world CMakeLists.txt and Config.cmake

2013-02-24 Thread Alexander Neundorf
On Sunday 24 February 2013, J Decker wrote:
 On Sun, Feb 24, 2013 at 2:23 AM, Ansis Māliņš ansis.mal...@gmail.comwrote:
  # You don't need the .in file.
  
  CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
  
  PROJECT(hello)
  
  set (hello_VERSION_MAJOR 1)
  set (hello_VERSION_MINOR 1)
  
  ENABLE_TESTING()
  
  ADD_LIBRARY(hello hello.cpp)
  
  # This works just the same. Unless I'm missing something.
  SET(hello_INCLUDE_DIRS
  
  ${CMAKE_INSTALL_PREFIX}/include/hello-${hello_VERSION_MAJOR}.${hello_VERS
  ION_MINOR}) SET(hello_LIBRARIES
  
  ${CMAKE_INSTALL_PREFIX}/lib/hello-${hello_VERSION_MAJOR}.${hello_VERSION_
  MINOR}/libhello.a)
 
 s/lib/${CMAKE_STATIC_LIBRARY_PREFIX}/
 s/.a/${CMAKE_STATIC_LIBRARY_SUFFIX}/
 
 also available ${CMAKE_EXECUTABLE_SUFFIX}  would be blank in your case, but
 not always.
 
 ${CMAKE_SHARED_LIBRARY_PREFX}
 ${CMAKE_SHARED_LIBRARY_SUFFX}
 
 PREFIX will be blank for windows platforms and SUFFIX appropriate .lib or
 .dll (.a, .so )

Please use the target-export feature, this handles all that for you, including 
dependent libraries, debug and optimized versions, etc.
http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets

Alex
--

Powered by www.kitware.com

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

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

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

Re: [CMake] CMake'ified Boost

2013-02-24 Thread Jean-Christophe Fillion-Robin
Hi James,
Make sens. Thanks for the follow up.
Jc


On Sat, Feb 23, 2013 at 5:06 AM, James Turner james.tur...@kdab.com wrote:

 No I'm simply using custom build and update commands to run bootstrap.sh
 and bjam with appropriate args. I suspect this is the piece the Xcode
 generator can't cope with, but I didn't have time to investigate in detail
 yet.

 Regards,
 James

 On 21 Feb 2013, at 17:59, Jean-Christophe Fillion-Robin 
 jchris.filli...@kitware.com wrote:

 Hi James,

 On a slightly different topic, you mentioned you were using Boost, did you
 find a version of boost  1.49 that was CMake'ified ?

 Here is the one I found:
 http://gitorious.org/boost/cmake/trees/cmake-1.49.0

 Thanks
 Jc


 On Thu, Feb 21, 2013 at 12:39 PM, Bill Hoffman 
 bill.hoff...@kitware.comwrote:

 On 2/21/2013 10:34 AM, James Turner wrote:

 I've just setup a SuperBuild using ExternalProject, and am pleasantly
 surprised how well it works so far.

 I've encountered one issue, which is awkward - I'm basically using
 the SuperBuild to automate assembling / updating dependencies for the
 final sub-project, which is the real project I normally work on. I
 typically work on that project using Xcode and the Xcode generator.
 The problem is, if I use -G Xcode for the super build, some parts
 fail (and to be honest this is no surprise - amongst the dependencies
 is Boost, for example).

 So the question, can I safely set things to use a different generator
 for a CMake-based ExternalProject, and still have a top-level build
 of everything? The documentation for how the generator flag is
 handled by ExternalProject_Add, makes me think there might be
 something 'magic' happening. (This would mean, for example, the
 top-level Makefile called xcodebuild to build the xcodeprojs I
 guess)

 I didn't yet try this on MSVC, I'm curious what the situation will be
 there with the same setup. Is a top-level NMake build with msbuild of
 VisualStudio child projects possible?

 It should work.  I do VS project builds with VS all the time.   The Xcode
 generator should work as well.  It passes the tests for external project.
  So, that should be something that should be fixed.


 --
 Bill Hoffman
 Kitware, Inc.
 28 Corporate Drive
 Clifton Park, NY 12065
 bill.hoff...@kitware.com
 http://www.kitware.com
 518 881-4905 (Direct)
 518 371-3971 x105
 Fax (518) 371-4573
 --

 Powered by www.kitware.com

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

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

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




 --
 +1 919 869 8849

 --

 Powered by www.kitware.com

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

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

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




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Please critique my hello world CMakeLists.txt and Config.cmake

2013-02-24 Thread Chris Stankevitz
On Sun, Feb 24, 2013 at 2:20 AM, Alexander Neundorf neund...@kde.org wrote:
 * export the target (use the EXPORT option in install(TARGETS))
 * the install this export, using install(EXPORT ...), this will install a
 cmake script file
 * include() this export-file in the Config.cmake file
 * use configure_package_config_file() instead of the plain configure_file() to
 configure the file. This will help with absolute and relative paths etc.

Alexander,

First, thank you for your reply.  This was exactly the kind of help I
was looking for.

Second, I attempted to follow your instructions.  I am a big proponent
of cmake at work.  I love how simple it is to create a hello world
project (particularly when compared to autotools).  However, my head
is spinning with the new jargon needed to properly install a simple
hello world package.  Even after reading the docs and wiki I don't
really understand what I am doing, I more or less just tried to copy
it.  Most of the EXPORT and CONFIGURE_PACKAGE docs seem to be geared
toward someone who already knows the old way of installing and just
needs a refresher to the new style.  I hope my hello project, once
it meets your approval, can be used to assist other new packagers in
the future.

Third, would you please take a look at my updated hello project and
the new hello-client project?  As you might imagine, hello-client is
an executable that uses the hello library.  I have done something
wrong in hello, hello-client, or both as hello-client fails to
compile.  I suspect that among other mistakes, I should have some
SET_AND_CHECKs in my Config.cmake.in file.  I also suspect that my
hello-client is missing a FIND_PACKAGE reference.

github links:
https://github.com/chrisstankevitz/hello
https://github.com/chrisstankevitz/hello-client

git clone links:
git://github.com/chrisstankevitz/hello.git
git://github.com/chrisstankevitz/hello-client.git

Thank you again for your help,

Chris
--

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] Please critique my hello world CMakeLists.txt and Config.cmake

2013-02-24 Thread Alexander Neundorf
Hi Chris,

On Sunday 24 February 2013, Chris Stankevitz wrote:
 On Sun, Feb 24, 2013 at 2:20 AM, Alexander Neundorf neund...@kde.org 
wrote:
  * export the target (use the EXPORT option in install(TARGETS))
  * the install this export, using install(EXPORT ...), this will install
  a cmake script file
  * include() this export-file in the Config.cmake file
  * use configure_package_config_file() instead of the plain
  configure_file() to configure the file. This will help with absolute and
  relative paths etc.
 
 Alexander,
 
 First, thank you for your reply.  This was exactly the kind of help I
 was looking for.
 
 Second, I attempted to follow your instructions.  I am a big proponent
 of cmake at work.  I love how simple it is to create a hello world
 project (particularly when compared to autotools).  However, my head
 is spinning with the new jargon needed to properly install a simple
 hello world package.  Even after reading the docs and wiki I don't
 really understand what I am doing, I more or less just tried to copy
 it.  Most of the EXPORT and CONFIGURE_PACKAGE docs seem to be geared
 toward someone who already knows the old way of installing and just
 needs a refresher to the new style.  I hope my hello project, once
 it meets your approval, can be used to assist other new packagers in
 the future.
 
 Third, would you please take a look at my updated hello project and
 the new hello-client project?  As you might imagine, hello-client is
 an executable that uses the hello library.  I have done something
 wrong in hello, hello-client, or both as hello-client fails to
 compile.  I suspect that among other mistakes, I should have some
 SET_AND_CHECKs in my Config.cmake.in file.  I also suspect that my
 hello-client is missing a FIND_PACKAGE reference.
 
 github links:
 https://github.com/chrisstankevitz/hello
 https://github.com/chrisstankevitz/hello-client

I had a look, the find_package() is missing indeed.


Maybe we'll start with the old way and get to the new way.

Your client should look like this:

cmake_minimum_required(VERSION 2.8)
project(hello-client)

find_package(hello REQUIRED NO_MODULE)

include_directories( ${hello_INCLUDE_DIRS} )

add_executable(hello-client hello-client.cpp)

target_link_libraries(hello-client ${hello_LIBRARIES} )



I think this is what you probably also expected, but maybe got confused due to 
the talking about importing and exporting targets.

Since you want find_package() to search for a Config.cmake file, I recommend 
to make this explicit by adding the NO_MODULE keyword. This way people looking 
at the CMakeLists.txt can know that a Config.cmake file is searched, not a 
Findhello.cmake.
This Config.cmake file should, as has always been the case, set the 
name_INCLUDE_DIRS and name_LIBRARIES variables, which you should use as 
always.


Now to the Config.cmake file.
In the most basic case it would look like that:

set(hello_LIBRARIES /some/path/libhello.a)
set(hello_INCLUDE_DIRS /some/path/include/ )


This would already kind of work.
It has the problem that the directories are hardcoded, so e.g. under Windows a 
user could not install the package in a directory of his choice, i.e. it is 
not relocatable.
Also, since the variables are simply set, there is not guarantee that the 
directories and files actually exist.

So if you use the configure_package_config_file() macro to configure that 
file, you put the @PACKAGE_INIT@ macro (this time really a macro, cmake will 
fill in code there) at the top, and this provides the set_and_check() 
function.
Then your file could look like this:


@PACKAGE_INIT@
set(hello_LIBRARIES /some/path/libhello.a)
set_and_check(hello_INCLUDE_DIRS /some/path/include/ )


This would still not be relocatable, but the set_and_check() would produce an 
error if the directory /some/path/include/ does not exist. This is good, since 
you would get an error at cmake time, and not at build time.
This error case should only happen if something went wrong, the install 
process was interrupted, files were moved or deleted manually, or something 
similar.

Now how do we get this file relocatable.
If you do this:


@PACKAGE_INIT@
set(hello_LIBRARIES /some/path/libhello.a)
set_and_check(hello_INCLUDE_DIRS @hello_DIRNAME_include@ )


and then call configure_package_config_file(), you'll get the full absolute 
hardcoded path again as above.
If you do instead


@PACKAGE_INIT@
set(hello_LIBRARIES /some/path/libhello.a)
set_and_check(hello_INCLUDE_DIR @PACKAGE_hello_DIRNAME_include@ )
set(hello_INCLUDE_DIRS ${hello_INCLUDE_DIR} )


and call
configure_package_config_file(... PATH_VARS hello_DIRNAME_include ...)
then cmake will put in some code so that the Config.cmake file will not have 
the absolute path to the include dir, but the relative path to the include, 
starting from the installed Config.cmake file itself.
(This is a bit tricky, you can have a look at the generated code in the 
Config.cmake file).

In the example above there are the variables 

Re: [CMake] Please critique my hello world CMakeLists.txt and Config.cmake

2013-02-24 Thread Chris Stankevitz
On Sun, Feb 24, 2013 at 12:37 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
 github links:
 https://github.com/chrisstankevitz/hello
 https://github.com/chrisstankevitz/hello-client

 Maybe we'll start with the old way and get to the new way.

Alex,

Thank you again.  I updated the projects per your teaching.  The only
place I had to guess was here:

INSTALL(
  FILES
${CMAKE_CURRENT_BINARY_DIR}/helloConfig.cmake
  DESTINATION
${hello_DIRNAME_lib}
  )

With respect to this INSTALL directive, I have three questions:

1. Is it needed?  [Apparently the answer is yes]

2. Is ${CMAKE_CURRENT_BINARY_DIR}/helloConfig.cmake the appropriate
way for me to reference this file?  I got this from kdelibs.git.

3. Is ${hello_DIRNAME_lib} (aka
/usr/local/lib/hello-1.1/helloConfig.cmake) the correct place to
install helloConfig.cmake?  kdelibs.git puts it somewhere else
(${CMAKECONFIG_INSTALL_DIR} which I guessed corresponds to the weird
location /usr/local/hello/).

Thank you again,

Chris
--

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] Toolchain file: Texas Instrument C6000 Code Generation Tools

2013-02-24 Thread Laszlo Papp
Here you can find the toolchain file I created:
https://projects.kde.org/projects/playground/mobile/wiki-reader/repository/revisions/master/entry/frontends/blackberry/cmake/Toolchain-C6X.cmake

I think the issue boils down to this:

root /home/lpapp/Projects/qt/skeleton/build #
/opt/ti/C6000CGT7.4.2/bin/cl6x --abi=eabi --run_linker ../main.c
Linking
../main.c, line 1: error: cannot find file int
../main.c, line 1: error: cannot find file main
../main.c, line 1: error: expecting filename, option, MEMORY, or SECTIONS
   instead of (
../main.c, line 4: error: expecting filename, option, MEMORY, or SECTIONS
   instead of }
fatal error: no input files

 Compilation failure
root /home/lpapp/Projects/qt/skeleton/build #
/opt/ti/C6000CGT7.4.2/bin/cl6x --abi=eabi ../main.c --run_linker
Linking
warning: automatic library build: using library
   /opt/ti/C6000CGT7.4.2/lib/rts6200_elf.lib for the first time, so it must
   be built.  This may take a few minutes.

Do you have any ideas how to solve this issue? It seems to me that, I would
need to pass the source files before the linker option.

Laszlo
--

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] Patch utility is installed, but my ExternalProject build step fails to execute it

2013-02-24 Thread David Brown
I'm trying to patch and build a Makefile-based project using the
ExternalProject module. My patch command looks like this:

PATCH_COMMAND patch -p1 -t -N  ${CMAKE_CURRENT_SOURCE_DIR}/IntelDFP.patch

When building, however, I get this:

[ 10%] Performing patch step for 'IntelDFP'
/bin/sh: 1: patch -p1 -t -N 
/home/david/Projects/db/IntelDFP.patch: not found

I'm certain that the patch utility is installed and that the patch
file path is correct. If I run that command myself, it works fine. So
why does the CMake-generated Makefile fail to execute it?
--

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] Patch utility is installed, but my ExternalProject build step fails to execute it

2013-02-24 Thread David Brown
Silly me... It was the quotes around the command. Sorry!

On Sun, Feb 24, 2013 at 7:58 PM, David Brown cypher...@gmail.com wrote:
 I'm trying to patch and build a Makefile-based project using the
 ExternalProject module. My patch command looks like this:

 PATCH_COMMAND patch -p1 -t -N  
 ${CMAKE_CURRENT_SOURCE_DIR}/IntelDFP.patch

 When building, however, I get this:

 [ 10%] Performing patch step for 'IntelDFP'
 /bin/sh: 1: patch -p1 -t -N 
 /home/david/Projects/db/IntelDFP.patch: not found

 I'm certain that the patch utility is installed and that the patch
 file path is correct. If I run that command myself, it works fine. So
 why does the CMake-generated Makefile fail to execute it?
--

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-commits] CMake branch, next, updated. v2.8.10.2-2316-g5cbeeef

2013-02-24 Thread Stephen Kelly
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  5cbeeef9ccb4d6bc9a46b8a559c4f4eaa9c64958 (commit)
   via  42ebb1886f7500c2f7a34fee99e2e9fa749f5a93 (commit)
  from  017d273c873f7d33bea09b65326c1e540f0801f2 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5cbeeef9ccb4d6bc9a46b8a559c4f4eaa9c64958
commit 5cbeeef9ccb4d6bc9a46b8a559c4f4eaa9c64958
Merge: 017d273 42ebb18
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sun Feb 24 16:05:19 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sun Feb 24 16:05:19 2013 -0500

Merge topic 'memoize-link-iface-includes-defines' into next

42ebb18 Memoize includes and defines from interface libraries.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42ebb1886f7500c2f7a34fee99e2e9fa749f5a93
commit 42ebb1886f7500c2f7a34fee99e2e9fa749f5a93
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Feb 22 13:03:35 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Sun Feb 24 22:04:20 2013 +0100

Memoize includes and defines from interface libraries.

This is similar in spirit to commit e48d8420 (Cache context-independent
includes on evaluation., 2013-02-03), but it is needed since commit
a1c4905f (Use the link information as a source of compile definitions
and includes., 2013-02-12), which changed how includes and defines
are determined. As they are now determined through the link interface,
we need to cache the result of evaluating them through that.

In the case of the includes, the result was already being cached
and then immediately disposed. Store the result as a member variable
instead to make use of the caching.

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 003f3d8..717cfc8 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -92,6 +92,7 @@ public:
 // Others not copied here are result caches.
 this-SourceEntries = r.SourceEntries;
 }
+  ~cmTargetInternals();
   typedef cmTarget::SourceFileFlags SourceFileFlags;
   std::mapcmSourceFile const*, SourceFileFlags SourceFlagsMap;
   bool SourceFileFlagsConstructed;
@@ -138,9 +139,36 @@ public:
   };
   std::vectorIncludeDirectoriesEntry* IncludeDirectoriesEntries;
   std::vectorcmValueWithOrigin LinkInterfaceIncludeDirectoriesEntries;
+
+  std::vectorIncludeDirectoriesEntry*
+CachedLinkInterfaceIncludeDirectoriesEntries;
+  std::mapstd::string, std::string CachedLinkInterfaceCompileDefinitions;
+
+  std::mapstd::string, bool CacheLinkInterfaceIncludeDirectoriesDone;
+  std::mapstd::string, bool CacheLinkInterfaceCompileDefinitionsDone;
 };
 
 //
+void deleteAndClear(
+  std::vectorcmTargetInternals::IncludeDirectoriesEntry* entries)
+{
+  for (std::vectorcmTargetInternals::IncludeDirectoriesEntry*::const_iterator
+  it = entries.begin(),
+  end = entries.end();
+  it != end; ++it)
+{
+  delete *it;
+}
+  entries.clear();
+}
+
+//
+cmTargetInternals::~cmTargetInternals()
+{
+  deleteAndClear(CachedLinkInterfaceIncludeDirectoriesEntries);
+}
+
+//
 cmTarget::cmTarget()
 {
   this-Makefile = 0;
@@ -2655,20 +2683,6 @@ void cmTarget::GatherDependencies( const cmMakefile mf,
 }
 
 //
-void deleteAndClear(
-  std::vectorcmTargetInternals::IncludeDirectoriesEntry* entries)
-{
-  for (std::vectorcmTargetInternals::IncludeDirectoriesEntry*::const_iterator
-  it = entries.begin(),
-  end = entries.end();
-  it != end; ++it)
-{
-  delete *it;
-}
-  entries.clear();
-}
-
-//
 void cmTarget::SetProperty(const char* prop, const char* value)
 {
   if (!prop)
@@ -2870,41 +2884,53 @@ std::vectorstd::string 
cmTarget::GetIncludeDirectories(const char *config)
 config,
 debugIncludes);
 
-  std::vectorcmTargetInternals::IncludeDirectoriesEntry*
-  linkInterfaceIncludeDirectoriesEntries;
-
-  for (std::vectorcmValueWithOrigin::const_iterator
-  it = this-Internal-LinkInterfaceIncludeDirectoriesEntries.begin(),
-  end = this-Internal-LinkInterfaceIncludeDirectoriesEntries.end();
-  it != end; ++it)
+  std::string configString = config 

[Cmake-commits] CMake branch, master, updated. v2.8.10.2-747-ge597ba2

2013-02-24 Thread Kitware Robot
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, master has been updated
   via  e597ba29288db609d0c3c797848fa7649851b1ee (commit)
  from  2de047669fd35cc293a29745990f26084a9b608a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e597ba29288db609d0c3c797848fa7649851b1ee
commit e597ba29288db609d0c3c797848fa7649851b1ee
Author: Kitware Robot kwro...@kitware.com
AuthorDate: Mon Feb 25 00:01:07 2013 -0500
Commit: Kitware Robot kwro...@kitware.com
CommitDate: Mon Feb 25 00:01:07 2013 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 073a09a..fdf42bb 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -2,5 +2,5 @@
 set(CMake_VERSION_MAJOR 2)
 set(CMake_VERSION_MINOR 8)
 set(CMake_VERSION_PATCH 10)
-set(CMake_VERSION_TWEAK 20130224)
+set(CMake_VERSION_TWEAK 20130225)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits