Re: [cmake-developers] [CMake] xcode project and static library dependencies

2011-02-20 Thread Johan Björk
Hi Nick,

Any updates on this patch?

Cheers
/Johan


On Thu, Jan 20, 2011 at 2:08 AM, Nick Kledzik kled...@apple.com wrote:

 
  BTW, it might make more sense to move this to the cmake-developers
 mailing list.
 
 I've transfered this thread to the developer list.  See below for
 continuation..


 On Jan 18, 2011, at 12:42 PM, Bill Hoffman wrote:

  On 1/18/2011 2:40 PM, Brad King wrote:
  On 1/18/2011 2:12 PM, Nick Kledzik wrote:
  When I use cmake to create a Makefile, the resulting main executable
  is placed in the build directory tree next to the Makefile.
 
  This is where CMake puts files in single-configuration generators.
 
  When I use cmake to create a xcode project, the resulting main
  executable is placed  in a subdirectory named Debug of the build
  directory tree.
 
  This is where CMake puts files in multi-configuration generators.
 
  Both of the above are expected default behaviors.  Both can be
  changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and
  its per-configuration equivalent.  All CMake generators must
  honor these.
 
  None of these locations are the native location
  where Xcode would put a build result.
 
  Xcode has settings like CONFIGURATION_BUILD_DIR to control
  where the build outputs go.  This already works.  Is there
  some reason your changes cannot use these?
 
  My understanding is that the main problem with the current generator
  is all the extra build phases and OTHER_LDFLAGS stuff used to deal
  with link line ordering and static libraries.  This is what Bill
  summarized:
 
  On 1/13/2011 3:41 PM, Bill Hoffman wrote:
  - have a static library show up more than once on a link line
  - be able to specify the order of static libraries on the link line
  - be able to relink and executable when a static library that it
  depends on is rebuilt.
 
  I'm more interested in a solution to implementation issues like these
  than in interface details like where output files go.
 
  -Brad
 
  So, for Xcode and VS IDE, CMake will place things in directories like
 Debug, Release.
 
  For example, you should get something like this:
 
  ${RUNTIME_OUTPUT_DIRECTORY}/Debug/myexe
 
  Xcode does support building multiple configurations like Debug, Release,
 etc.  Where is the native location for those files?
 As I said, it is per-user xcode settings.  You cannot infer the location
 from source tree cmake has access to.

 At build time, the location is known within xcode.  So, I added a copy-file
 phase to have xocde copy the resulting binary from the native location to
 the standard location the cmake expects.  There is little overhead for this.

 I've now have a patch which:
 1) preserves link order
 2) builds libraries into the xcode native location
 4) removes pre and post shell script phases previously used to fix
 dependency problems
 3) xcode projects now have proper dependencies

 WIth this cmake patch, I can build CMake.xcodeproject, open it in xcode,
 build-all, set the current target to be cmake, make a source change, hit
 build, and have xcode just compile that one file, re-archive the library,
 then re-link cmake tool.  I also debugged all this in Xcode by setting
 arguments for the cmake tool and hitting the build-and-debug within xcode!

 Attached is the patch from cmake-2.8.3 sources:



 This cmake also creates an xcode project that builds LLVM.  It is still not
 quite optimal because there are a bunch of cases where custom rules cause a
 custom make file to be generated which is executed from within xcode via a
 shell script phase.  Xcode does not now which files the script might modify,
 so xcode has to be conservative and re-check all timestamps.  There are ways
 to add custom scripts with specified input and output files in xcode.  I may
 get to fixing that someday...


 How does one run the test suite?  I saw the instructions about building
 cmake for make, then executing make Experimental.  I did that and all 184
 or 184 tests passed.  But it looks like this is running the cmake generated
 makefiles - not cmake generated xcode projects.

 -Nick








 ___
 cmake-developers mailing list
 cmake-developers@cmake.org
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[cmake-developers] Fwd: [CMake] CTest GIT support does not properly update recursive submodules

2011-02-20 Thread Johan Björk
missed the list. attached patch.


-- Forwarded message --
From: Johan Björk p...@spotify.com
Date: Sun, Feb 20, 2011 at 5:28 PM
Subject: Re: [CMake] CTest GIT support does not properly update recursive
submodules
To: Brad King brad.k...@kitware.com


Hi Brad,

Attached a small patch for --recursive support.

/Johan

On Fri, Feb 18, 2011 at 5:18 PM, Brad King brad.k...@kitware.com wrote:

 On 02/18/2011 10:00 AM, Johan Björk wrote:
  On Mon, Feb 7, 2011 at 7:14 PM, Brad King wrote:
  (1) Hard-code --recursive and add a check to error out if the Git
  version is not new enough.
 
  (2) seems both complicated and confusing for end users. I would vote for
  (1) as if someone updates to the latest CMake on their machine, they
  shouldn't have any issues in upgrading the git version in use.

 Basically this says that CTest will support only Git 1.6.5 or higher
 even for projects that have no submodules at all, let alone recursive
 ones, and even though it would work fine were it not for this option.

 Perhaps instead we should detect whether any submodules are present
 (e.g. is the .gitmodules file present at the top) and only enforce
 the version number in that case.  Do you mind working on a patch for
 this please?

 Thanks,
 -Brad



0001-CTest-git-Use-recursive-with-gitsubmodule-support.-B.patch
Description: Binary data
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[cmake-developers] ninja on Windows

2011-02-20 Thread Peter Kümmel

Here is a very first shot of ninja on Windows:

  https://github.com/syntheticpp/ninja/tree/qprocess

Sorry, it links against Qt, but the original code depends
on fork() and Qt was the fastest way to get ninja running
on Windows.

Maybe there are big show-stopper bugs, but
misc/long-slow-build.ninja runs nice in the debugger,
so it will not hard to fix other bugs.

I've tested it with mingw 4.4 and msvc10. I assume
MSVC 2008 will also work when tr1 is installed (hash_map).

Precompiled packages of Qt for mingw (SDK also incudes mingw)
and MSVC 2008 could be downloaded from:

  http://qt.nokia.com/downloads

Cheers,
Peter
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers