Re: [cmake-developers] Ninja: files per second

2012-07-30 Thread Shlomi Fish
Hi Peter,

On Sat, 28 Jul 2012 14:03:48 +0200
Peter Kümmel syntheti...@gmx.net wrote:

 On 28.07.2012 11:43, Shlomi Fish wrote:
 
  Nice.
 
  I was now able to get the Freecell Solver test suite to pass with ninja 
  test,
  but there is one problem: when I run ninja -vv test, then ninja displays 
  the
  line
  [1/1] cd /home/shlomif/progs/freecell/git/fc-solve/fc-solve/source/n
  perl /home/shlomif/progs/freecell/git/fc-solve/fc-solve/source/run-tests.pl
 
  and then it waits for the entire test suite to run, and only then displays 
  its
  output. This is frustrating because I want to see the output while the test
  suite is running. Is there anyway to do it like that?
 
 No, this is by design, ninja collects the whole output so it is not 
 interweaved
 with the output of other processes.
 
 Peter

Well, when I run ninja test, then eventually there's only one process running
and this it the test harness (for which I don't want to wait to finish to view
intermediate output). Can you consider integrating Nicolas’ solution from:

http://public.kitware.com/pipermail/cmake-developers/2012-July/004701.html

Regards,

Shlomi Fish

-- 
-
Shlomi Fish   http://www.shlomifish.org/
First stop for Perl beginners - http://perl-begin.org/

English spelling aims to be consistent. Publicly and methodically.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
--

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] Patch to support SVN externals in CTest update

2012-07-30 Thread Xavier Besseron
Hello,

I am affected by the issue in bug 12630
(http://public.kitware.com/Bug/view.php?id=12630), so I prepared a
patch.

This patch adds support for svn externals during CTest update. I
tested it successfully  with svn 1.6/1.7, Linux/Windows and with
nested externals as well.

Summary of the modifications:
- Add SVNInfo structure to hold info about each repository
- Get the list of external repositories (using 'svn status' and
ExternalParser)
- Run 'svn info' for all repositories, before and after the update
- Run 'svn log' for all repositories
- Build the correct path for all updated files (ie add the
external prefix and remove the svn base)

Let me know if you have any questions or comments.


Xavier


ctest_svn_externals.patch
Description: Binary data
--

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-developers] Patch to support SVN externals in CTest update

2012-07-30 Thread Brad King
On 07/30/2012 09:45 AM, Xavier Besseron wrote:
 I am affected by the issue in bug 12630
 (http://public.kitware.com/Bug/view.php?id=12630), so I prepared a
 patch.

Thanks for working on this!

 This patch adds support for svn externals during CTest update. I
 tested it successfully  with svn 1.6/1.7, Linux/Windows and with
 nested externals as well.
 
 Summary of the modifications:
 - Add SVNInfo structure to hold info about each repository
 - Get the list of external repositories (using 'svn status' and
 ExternalParser)
 - Run 'svn info' for all repositories, before and after the update
 - Run 'svn log' for all repositories
 - Build the correct path for all updated files (ie add the
 external prefix and remove the svn base)
 
 Let me know if you have any questions or comments.

The changes will be much easier to review in smaller pieces.
Please split this patch into a series.  For example, the first
patch should add the SVNInfo infrastructure with no functional
changes.  Each step in the series should still compile and
pass the UpdateSVN test.

Separately, please also extend the UpdateSVN test to exercise
the new functionality.

Thanks,
-Brad
--

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] Github pull request for Ninja on OS X

2012-07-30 Thread Brad King
Hi Folks,

Please take a look at this pull request:

 https://github.com/Kitware/CMake/pull/22

Thanks,
-Brad
--

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] find_package without REQUIRED can cause fatal error now

2012-07-30 Thread Bill Hoffman

Alex added this check:
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a2be068c

It guards against broken installations of packages.  This is a good 
thing.  However, it is causing a failed test:



http://open.cdash.org/buildSummary.php?buildid=2465838


--Checking FindVTK
CMake Error at //lib/vtk-5.8/VTKTargets-debug.cmake:996 (MESSAGE):
  The imported target vtkWrapTcl references the file

 //bin/vtkWrapTcl

  but this file does not exist.  Possible reasons include:


So, there is a bad config file for VTK on this machine.

However, if someone does an optional find_package it should not error 
out.   If you were building a project that you did not write the cmake 
files for and came across this error for an optional part of the system 
you might be stuck.  Not sure how to make the required bit propagate 
down to where this error is produced...


Thoughts?

-Bill
--

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-developers] find_package without REQUIRED can cause fatal error now

2012-07-30 Thread David Cole
Seems like message(FATAL_ERROR/SEND_ERROR needs to know whether it's
in the middle of a find_package( OPTIONAL ) call or not.

What would happen if the only line of code in a project config file is:

  message(FATAL_ERROR not implemented yet)

And then somebody did a find_package(OPTIONAL on that package?

The contents of hand-written project config files are arbitrary, and
we can't stop people from putting FATAL_ERRORs in them. So we should
deal with it generically internal to CMake somehow.


  David C.


On Mon, Jul 30, 2012 at 10:33 AM, Bill Hoffman bill.hoff...@kitware.com wrote:
 Alex added this check:
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a2be068c

 It guards against broken installations of packages.  This is a good thing.
 However, it is causing a failed test:


 http://open.cdash.org/buildSummary.php?buildid=2465838


 --Checking FindVTK
 CMake Error at //lib/vtk-5.8/VTKTargets-debug.cmake:996 (MESSAGE):
   The imported target vtkWrapTcl references the file

  //bin/vtkWrapTcl

   but this file does not exist.  Possible reasons include:


 So, there is a bad config file for VTK on this machine.

 However, if someone does an optional find_package it should not error out.
 If you were building a project that you did not write the cmake files for
 and came across this error for an optional part of the system you might be
 stuck.  Not sure how to make the required bit propagate down to where this
 error is produced...

 Thoughts?

 -Bill
 --

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

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-developers] find_package without REQUIRED can cause fatal error now

2012-07-30 Thread Brad King
On 07/30/2012 10:41 AM, David Cole wrote:
 Seems like message(FATAL_ERROR/SEND_ERROR needs to know whether it's
 in the middle of a find_package( OPTIONAL ) call or not.
 
 What would happen if the only line of code in a project config file is:
 
   message(FATAL_ERROR not implemented yet)
 
 And then somebody did a find_package(OPTIONAL on that package?
 
 The contents of hand-written project config files are arbitrary, and
 we can't stop people from putting FATAL_ERRORs in them. So we should
 deal with it generically internal to CMake somehow.

One could also have:

 $ cat lib/cmake/myproj/MyProjConfig.cmake
 Oops, this is not a CMake language file.  Uh oh.

and find_package could deal with it only by sandboxing the entire
load process.  This problem was not created by Alex's check.  His
check is only one instance of the conditions for the underlying
problem.

Sandboxing the entire operation is not achievable in our
current CMake language implementation.  It's not even fully
possible because the scripts could always do things that are
externally visible and not reversible like execute_process.

I'm not sure sandboxing any and all errors inside package
configuration files is the right thing either.  As a user
expecting find_package to locate a particular installation
that I do not know is corrupted I might bang my head against
the desk wondering why CMake is ignoring it.  We would have
to dump the entire output from the attempted/failed load as
a warning.

What do we do after such failure?  Ignore the instance and
continue to search for another one?  Consider the package
to be not found?  The answer should be consistent with what
happens since this change:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=16c0c737

when a package config file sets package_FOUND to FALSE.

-Brad
--

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 0013445]: file glob with relative path containing '.'

2012-07-30 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=13445 
== 
Reported By:nagger
Assigned To:
== 
Project:CMake
Issue ID:   13445
Category:   (No Category)
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2012-07-30 11:43 EDT
Last Modified:  2012-07-30 11:43 EDT
== 
Summary:file glob with relative path containing '.'
Description: 
At a call of file(GLOB var RELATIVE ${absdir} ...), if absdir contains /./
parts the resulting relative path is wrong

Steps to Reproduce: 
cmake_minimum_required(VERSION 2.8)
file(GLOB var1 *.txt)
file(GLOB var2 RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} *.txt)
file(GLOB var3 RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}/. *.txt)
file(GLOB var4 RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}/./. *.txt)
message(var1: '${var1}')
message(var2: '${var2}')
message(var3: '${var3}')
message(var4: '${var4}')

---
output:
var1: 'D:/src/CMake_globrelative/CMakeLists.txt'
var2: 'CMakeLists.txt'
var3: '../CMakeLists.txt'
var4: '../../CMakeLists.txt'
---
expected output:
var1: 'D:/src/CMake_globrelative/CMakeLists.txt'
var2: 'CMakeLists.txt'
var3: 'CMakeLists.txt'
var4: 'CMakeLists.txt'

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-07-30 11:43 nagger 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-developers] find_package without REQUIRED can cause fatal error now

2012-07-30 Thread Alexander Neundorf
On Monday 30 July 2012, Bill Hoffman wrote:
 Alex added this check:
   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a2be068c
 
 It guards against broken installations of packages.  This is a good
 thing.  However, it is causing a failed test:
 
 
 http://open.cdash.org/buildSummary.php?buildid=2465838
 
 
 --Checking FindVTK
 CMake Error at //lib/vtk-5.8/VTKTargets-debug.cmake:996 (MESSAGE):
The imported target vtkWrapTcl references the file
 
   //bin/vtkWrapTcl
 
but this file does not exist.  Possible reasons include:
 
 
 So, there is a bad config file for VTK on this machine.
 
 However, if someone does an optional find_package it should not error
 out.   If you were building a project that you did not write the cmake
 files for and came across this error for an optional part of the system
 you might be stuck.

The idea was that this is a sign of a broken install.
Can you uninstall the vtk-devel package (does this exist ?), because it is 
broken, i.e. does not contain everything is claims to ?

I understand that this is maybe not expected behaviour for an optional 
package, but maybe Brad is right ?

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

Re: [cmake-developers] CMake, Xcode 4.4, and Mountain Lion

2012-07-30 Thread Óscar Fuentes
Ho Cheung hocheun...@gmail.com writes:

[snip]

 Since Xcode uses clang but CMAKE_C_COMPILER is set to gcc, the gcc
 compiler flags are being passed to clang.

Something related to this issue is being commented on the LLVM ml rigth
now: while searching for compilers, CMake prefers gcc over cc and that
is causing trouble:

http://comments.gmane.org/gmane.comp.compilers.llvm.devel/52263


--

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] installing python scripts

2012-07-30 Thread Michael Wild
On 07/30/2012 02:15 AM, Kyle Husmann wrote:
 Hi all,
 
 In my project I have a python program (call it program.py) that
 references a python module also in my project (call it pymodule).
 program.py gets installed to ${CMAKE_INSTALL_PREFIX}/bin/program and
 pymodule gets installed to ${PYTHON_INSTALL_DIR}.
 
 To make sure the program.py program always finds pymodule, I treat it
 like a config script in cmake and then add the following to the top of
 program.py.in http://program.py.in:
 
 import sys
 sys.path.append(@PYTHON_INSTALL_DIR@)
 import pymodule
 
 This works great, but it means that I can only run program.py after
 running a make install, and running it from the installed location.
 
 My question is, is there are clever way of doing this so that I can run
 program.py from the build directory, without having to install it? (But
 have it still run properly when installed)
 
 Thanks,
 Kyle

Call CONFIGURE_FILE() twice, once for the installation and once for the
build-tree:

set(CONFIG_PY_DIR ${PROJECT_SOURCE_DIR})
configure_file(program.py.in ${PROJECT_BINARY_DIR}/program.py @ONLY)
set(CONFIG_PY_DIR ${PYTHON_INSTALL_DIR})
configure_file(program.py.in
  ${PROJECT_BINARY_DIR}/installFiles/program.py @ONLY)
install(PROGRAMS ${PROJECT_BINARY_DIR}/installFiles/program.py
  DESTINATION bin)


You'll need to replace PYTHON_INSTALL_DIR with CONFIG_PY_DIR in your
program.py.in file, of course. Also, I would replace the
sys.path.append(@CONFIG_PY_DIR@) call with sys.path.insert(0,
@CONFIG_PY_DIR@). There are pros and cons for each...

HTH

Michael
--

Powered by www.kitware.com

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

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

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


Re: [CMake] Disabling C for C++-only projects

2012-07-30 Thread Johannes Zarl
Am 26.07.2012, 17:53:01 schrieb Alexander Neundorf:
 On Thursday 26 July 2012, Johannes Zarl wrote:
  On Wednesday 25 July 2012 22:20:55 Clinton Stimpson wrote:
   This has already been fixed in FindQt4 since CMake 2.8.6.
  
  ...using cmake 2.8.9-rc1 from debian.
 
 if you use it together with FindKDE4.cmake, you get the copy of
 FindQt4.cmake coming with kdelibs, which apparently does not yet have
 these fixes applied.

Yes, that's it. Thanks for the info!

  Johannes
--

Powered by www.kitware.com

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

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

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


[CMake] multiple line of comment howto

2012-07-30 Thread luxInteg
Greetings

I am learniong cmake.  From the documentation:-
 add_custom_target(Name [ALL] [command1 [args1...]]
[COMMAND command2 [args2...] ...]
[DEPENDS depend depend depend ... ]
[WORKING_DIRECTORY dir]
[COMMENT comment] [VERBATIM]
[SOURCES src1 [src2...]])




I want to  generate multiple line   in the compiler output
  when using add_custom_target()  such as  shown below

#---
set(line0 )
set(line1  )
set(line2compiling $some_source_code} ' )
#--

add_custom_command(whatever ALL
  ...
COMMAND ${whatever}
COMMENT  ${line0}  ${line1}  ${line2} ${line1} ${line0}
VERBATIM )


is the above recommended   to generate multiple lines?
Guidance would be appreciated.
--

Powered by www.kitware.com

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

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

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


Re: [CMake] multiple line of comment howto

2012-07-30 Thread Petr Kmoch
Hi.

I think you're looking for
...
COMMENT ${line0}\n${line1}\n${line2}\n${line1}\n${line0}
...

Petr

On Mon, Jul 30, 2012 at 11:42 AM, luxInteg lux-in...@btconnect.com wrote:
 Greetings

 I am learniong cmake.  From the documentation:-
  add_custom_target(Name [ALL] [command1 [args1...]]
 [COMMAND command2 [args2...] ...]
 [DEPENDS depend depend depend ... ]
 [WORKING_DIRECTORY dir]
 [COMMENT comment] [VERBATIM]
 [SOURCES src1 [src2...]])




 I want to  generate multiple line   in the compiler output
   when using add_custom_target()  such as  shown below

 #---
 set(line0 )
 set(line1  )
 set(line2compiling $some_source_code} ' )
 #--

 add_custom_command(whatever ALL
   ...
 COMMAND ${whatever}
 COMMENT  ${line0}  ${line1}  ${line2} ${line1} ${line0}
 VERBATIM )


 is the above recommended   to generate multiple lines?
 Guidance would be appreciated.
 --

 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] stderr and stdout in cmake

2012-07-30 Thread luxInteg
Greetings

I have   a  bash script (from an auto-tools Makefile )   to translate   to 
cmake


My 'translation might  go something like thios

execute_process(COMMAND ${some_command}  '21'
INPUT_FILE${someFile2}
OUTPUT_FILE/dev/null
WORKING_DIRECTORY ${some_dir} )

I am unconfortable with the '21'  and I tried  reading up on 

file(WRITE ) and 
file(APPEND )   

but I am unsure how to proceed; for example how to use cmake -P  or cmake --
build  or using /dev/std* device files

test [ ~ ]$ ls /dev/std*
/dev/stderr  /dev/stdin  /dev/stdout
test [ ~ ]$ 


Advice would be  appreciated

Yours sincerely
luxInteg
--

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] Recommended Multilib Build Approach?

2012-07-30 Thread Gregory Peele ARA/CFD
From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net] 
Sent: Saturday, July 28, 2012 11:48 AM
To: cmake@cmake.org
Cc: Gregory Peele ARA/CFD
Subject: Re: [CMake] Recommended Multilib Build Approach?

On Thursday 21 June 2012, Gregory Peele ARA/CFD wrote:
 Hi all,
 
 I want to be able to build 32-bit and 64-bit from the same GCC multilib
 install (currently for MinGW-w64, though this also applies for Linux/Mac
 GCC and LLVM). To clarify, I want to be able to do two completely
 separate builds in separate binary dirs - building fat binaries from
 multiple architectures in the same binary dir is a separate problem I'm
 also interested in for Android, but I'm not worrying about that yet.
 
 What is the proper approach to building the non-default arch in a
 multilib setup? Obviously using CMake as-is will build the default arch
 just fine.
 I think there are no recommendations yet. I'm not aware that somebody else 
 already tried to do this.
 Can the executables built for the non-default architecture be executed on the 
 hopst where you are building ?
 If so, there should be a way :-)
 If not, this sounds like somewhat like crosscompiling.
 Alex

I haven't explored the topic any further since posting.  On a multilib system, 
all multilib architectures are native to the host and can be executed.  
Basically the problem I wanted to solve was getting the x86-64 GCC or LLVM 
compiler to produce 32-bit x86 code in an easy and non-intrusive way.

Right now I'm forcibly adding the -m32 flags to all relevant CMake variables 
within my top-level CMake script if CMAKE_SYSTEM_PROCESSOR is set to x86 or 
i686, and conversely the -m64 flags if set to x86-64 or AMD64.  It seems like 
there should be a less intrusive way of doing it, and I'm not sure if this 
skews some early compiler/platform tests prior to me overriding the flags.  
Visual Studio doesn't have this issue since the 32-bit and 64-bit builds are 
entirely separate CMake generators - a strange decision, in my opinion, but 
easy enough to work with.

Greg
--

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] Recommended Multilib Build Approach?

2012-07-30 Thread Xavier Besseron
Hello Greg,


To build i386 binaries on my 64-bit system with multilib, I just do
something like this:

mkdir build-i386
cd build-i386
CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-melf_i386 cmake ../src/

And to build x86-64 binaries on my 64-bit system,  I don't need to
specify anything since it is the default behavior.


Xavier

On Mon, Jul 30, 2012 at 6:43 PM, Gregory Peele ARA/CFD gpe...@ara.com wrote:
 From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net]
 Sent: Saturday, July 28, 2012 11:48 AM
 To: cmake@cmake.org
 Cc: Gregory Peele ARA/CFD
 Subject: Re: [CMake] Recommended Multilib Build Approach?

 On Thursday 21 June 2012, Gregory Peele ARA/CFD wrote:
 Hi all,

 I want to be able to build 32-bit and 64-bit from the same GCC multilib
 install (currently for MinGW-w64, though this also applies for Linux/Mac
 GCC and LLVM). To clarify, I want to be able to do two completely
 separate builds in separate binary dirs - building fat binaries from
 multiple architectures in the same binary dir is a separate problem I'm
 also interested in for Android, but I'm not worrying about that yet.

 What is the proper approach to building the non-default arch in a
 multilib setup? Obviously using CMake as-is will build the default arch
 just fine.
 I think there are no recommendations yet. I'm not aware that somebody else 
 already tried to do this.
 Can the executables built for the non-default architecture be executed on 
 the hopst where you are building ?
 If so, there should be a way :-)
 If not, this sounds like somewhat like crosscompiling.
 Alex

 I haven't explored the topic any further since posting.  On a multilib 
 system, all multilib architectures are native to the host and can be 
 executed.  Basically the problem I wanted to solve was getting the x86-64 GCC 
 or LLVM compiler to produce 32-bit x86 code in an easy and non-intrusive way.

 Right now I'm forcibly adding the -m32 flags to all relevant CMake 
 variables within my top-level CMake script if CMAKE_SYSTEM_PROCESSOR is set 
 to x86 or i686, and conversely the -m64 flags if set to x86-64 or AMD64.  
 It seems like there should be a less intrusive way of doing it, and I'm not 
 sure if this skews some early compiler/platform tests prior to me overriding 
 the flags.  Visual Studio doesn't have this issue since the 32-bit and 64-bit 
 builds are entirely separate CMake generators - a strange decision, in my 
 opinion, but easy enough to work with.

 Greg
 --

 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] Recommended Multilib Build Approach?

2012-07-30 Thread Alexander Neundorf
On Monday 30 July 2012, Gregory Peele ARA/CFD wrote:
 From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net]
 Sent: Saturday, July 28, 2012 11:48 AM
 To: cmake@cmake.org
 Cc: Gregory Peele ARA/CFD
 Subject: Re: [CMake] Recommended Multilib Build Approach?
 
 On Thursday 21 June 2012, Gregory Peele ARA/CFD wrote:
  Hi all,
  
  I want to be able to build 32-bit and 64-bit from the same GCC multilib
  install (currently for MinGW-w64, though this also applies for Linux/Mac
  GCC and LLVM). To clarify, I want to be able to do two completely
  separate builds in separate binary dirs - building fat binaries from
  multiple architectures in the same binary dir is a separate problem I'm
  also interested in for Android, but I'm not worrying about that yet.
  
  What is the proper approach to building the non-default arch in a
  multilib setup? Obviously using CMake as-is will build the default arch
  just fine.
  
  I think there are no recommendations yet. I'm not aware that somebody
  else already tried to do this. Can the executables built for the
  non-default architecture be executed on the hopst where you are building
  ? If so, there should be a way :-)
  If not, this sounds like somewhat like crosscompiling.
  Alex
 
 I haven't explored the topic any further since posting.  On a multilib
 system, all multilib architectures are native to the host and can be
 executed.  

Ah, ok.
So the idea is not that I have e.g. /usr/lib/i386/ and /usr/lib/x86-64 and 
also /usr/lib/armv7/ and /usr/lib/mips/, which have different libs but share 
the headers and all other architecture independent files ?

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

[CMake] How to automate building of third party library using cmake

2012-07-30 Thread Vivek Goel
What I am looking for:

   - Download library
   - Extract It
   - Apply custom patch
   - Run configure
   - Run build command

What library I am trying to build  are:

   - Openssl
   - Boost
   - Thrift
   - C-ares
   - Curl
   - Pcre
   - Nginx
   - ICU
   - JsonCPP


I think I can do these things using external module:
http://cmake.org/cmake/help/v2.8.8/cmake.html#module:ExternalProject

But I have following question?

   1. I have different type of build and with different directory. Is it
   going to build all these library for every different target? If yes it will
   be painful as all these library take one hour to build. Is there a way I
   can control it and it only build it once. As library remains same for all
   these targets.
   2. On switching directory to different name. Cmake force everything to
   be rebuild-ed. Will it be same for external library. If yes? How to solve
   this problem. I don't want to rebuild the library if I am not changing them
   and want to use them while switching to different branches without building
   them.



regards
Vivek Goel
--

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] Automating package installion if not there

2012-07-30 Thread Vivek Goel
I have a project. Which is getting build-ed from different developers on
different system.
Is there a way I can automate package installation of not found for
packages like:

   - gcc
   - yacc

If not is there a way I can pre check if particular tool is installed or
not. If not show a good message to user please install the package and
abort like:

Seems like you have not installed gcc, g++, yacc required to build this
project. Please run following command to fix this problem:
   yum install gcc g++ yacc -y

regards
Vivek Goel
--

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] Recommended Multilib Build Approach?

2012-07-30 Thread Alexander Neundorf
On Monday 30 July 2012, Xavier Besseron wrote:
 Hello Greg,
 
 
 To build i386 binaries on my 64-bit system with multilib, I just do
 something like this:
 
 mkdir build-i386
 cd build-i386
 CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-melf_i386 cmake ../src/
 
 And to build x86-64 binaries on my 64-bit system,  I don't need to
 specify anything since it is the default behavior.

Is this maybe somewhat similar to the fat binaries on OSX ?
How is this handled by 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

[CMake] Mastering CMake 6th edition?

2012-07-30 Thread Xu Wang
Hi,

I'm curious as to whether there will be a 6th edition of this wonderful
book. If so, any (rough?) estimate on when it will be published?

Thanks so much!

Xu
--

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] Recommended Multilib Build Approach?

2012-07-30 Thread Xavier Besseron
On Mon, Jul 30, 2012 at 9:44 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
 On Monday 30 July 2012, Xavier Besseron wrote:
 To build i386 binaries on my 64-bit system with multilib, I just do
 something like this:

 mkdir build-i386
 cd build-i386
 CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-melf_i386 cmake ../src/

 And to build x86-64 binaries on my 64-bit system, I don't need to
 specify anything since it is the default behavior.

 Is this maybe somewhat similar to the fat binaries on OSX ?


No, I don't think so. You have to use two build directories, one for
32-bit code, one for 64-bit code. At the end, you will have two
different binaries.


 How is this handled by CMake ?


This is quite independent of CMake. It works with other build systems
like autotools/makefile as well.

CFLAGS=-m32 CXXFLAGS=-m32 tells CMake to pass the '-m32' to the C
and C++ compilers.
It tells the compiler to generate code that runs on any i386 system
(cf gcc manpage).

LDFLAGS=-melf_i386 tells CMake to pass the '-melf_i386' to the linker.
It tells the linker to use the i386 ELF format for the binary (cf ld manpage).

This works for GNU compiler/linker at least. I haven't tried other compilers.


Xavier
--

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] VC++10 change WIN32_EXECUTABLE per configuration

2012-07-30 Thread Steve deRosier
I need a way to have the WIN32_EXECUTABLE property set off for debug
builds and on for release builds when using the IDE.

Here's the deal: For debug our code uses the standard main()
construct, and for release we use the WinMain(). Lets just say there's
a reason and leave it at that...
The obvious solution is to be able to specify the '/subsystem:windows'
flag myself in LINK_FLAGS_DEBUG and LINK_FLAGS_RELEASE.

But, the generator overrides these settings for me.  So, I found the
WIN32 for add_executable(), but of course you can't specify that
differently for debug vs release.

For a make-file generator, I could just utilize:
if( ${CMAKE_BUILD_TYPE} STREQUAL Debug )
...
elseif( ${CMAKE_BUILD_TYPE} STREQUAL Release )
...
endif()

but of course this doesn't work when generating for VS10 IDE.

I found the CMAKE_CREATE_WIN32_EXE variable, but overriding it to 
does nothing, so I resorted to looking at cmake's source code, which
totally ignores that variable, and hard codes the linker flag in the
output based on the WIN32_EXECUTABLE property! (see line 1409 of
cmVisualStudio10TargetGenerator.cxx).

OK, other than hacking the cmake source and rolling our own, so is
there any way to:
1. Override the setting after-the-fact but before the project files
are actually written?
2. Set the WIN32_EXECUTABLE property on a per-configuration basis?

At the moment I see four options- hack the cmake source and roll our
own; do some post-processing on the produced project files; Force
everyone to manually change the flag in the IDE; convince my client to
restructure some code so we don't encounter this problem in the first
place.

I'm hoping there's more options out there that are pure project.cmake
file-based. Anyone?

Thanks,
- Steve
--

Powered by www.kitware.com

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

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

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


[CMake] Problems with FindBoost.cmake

2012-07-30 Thread Christian Henning
Hi there, I'm trying to figure why cmake cannot find my boost
installation. Actually, I'm working of some outdated boost's trunk
version ( 1.50 ). I'm setting various variables, like BOOST_ROOT,
BOOST_INCLUDEDIR, etc. But findBoost.cmake always comes up with
Boost_FOUND = FALSE.

Here is the output I get from that module: ( a more read friendlier
can be found here: http://pastebin.com/raw.php?i=6tiRftVW )

-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:526
] Boost not in cache
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:529
] _boost_TEST_VERSIONS =
1.50;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;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
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:531
] Boost_USE_MULTITHREADED = TRUE
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:533
] Boost_USE_STATIC_LIBS = on
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:535
] Boost_USE_STATIC_RUNTIME = on
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:537
] Boost_ADDITIONAL_VERSIONS = 1.50
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:539
] Boost_NO_SYSTEM_PATHS =
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:607
] Declared as CMake or Environmental Variables:
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:609
]   BOOST_ROOT = C:/boost
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:611
]   BOOST_INCLUDEDIR = c:\boost\boost
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:613
]   BOOST_LIBRARYDIR = C:\boost\stage\lib\x86
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:615
] _boost_TEST_VERSIONS =
1.50;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;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
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:668
] Include debugging info:
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:670
]   _boost_INCLUDE_SEARCH_DIRS =
c:/boost/boost;C:/boost/include;C:/boost;C:/boost/include;C:/boost;C:\Program
Files (x86)/boost/include;C:\Program Files
(x86)/boost;/sw/local/include
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:672
]   _boost_PATH_SUFFIXES =
boost-1_50;boost_1_50;boost-1_50_0;boost_1_50_0;boost-1_50;boost_1_50;boost-1_49_0;boost_1_49_0;boost-1_49;boost_1_49;boost-1_48_0;boost_1_48_0;boost-1_48;boost_1_48;boost-1_47_0;boost_1_47_0;boost-1_47;boost_1_47;boost-1_46_1;boost_1_46_1;boost-1_46_0;boost_1_46_0;boost-1_46;boost_1_46;boost-1_45_0;boost_1_45_0;boost-1_45;boost_1_45;boost-1_44_0;boost_1_44_0;boost-1_44;boost_1_44;boost-1_43_0;boost_1_43_0;boost-1_43;boost_1_43;boost-1_42_0;boost_1_42_0;boost-1_42;boost_1_42;boost-1_41_0;boost_1_41_0;boost-1_41;boost_1_41;boost-1_40_0;boost_1_40_0;boost-1_40;boost_1_40;boost-1_39_0;boost_1_39_0;boost-1_39;boost_1_39;boost-1_38_0;boost_1_38_0;boost-1_38;boost_1_38;boost-1_37_0;boost_1_37_0;boost-1_37;boost_1_37;boost-1_36_1;boost_1_36_1;boost-1_36_0;boost_1_36_0;boost-1_36;boost_1_36;boost-1_35_1;boost_1_35_1;boost-1_35_0;boost_1_35_0;boost-1_35;boost_1_35;boost-1_34_1;boost_1_34_1;boost-1_34_0;boost_1_34_0;boost-1_34;boost_1_34;boost-1_33_1;boost_1_33_1;boost-1_33_0;boost_1_3
 3_0;boost-1_33;boost_1_33
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:697
] location of version.hpp: C:/boost/boost/version.hpp
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:716
] version.hpp reveals boost 1.50.0
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:809
] guessed _boost_COMPILER = -vc100
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:819
] _boost_MULTITHREADED = -mt
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:862
] _boost_RELEASE_ABI_TAG = -s
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:864
] _boost_DEBUG_ABI_TAG = -sgd
-- [ 
C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:907
] _boost_LIBRARY_SEARCH_DIRS =
C:/boost/stage/lib/x86;C:/boost/lib;C:/boost/stage/lib;C:/boost/lib;C:/boost/../lib;C:/boost/stage/lib;C:/boost/lib;C:/boost;C:\Program
Files (x86)/boost/boost_1_50_0/lib;C:\Program Files

Re: [CMake] Problems with FindBoost.cmake

2012-07-30 Thread Michael Jackson
Where is your boost installed at? What operating system are you using? Is this 
boost precompiled or compiled by you?
If you set BOOST_ROOT as a cmake variable and point it to the top level 
directory of your boost installation does that help?

For example if you boost is installed in C:\Boost then set BOOST_ROOT to 
C:\Boost

--
Mike Jackson www.bluequartz.net

On Jul 30, 2012, at 8:44 PM, Christian Henning wrote:

 Hi there, I'm trying to figure why cmake cannot find my boost
 installation. Actually, I'm working of some outdated boost's trunk
 version ( 1.50 ). I'm setting various variables, like BOOST_ROOT,
 BOOST_INCLUDEDIR, etc. But findBoost.cmake always comes up with
 Boost_FOUND = FALSE.
 
 Here is the output I get from that module: ( a more read friendlier
 can be found here: http://pastebin.com/raw.php?i=6tiRftVW )
 
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:526
 ] Boost not in cache
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:529
 ] _boost_TEST_VERSIONS =
 1.50;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;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
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:531
 ] Boost_USE_MULTITHREADED = TRUE
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:533
 ] Boost_USE_STATIC_LIBS = on
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:535
 ] Boost_USE_STATIC_RUNTIME = on
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:537
 ] Boost_ADDITIONAL_VERSIONS = 1.50
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:539
 ] Boost_NO_SYSTEM_PATHS =
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:607
 ] Declared as CMake or Environmental Variables:
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:609
 ]   BOOST_ROOT = C:/boost
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:611
 ]   BOOST_INCLUDEDIR = c:\boost\boost
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:613
 ]   BOOST_LIBRARYDIR = C:\boost\stage\lib\x86
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:615
 ] _boost_TEST_VERSIONS =
 1.50;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;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
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:668
 ] Include debugging info:
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:670
 ]   _boost_INCLUDE_SEARCH_DIRS =
 c:/boost/boost;C:/boost/include;C:/boost;C:/boost/include;C:/boost;C:\Program
 Files (x86)/boost/include;C:\Program Files
 (x86)/boost;/sw/local/include
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:672
 ]   _boost_PATH_SUFFIXES =
 boost-1_50;boost_1_50;boost-1_50_0;boost_1_50_0;boost-1_50;boost_1_50;boost-1_49_0;boost_1_49_0;boost-1_49;boost_1_49;boost-1_48_0;boost_1_48_0;boost-1_48;boost_1_48;boost-1_47_0;boost_1_47_0;boost-1_47;boost_1_47;boost-1_46_1;boost_1_46_1;boost-1_46_0;boost_1_46_0;boost-1_46;boost_1_46;boost-1_45_0;boost_1_45_0;boost-1_45;boost_1_45;boost-1_44_0;boost_1_44_0;boost-1_44;boost_1_44;boost-1_43_0;boost_1_43_0;boost-1_43;boost_1_43;boost-1_42_0;boost_1_42_0;boost-1_42;boost_1_42;boost-1_41_0;boost_1_41_0;boost-1_41;boost_1_41;boost-1_40_0;boost_1_40_0;boost-1_40;boost_1_40;boost-1_39_0;boost_1_39_0;boost-1_39;boost_1_39;boost-1_38_0;boost_1_38_0;boost-1_38;boost_1_38;boost-1_37_0;boost_1_37_0;boost-1_37;boost_1_37;boost-1_36_1;boost_1_36_1;boost-1_36_0;boost_1_36_0;boost-1_36;boost_1_36;boost-1_35_1;boost_1_35_1;boost-1_35_0;boost_1_35_0;boost-1_35;boost_1_35;boost-1_34_1;boost_1_34_1;boost-1_34_0;boost_1_34_0;boost-1_34;boost_1_34;boost-1_33_1;boost_1_33_1;boost-1_33_0;boost_1
 _3
 3_0;boost-1_33;boost_1_33
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:697
 ] location of version.hpp: C:/boost/boost/version.hpp
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:716
 ] version.hpp reveals boost 1.50.0
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:809
 ] guessed _boost_COMPILER = -vc100
 -- [ 
 C:/Users/chenning/cmake-2.8.8-win32-x86/share/cmake-2.8/Modules/FindBoost.cmake:819
 ] _boost_MULTITHREADED = -mt
 -- [ 
 

Re: [CMake] Recommended Multilib Build Approach?

2012-07-30 Thread m.hergarden

On 07/30/2012 11:28 PM, Xavier Besseron wrote:

On Mon, Jul 30, 2012 at 9:44 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:

On Monday 30 July 2012, Xavier Besseron wrote:

To build i386 binaries on my 64-bit system with multilib, I just do
something like this:

mkdir build-i386
cd build-i386
CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-melf_i386 cmake ../src/

And to build x86-64 binaries on my 64-bit system, I don't need to
specify anything since it is the default behavior.

Is this maybe somewhat similar to the fat binaries on OSX ?


No, I don't think so. You have to use two build directories, one for
32-bit code, one for 64-bit code. At the end, you will have two
different binaries.



How is this handled by CMake ?


This is quite independent of CMake. It works with other build systems
like autotools/makefile as well.

CFLAGS=-m32 CXXFLAGS=-m32 tells CMake to pass the '-m32' to the C
and C++ compilers.
It tells the compiler to generate code that runs on any i386 system
(cf gcc manpage).

LDFLAGS=-melf_i386 tells CMake to pass the '-melf_i386' to the linker.
It tells the linker to use the i386 ELF format for the binary (cf ld manpage).

This works for GNU compiler/linker at least. I haven't tried other compilers.


Xavier
--

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
On Linux there is an application called linux32 that changes the way the 
os presents itself to an application. It will help the cmake modules 
make better decisions about the platform they are building on.


Hth,
Micha
--

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.8-3599-g078b8b1

2012-07-30 Thread Rolf Eike Beer
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  078b8b15f78e05f80b196c2f02405ff7137ba571 (commit)
   via  6c8722fab592ca63d0b85f86ec91ec75e6e66dea (commit)
   via  8baeeed109f2eb21e94b7ec7a0230030fa7e9a1c (commit)
  from  298ba6f12314e43af95ed9039b714a4157bfdd6d (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=078b8b15f78e05f80b196c2f02405ff7137ba571
commit 078b8b15f78e05f80b196c2f02405ff7137ba571
Merge: 298ba6f 6c8722f
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Mon Jul 30 02:09:03 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jul 30 02:09:03 2012 -0400

Merge topic 'directory-typo' into next

6c8722f Fix typo direcotry - directory (and similar) [#13444]
8baeeed CMake Nightly Date Stamp


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6c8722fab592ca63d0b85f86ec91ec75e6e66dea
commit 6c8722fab592ca63d0b85f86ec91ec75e6e66dea
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Mon Jul 30 08:08:33 2012 +0200
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Mon Jul 30 08:08:33 2012 +0200

Fix typo direcotry - directory (and similar) [#13444]

diff --git a/Modules/FindKDE3.cmake b/Modules/FindKDE3.cmake
index 9d10814..ca3dae6 100644
--- a/Modules/FindKDE3.cmake
+++ b/Modules/FindKDE3.cmake
@@ -131,7 +131,7 @@ ENDIF(KDECONFIG_EXECUTABLE)
 
 
 
-# at first the KDE include direcory
+# at first the KDE include directory
 # kpassdlg.h comes from kdeui and doesn't exist in KDE4 anymore
 FIND_PATH(KDE3_INCLUDE_DIR kpassdlg.h
   HINTS
diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
index 2f1708d..d157dab 100644
--- a/Modules/FindQt4.cmake
+++ b/Modules/FindQt4.cmake
@@ -70,7 +70,7 @@
 #  
 #  macro QT4_WRAP_CPP(outfiles inputfile ... OPTIONS ...)
 #create moc code from a list of files containing Qt class with
-#the Q_OBJECT declaration.  Per-direcotry preprocessor definitions 
+#the Q_OBJECT declaration.  Per-directory preprocessor definitions
 #are also added.  Options may be given to moc, such as those found
 #when executing moc -help.  
 #
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index fdc42fa..d841e41 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -1043,7 +1043,7 @@ int cmake::AddCMakePaths()
   {
   cMakeRoot = cMakeRoot.substr(0, slashPos);
   }
-// is there no Modules direcory there?
+// is there no Modules directory there?
 modules = cMakeRoot + /Modules/CMake.cmake;
 }
 
@@ -1072,7 +1072,7 @@ int cmake::AddCMakePaths()
 {
 // next try exe
 cMakeRoot  = cmSystemTools::GetProgramPath(cMakeSelf.c_str());
-// is there no Modules direcory there?
+// is there no Modules directory there?
 modules = cMakeRoot + /Modules/CMake.cmake;
 }
   if (!cmSystemTools::FileExists(modules.c_str()))
diff --git a/Utilities/cmlibarchive/libarchive/archive_read_disk_posix.c 
b/Utilities/cmlibarchive/libarchive/archive_read_disk_posix.c
index 7d7eeca..365a874 100644
--- a/Utilities/cmlibarchive/libarchive/archive_read_disk_posix.c
+++ b/Utilities/cmlibarchive/libarchive/archive_read_disk_posix.c
@@ -925,7 +925,7 @@ _archive_read_next_header2(struct archive *_a, struct 
archive_entry *entry)
if (fd  0)
tree_enter_working_dir(t);
 
-   /* The current direcotry fd is needed at
+   /* The current directory fd is needed at
 * archive_read_disk_entry_from_file() function to read link data
 * with readlinkat(). */
a-entry_wd_fd = tree_current_dir_fd(t);
diff --git a/Utilities/cmlibarchive/libarchive/archive_read_disk_windows.c 
b/Utilities/cmlibarchive/libarchive/archive_read_disk_windows.c
index d8a1f55..217a91a 100644
--- a/Utilities/cmlibarchive/libarchive/archive_read_disk_windows.c
+++ b/Utilities/cmlibarchive/libarchive/archive_read_disk_windows.c
@@ -955,7 +955,7 @@ _archive_read_disk_open_w(struct archive *_a, const wchar_t 
*pathname)
a-tree = tree_open(pathname, a-symlink_mode, a-restore_time);
if (a-tree == NULL) {
archive_set_error(a-archive, ENOMEM,
-   Can't allocate direcotry traversal data);
+   Can't allocate directory traversal data);
a-archive.state = ARCHIVE_STATE_FATAL;
return (ARCHIVE_FATAL);
}

---

Summary of changes:
 Modules/FindKDE3.cmake |2 +-
 Modules/FindQt4.cmake  |2 +-
 Source/CMakeVersion.cmake

[Cmake-commits] CMake branch, master, updated. v2.8.8-589-gaa3dbec

2012-07-30 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  aa3dbec57d07dd22718c3860d0c0e1b49f15a3ba (commit)
  from  8baeeed109f2eb21e94b7ec7a0230030fa7e9a1c (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=aa3dbec57d07dd22718c3860d0c0e1b49f15a3ba
commit aa3dbec57d07dd22718c3860d0c0e1b49f15a3ba
Author: Kitware Robot kwro...@kitware.com
AuthorDate: Tue Jul 31 00:01:12 2012 -0400
Commit: Kitware Robot kwro...@kitware.com
CommitDate: Tue Jul 31 00:01:12 2012 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index b0cd277..a137de3 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 8)
-SET(CMake_VERSION_TWEAK 20120730)
+SET(CMake_VERSION_TWEAK 20120731)
 #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