[CMake] macosx fix bundle problems
hi all, I have a Qt4 application with bundle build support taken from cmake wiki example. When I run "deploy" phase with make install, the correct structure is created in CMAKE_INSTALL_PREFIX. But it looks like cmake's fixup_bundle function from BundleUtilities does its job only partially. All Qt frameworks are fixed correctly to use @executable_path, but the main binary still contains links to my development environment. What could be the issue? thanks, Petr Vanek code: http://tora.svn.sourceforge.net/viewvc/tora/trunk/tora/ 1st make install run: rimmer:build-bundle pvanek$ make install [ 1%] Built target tora_loki_lib [100%] Built target tora Install the project... -- Install configuration: "RELEASE" Removing Previous TOra.app bundle at /Users/pvanek/oss/tora/bundle/ Copying TOra.app from the build tree to /Users/pvanek/oss/tora/bundle/ -- fixup_bundle -- app='/Users/pvanek/oss/tora/bundle/TOra.app' -- libs='' -- dirs='Plugins' -- warning: *NOT* handled - .app directory case... -- error: fixup_bundle: not a valid bundle -- fixup_bundle: done CMake Warning (dev) at cmake_install.cmake:31 (INCLUDE): Policy CMP0011 is not set: Included scripts do automatic cmake_policy PUSH and POP. Run "cmake --help-policy CMP0011" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The included script /Users/pvanek/oss/tora/trunk/tora/build-bundle/ TOra_OSX_MakeStandAloneBundle.cmake affects policy settings. CMake is implying the NO_POLICY_SCOPE option for compatibility, so the effects are applied to the including context. This warning is for project developers. Use -Wno-dev to suppress it. -- Installing: /Users/pvanek/oss/tora/bundle/tora.app -- Installing: /Users/pvanek/oss/tora/bundle/tora.app/Contents -- Installing: /Users/pvanek/oss/tora/bundle/tora.app/Contents/ Info.plist -- Installing: /Users/pvanek/oss/tora/bundle/tora.app/Contents/MacOS -- Installing: /Users/pvanek/oss/tora/bundle/tora.app/Contents/MacOS/ tora -- Installing: /Users/pvanek/oss/tora/bundle/tora.app/Contents/Resources -- Installing: /Users/pvanek/oss/tora/bundle/tora.app/Contents/ Resources/tora.icns 2nd make install rimmer:build-bundle pvanek$ make install [ 1%] Built target tora_loki_lib [100%] Built target tora Install the project... -- Install configuration: "RELEASE" Removing Previous TOra.app bundle at /Users/pvanek/oss/tora/bundle/ Copying TOra.app from the build tree to /Users/pvanek/oss/tora/bundle/ -- fixup_bundle -- app='/Users/pvanek/oss/tora/bundle/TOra.app' -- libs='' -- dirs='Plugins' -- fixup_bundle: preparing... -- fixup_bundle: copying... -- 1/28: *NOT* copying '/Users/pvanek/oss/tora/bundle/TOra.app/ Contents/MacOS/tora' -- 2/28: copying '/opt/local/lib/libcrypto.0.9.8.dylib' -- 3/28: copying '/opt/local/lib/libpng12.0.dylib' -- 4/28: copying '/opt/local/lib/libssl.0.9.8.dylib' -- 5/28: copying '/opt/local/lib/libz.1.dylib' -- 6/28: copying '/opt/local/lib/oracle/libclntsh.dylib.10.1' -- 7/28: copying '/opt/local/lib/oracle/libocci.dylib.10.1' -- 8/28: copying '/opt/local/lib/postgresql83/libpq.5.dylib' -- 9/28: copying '/opt/local/libexec/qt4-mac/lib/QtCore.framework/ Versions/4/QtCore' -- 10/28: copying '/opt/local/libexec/qt4-mac/lib/QtGui.framework/ Versions/4/QtGui' -- 11/28: copying '/opt/local/libexec/qt4-mac/lib/QtNetwork.framework/ Versions/4/QtNetwork' -- 12/28: copying '/opt/local/libexec/qt4-mac/lib/QtSql.framework/ Versions/4/QtSql' -- 13/28: copying '/opt/local/libexec/qt4-mac/lib/QtXml.framework/ Versions/4/QtXml' -- 14/28: copying '/opt/local/libexec/qt4-mac/lib/ libqscintilla2.5.dylib' -- fixup_bundle: fixing... -- 15/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/ MacOS/tora' -- 16/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/ Libraries/libcrypto.0.9.8.dylib' -- 17/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/ Libraries/libpng12.0.dylib' -- 18/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/ Libraries/libssl.0.9.8.dylib' -- 19/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/ Libraries/libz.1.dylib' -- 20/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/ MacOS/libclntsh.dylib.10.1' -- 21/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/ MacOS/libocci.dylib.10.1' -- 22/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/ Libraries/libpq.5.dylib' -- 23/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/ Frameworks/QtCore.framework/Versions/4/QtCore' -- 24/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/ Frameworks/QtGui.framework/Versions/4/QtGui' -- 25/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/ Frameworks/QtNetwork.framework/Versions/4/QtNetwork' -- 26/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/ Frameworks/QtSql.framework/Versions/4/QtSql' -- 27/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.ap
Re: [CMake] add_custom_command using CMAKE_CXX_FLAGS
Alexander Neundorf wrote: On Monday 24 August 2009, John Smith wrote: [...] I have tried doing that. [...] So you have also hit that bug ? http://public.kitware.com/Bug/view.php?id=8392 Interesting, did not know of it. IMHO, I believe that the C compiler (or C compiler driver) should be invoked on the assembly sources, with the exact definitions and C compiler flags that are set at that point in the processing of the source tree. The reason for that is definitions may be involved in pre-processing the source file as conditionals guarding include directives, etc. and flags may alter the code generation, e.g., -m32 may be used to generate x86 code. If CMake has the concept of a settable "default" language/compiler per project then perhaps that default compiler -- be it C or C++ -- might be the perfect choice for building the project's assembly files. The C compiler would use the compile definitions and C flags, whereas the C++ compiler would use the same definitions but CXX flags. I.e., not hard-coding the C compiler in might be a better choice. Of course, I might be wrong, and I invite others to state their opinions on this. gcc -- per the man page -- does not preprocess .s files but it does so for .S files, when invoked for compilation. With this behavior, I believe gcc is unique. Other compilers which I believe know automagically what to do with .s assembly sources are: 1. HP aCC at http://tinyurl.com/nhr97k : Assembly language source files (.s files) Files with names ending in .s are assumed to be assembly source files. The compiler invokes the assembler through cc to produce .o files from these. 2. IBM VisualAge for C++ at http://tinyurl.com/l2lqt4 : Assembler files Assembler files must have a .s suffix, for example, file_name.s, unless you compile with the -qsourcetype=assembler option. Assembler files are assembled to create an object file. 3. Sun's Sun Studio at http://tinyurl.com/ma6etm : The syntax of the cc command is: % cc [options] filenames [libraries]... [...] Use the C compiler to compile and link any combination of the following: [...] o Assembler source files, with .s suffixes 4. Intel C++ at http://tinyurl.com/6lxedl : The Intel® C++ Compiler recognizes input files with the extensions listed in the following table: [...] file.s | Assembly file| Passed to assembler Can you please try the attached patch ? Sure thing, I will. Thanks! ___ 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] dependency in custom command?
On Friday 28 August 2009, King, Steven R wrote:
> Hello List,
> I'm new to cmake and liking it a lot. I'm using cmake 2.6.3 on Linux.
>
> I'm building a dynamically loadable module and an executable to test it.
> Each lives in a different directory. My test program needs to know the
> location of the dll when calling dlopen(). To solve this, I created a
> custom command to copy the dll to the binary directory of the test program.
> This works, but I have an annoying dependency problem. Specifically, if
> the dll gets rebuilt, the copy command does not execute. The copy command
...
> # Create a custom build step to copy the dynamically loaded .so file
> # into the this directory so our test executable can find it.
> add_custom_command(
> TARGET test_my_module
> POST_BUILD
> DEPENDS my_module # no effect?
> COMMAND ${CMAKE_COMMAND} -E copy ${SO_LOCATION}
> ${CMAKE_CURRENT_BINARY_DIR} COMMENT "CUSTOM COMMAND: Copy my_module to
> build directory" )
>
>
> What should I do make the copy happen if the dll is rebuilt?
I must be missing something, but can't you assign the custom command to the
module instead to the executable ?
add_custom_command(TARGET my_module
POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy ${SO_LOCATION}
${CMAKE_CURRENT_BINARY_DIR}
)
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] dependency in custom command?
On Friday 28 August 2009, King, Steven R wrote:
> > You don't need to do this. Since "my_module" is a CMake target, you can
> > just use "my_module" instead of ${SO_LOCATION} in the custom_command
> > below and CMake will figure out where the .so is on the disk>
>
> Hi Tyler -- Substituting my_module did not work. The copy fails. Is this
> a cmake bug?
AFAIK this works only for the executable which is called by COMMAND:
add_custom_command ( ... COMMAND ... )
So, it's not a bug, this feature does not exist.
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] add_custom_command using CMAKE_CXX_FLAGS
On Monday 24 August 2009, John Smith wrote:
> On Aug 24, 2009, at 12:48 PM, Tyler Roscoe wrote:
> > On Sun, Aug 23, 2009 at 09:03:22PM -0400, John Smith wrote:
> >> I am using the following test case in an attempt to add a custom
> >> command to build an assembly file. The assembly file should be
> >> compiled with the C++ compiler driver (which in turn should invoke
> >> the
> >> assembler after pre-processing), and I am building up a
> >> CMAKE_CXX_FLAGS variable from separate pieces:
> >
> > I think you can just hand your .S files to add_library(). Did you try
> > searching the ML archives or google for how to handle assembler files
> > with CMake?
>
> I have tried doing that. However, the net end result is that I get a
> rule that invokes the assembler on the assembly source file. My top-
> level assembly source file is a shell containing a bunch of platform-
> specific conditionals, which in turn guard include directives for
> platform-specific assembly source files.
So you have also hit that bug ?
http://public.kitware.com/Bug/view.php?id=8392
Can you please try the attached patch ?
It introduces a language "ASM-GCC" and removes the extension ".S" from the
normal assembler support.
Can you please give it a try ?
Is it only gcc which supports processing assembler files or do other compilers
also support this ?
Alex
Index: Modules/CMakeASM-ATTInformation.cmake
===
RCS file: /cvsroot/CMake/CMake/Modules/CMakeASM-ATTInformation.cmake,v
retrieving revision 1.2
diff -b -u -p -r1.2 CMakeASM-ATTInformation.cmake
--- Modules/CMakeASM-ATTInformation.cmake 5 Nov 2008 23:51:46 - 1.2
+++ Modules/CMakeASM-ATTInformation.cmake 8 Mar 2009 19:35:15 -
@@ -1,6 +1,6 @@
# support for AT&T syntax assemblers, e.g. GNU as
SET(ASM_DIALECT "-ATT")
-SET(CMAKE_ASM${ASM_DIALECT}_SOURCE_FILE_EXTENSIONS s;S;asm)
+SET(CMAKE_ASM${ASM_DIALECT}_SOURCE_FILE_EXTENSIONS s;asm)
INCLUDE(CMakeASMInformation)
SET(ASM_DIALECT)
Index: Modules/CMakeASM-GCCInformation.cmake
===
RCS file: Modules/CMakeASM-GCCInformation.cmake
diff -N Modules/CMakeASM-GCCInformation.cmake
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Modules/CMakeASM-GCCInformation.cmake 8 Mar 2009 19:35:15 -
@@ -0,0 +1,9 @@
+# support for AT&T syntax assemblers with C preprocessing
+
+SET(ASM_DIALECT "-GCC")
+
+SET(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT " -c -o ")
+
+SET(CMAKE_ASM${ASM_DIALECT}_SOURCE_FILE_EXTENSIONS s;S;asm)
+INCLUDE(CMakeASMInformation)
+SET(ASM_DIALECT)
Index: Modules/CMakeDetermineASM-GCCCompiler.cmake
===
RCS file: Modules/CMakeDetermineASM-GCCCompiler.cmake
diff -N Modules/CMakeDetermineASM-GCCCompiler.cmake
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Modules/CMakeDetermineASM-GCCCompiler.cmake 8 Mar 2009 19:35:15 -
@@ -0,0 +1,6 @@
+# determine the compiler to use for ASM using AT&T syntax, e.g. GNU as
+
+SET(ASM_DIALECT "-GCC")
+SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_INIT ${_CMAKE_TOOLCHAIN_PREFIX}gcc ${_CMAKE_TOOLCHAIN_PREFIX}cc )
+INCLUDE(CMakeDetermineASMCompiler)
+SET(ASM_DIALECT)
Index: Modules/CMakeTestASM-GCCCompiler.cmake
===
RCS file: Modules/CMakeTestASM-GCCCompiler.cmake
diff -N Modules/CMakeTestASM-GCCCompiler.cmake
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Modules/CMakeTestASM-GCCCompiler.cmake 8 Mar 2009 19:35:15 -
@@ -0,0 +1,10 @@
+
+# This file is used by EnableLanguage in cmGlobalGenerator to
+# determine that that selected ASM-ATT compiler can actually compile
+# and link the most basic of programs. If not, a fatal error
+# is set and cmake stops processing commands and will not generate
+# any makefiles or projects.
+
+SET(ASM_DIALECT "-GCC")
+INCLUDE(CMakeTestASMCompiler)
+SET(ASM_DIALECT)
Index: Source/cmLocalUnixMakefileGenerator3.cxx
===
RCS file: /cvsroot/CMake/CMake/Source/cmLocalUnixMakefileGenerator3.cxx,v
retrieving revision 1.262
diff -b -u -p -r1.262 cmLocalUnixMakefileGenerator3.cxx
--- Source/cmLocalUnixMakefileGenerator3.cxx 24 Feb 2009 20:37:09 - 1.262
+++ Source/cmLocalUnixMakefileGenerator3.cxx 8 Mar 2009 19:35:17 -
@@ -1528,7 +1528,7 @@ cmLocalUnixMakefileGenerator3
// Create the scanner for this language
cmDepends *scanner = 0;
-if(lang == "C" || lang == "CXX" || lang == "RC")
+if(lang == "C" || lang == "CXX" || lang == "RC" || lang == "ASM-GCC")
{
// TODO: Handle RC (resource files) dependencies correctly.
scanner = new cmDependsC(this, targetDir, lang.c_str());
___
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
Re: [CMake] macport issue?
On Sep 5, 2009, at 15:18 , Bill Hoffman wrote: I found this with a google alert: http://www.nabble.com/-MacPorts---21120:-Cmake-fails-to-sync--or-bootstrap--Not-sure-what-it-trying-to-say-sorry.-td25310279.html Is there anyone on this list that is having this problem with CMake? I recently built cmake 2.6.4 under MacPorts 1.8.0 in Snow Leopard and had no issue. He's using a very old version of XCode and OS X Tiger though ... 2.2.1 and 10.4.11 respectively. Stephen ___ 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] macport issue?
I found this with a google alert: http://www.nabble.com/-MacPorts---21120:-Cmake-fails-to-sync--or-bootstrap--Not-sure-what-it-trying-to-say-sorry.-td25310279.html Is there anyone on this list that is having this problem with CMake? -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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CHECK_CXX_SOURCE_COMPILES attempts linking
Alexander Neundorf wrote: On Thursday 03 September 2009, John Smith wrote: It seems that CHECK_CXX_SOURCE_COMPILES attempts to link the object files into an executable: Yes. Sometimes having it only compile but not link would be nice, but that's not the case. So, this is not by design, instead it is an artifact of the implementation? You can specifiy libraries to link to, so it should be possible to get it linking. That is true. But what is the obstacle to implementing the macro such that it just does compilation (as the name suggests) and not compilation and linking? Thanks! ___ 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] CHECK_CXX_SOURCE_COMPILES attempts linking
On Saturday 05 September 2009, you wrote: > Alexander Neundorf wrote: > > On Thursday 03 September 2009, John Smith wrote: > >> It seems that CHECK_CXX_SOURCE_COMPILES attempts to link the object > >> files into an executable: > > > > Yes. Sometimes having it only compile but not link would be nice, but > > that's not the case. > > So, this is not by design, instead it is an artifact of the implementation? > > > You can specifiy libraries to link to, so it should be possible to get it > > linking. > > That is true. But what is the obstacle to implementing the macro such > that it just does compilation (as the name suggests) and not compilation > and linking? (without checking) I think it creates a small project, where the CMakeLists.txt uses add_executable(). This links. There is not cmake command which only compiles, but not links. add_library(STATIC) may be close. 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] Create libtool file
On Tuesday 11 August 2009, Pau Garcia i Quiles wrote: > Hello, > > I'm converting to CMake a library ( > http://sourceforge.net/projects/wvware/ ) which creates a libtool. > While in this, I'm improving the CREATE_LIBTOOL_FILE macro ( > http://www.cmake.org/Wiki/CMakeMacroLibtoolFile ). The next thing I'd > like to add is autogeneration of the LT_DEPENDENCY_LIBS variable. > After all, it's essentially the same information we pass to > TARGET_LINK_LIBRARIES. > > Currently, I only know to ways to set this variable and both of them > require setting the same information twice: > > - Manually, by repeating the information passed to > TARGET_LINK_LIBRARIES. Problem is those "optimized", "debug", > "general" keywords require some parsing to remove them. > > - Automatically, by using LINK_INTERFACE_LIBRARIES in > TARGET_LINK_LIBRARIES, then repeating the same information in a > SET_TARGET_PROPERTIES( LINK_INTERFACE_LIBRARIES ... ) and getting it I think it's not necessary to repeat that with the SET_TARGET_PROPERTIES() call, GET_TARGET_PROPERTY() should work also without that. You may also have a look at the _LIB_DEPENDS variables. 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] Get all required shared libs from a target
On Friday 28 August 2009, Michael Jackson wrote: > If you pull the boost 1.39.0 sources there is an experimental CMake > based build system. In those cmake files the developers have somehow > figured out how to do what you want. For a given library, you can get > all the dependencies. Maybe you can file a feature request, so that you can do get_target_properties(libs yourlib LINK_INTERFACE_LIBRARIES) works if you have set LINK_INTERFACE_LIBRARIES using TARGET_LINK_LIBRARIES(... LINK_INTERFACE_LIBRARIES) If you haven't done that, it returns NOTFOUND. Maybe you could file a feature request that get_target_property( LINK_INTERFACE_LIBRARIES) should return the full set of linked libraries (which will be the link interface libraries) if LINK_INTERFACE_LIBRARIES has not explicitely been set. For libraries you can also have a look at the _LIB_DEPENDS variable, maybe that helps. 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] Unknown origin of compiler flag on Cray
On Thursday 27 August 2009, Will Dicharry wrote:
> Hi All,
>
> I am experiencing a strange problem on Cray XT machines running CNL
> compute nodes with the PGI compiler.
>
> It appears that something is adding the flags "-Bstatic -Bdynamic" (in
> that order) to the link line. It looks like the Linux.cmake platform
> module sets the the variable CMAKE_${type}_DYNAMIC_C_FLAGS to -Bdynamic.
>But that's the only reference to the flags that I can find anywhere
> in the project.
Linux.cmake also adds the Bstatic (at least with CVS head).
I didn't try, can you just change these variables ?
> The cache does not contain the flags, my list files do not contain the
> flags, and as far as I can tell, none of the modules I am using add the
> flags (the only modules I call are a custom exodus find module, a custom
> netcdf find module, and the HDF5 find module I submitted earlier this
> week). Also, all of the libraries built by my projects and the
> libraries found by cmake with find_package are static.
>
> The flags are causing problems because we use the Cray provided wrapper
> compilers, which add a few additional libraries to the link line, and
I think you don't have to use these compiler wrappers, it should work if you
use the plain compiler (worked for me).
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] [PATCH] slightly modify cache variable behaviour, Was: Re: option() behavior
On Sunday 28 June 2009, Alexander Neundorf wrote: > On Tuesday 12 May 2009, Philip Lowman wrote: > > On Mon, May 11, 2009 at 4:53 PM, Alexander Neundorf > > > > > > wrote: > > > > > > On Monday 11 May 2009, Bill Hoffman wrote: > > > > Alexander Neundorf wrote: > > > > > On Monday 11 May 2009, Bill Hoffman wrote: > > > > >> So, CMake has done what it does now from the start. There was a > > > > > > short > > > > > > > >> period of time when it did not, and that was when a re-write was > > > > >> done, and it quickly broke some existing projects. Here is the > > > > >> thread: > > > > > > > > > > Yes, I can imagine that. > > > > > Still the current behaviour is not very intuitive, especially that > > > > > set(CACHE) in the first cmake run overrides the "visible" variable, > > > > > > while > > > > > > > > the set(CACHE) in the second run basically does nothing, and so the > > > > > > value > > > > > > > > of the "visible" variable is different. > > > > > I think for CMake 2.8 or 3.0 it would be a good idea to make this > > > > > more consistent and easier to understand (especially since now more > > > > > and more people are using cmake). > > > > > > > > > >> http://www.cmake.org/pipermail/cmake/2007-March/013204.html > > > > >> > > > > >> I think the rule should be if you want to change a variable you > > > > >> have > > > > > > to > > > > > > > >> have the set AFTER the variable, or use CACHE INTERNAL. > > > > > > > > > > What do you mean exactly with "have the set after the variable" ? > > > > > Have the set(FOO ) after the set(FOO CACHE), or > > > > > > something > > > > > > > > else ? > > > > > > > > Yes, > > > > > > > > This always has worked as expected: > > > > > > > > set(FOO 2 CACHE) > > > > set(FOO 1) # this is always the value > > > > > > > > However, I think your change is OK. Basically if the set CACHE comes > > > > after the set, it will always set the value. We do need a policy > > > > for this, but it should be easy to detected. You will have to see if > > > > the REMOVE is going to do anything.I wonder how many warnings > > > > that policy will cause... I guess we could create the policy code, > > > > and try it on VTK, Boost, SecondLife, and some other big projects to > > > > see what happens... > > > > > > Ok, I put it on my TODO, then we'll see what (would) happen. > > > > I'll be happy to test it out on our build system at work as well. > > > > I never thought to do anything crazy like define a local variable before > > a cache variable until CMakePorts... so I don't think this is going to > > impact us at all and I suspect it probably won't affect others much > > either. Wrapping the cache and option declarations with if(DEFINED...) is > > no big deal. > > The patch attached at http://public.kitware.com/Bug/view.php?id=9008 > implements this changed behaviour, together with a new cmake policy CMP0014 > (OLD behaviour: ignore the value in the cache if the variable has been > already set, new behaviour: set the variable to the value from the cache) > > The cmake tests are all succeeding, and I'm also building kdelibs without > problems with this patch. > > If you think it's ok I can commit it to HEAD. Any comments on this one ? If this should get in, I think it should be done before 2.8.0. I'm using cmake built with this patch since June and didn't notice any issues. 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] out of source command line flag
2009/9/5 Alexander Neundorf : > On Saturday 05 September 2009, Eric Noulard wrote: [...] >> E3) One gives a build tree which does not correspond to the given source >> tree This is easy to check because CMakeCache.txt contains >> _SOURCE_DIR >> >> If this appear CMake should abort and send a message telling >> the source tree/build tree mismatch. > > I think it could be easier than that. > E1) none of the two directories contains a CMakeLists.txt > E2) both directories contain a CMakeLists.txt > > In all other case, one directory contains a CMakeLists.txt, this is the source > dir. The other directory does not contain a CMakeLists.txt, so it is not a > source dir. It may contain a CMakeCache.txt, then it is already a build dir. > If it does not, it will become the build dir. Fair enough, my tortuous mind was tracking the build tree yours is tracking the source tree, this is obviously a better choice. My E3) case still remains, you really don't want to mess-up an existing build tree with a unrelated source tree. I know however that my proposal does not solve the other problem regarding ignoring "" raised in this thread. Moreover the problem raised by Alan: "If you would prefer not to have policy about this issue, is there some technical means of detecting when the cmake invocation directory is not the same as the build directory? The combination of cmake invocation directory != build directory AND build_directory == source directory is the one I want to avoid (by erroring out with appropriate message) since that is the combination that appears to get newbies into trouble." is important to me too. In the current one arg cmake invocation we should have a way to detect/avoid an unvoluntary in-source build. Currently we cannot. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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] Finding X11 fails under OS X...
On Thursday 03 September 2009, Georgios Petasis wrote: ... > No I don't. In fact there is only a .la file all X11 libraries, besides > the version-coded .dylib files. The only places that there .dylib files > without version (along with the versioned ones) is inside the SDK > folders, which are not considered at all by cmake. In which directories are the libraries/headers located in the SDK ? Maybe these directories should be added to the search paths in FindX11.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] CHECK_CXX_SOURCE_COMPILES attempts linking
On Thursday 03 September 2009, John Smith wrote: > It seems that CHECK_CXX_SOURCE_COMPILES attempts to link the object > files into an executable: Yes. Sometimes having it only compile but not link would be nice, but that's not the case. You can specifiy libraries to link to, so it should be possible to get it linking. Or just add an empty main() ? 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] Unknown names of output files - How to add the dependency?
On Thursday 03 September 2009, Swaroop Ramachandra wrote: > Hi, > I have a question regarding the ADD_CUSTOM_COMMAND. I have an input file > which is generated on the fly. My ADD_CUSTOM_COMMAND executes a binary file > which takes this input file. My output is a set of files whose names are > based on the contents of my input file. Specifically, I generate ".c" files > on execution of the binary and the names of the ".c" files generated is not > known in advance. > > In the above case, how can I specify a set of output files since I do not > know the names of these files before hand? I think this is a problem. Is there really no way you can calculate the names beforehand ? Can you maybe generate an additional file, where you know the name and use that as dependency or something like that ? 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] out of source command line flag
On Saturday 05 September 2009, Eric Noulard wrote: > Continued ... > CMake may guess which one is the build tree using this algorithm. > > 1) If there is a CMakeCache.txt in the dir then this is a build tree > 2) If the path does not exists then this is a "to be created" build tree > > error cases are: > > E1) One gives two existing dir with none containing a CMakeCache.txt > ==> send an error message explaining that and abort. > > E2) One gives two directories > E21) both contains a CMakeCache.txt > or E22) one contains a CMakeCache.txt and the other does not exists. > > E21 is plain wrong > E22 the source tree may have been polluted with a previous > in-source config. > > E3) One gives a build tree which does not correspond to the given source > tree This is easy to check because CMakeCache.txt contains > _SOURCE_DIR > > If this appear CMake should abort and send a message telling > the source tree/build tree mismatch. I think it could be easier than that. E1) none of the two directories contains a CMakeLists.txt E2) both directories contain a CMakeLists.txt In all other case, one directory contains a CMakeLists.txt, this is the source dir. The other directory does not contain a CMakeLists.txt, so it is not a source dir. It may contain a CMakeCache.txt, then it is already a build dir. If it does not, it will become the build dir. 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] out of source command line flag
Am Samstag 05 September 2009 16:59:09 schrieb Bill Hoffman: > I use this all the time, and so do lots of people that I know. They do > this: > > cmake . I also use this. But being able to force a specific build dir (instead of cmake trying to be smart) may be a good thing, like ignoring the in-source build files. It may cause other problem though, like "-I -I" and a generated header file. HS ___ 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 Python support
On Wednesday 26 August 2009, Matt McCormick wrote: > Andreas Pakulat writes: > > On 19.08.09 08:34:26, Philip Lowman wrote: > > > Speaking of the existing FindPython* scripts they do not support v3.0 > > > yet. Is there a need to maintain support for picking 2.x if two > > > versions of python are installed? > > > > As Py2 and Py3 are basically incompatible IMHO A separate FindPython3 > > would be better than letting the module try to "guess" py2 vs. py3 if > > both are installed. The project using Python should have decide on wether > > it works with Py3 or not. > > > > Andreas > > Python 2.X are also incompatible with each other sometimes, and a user can > have multiple 2.X and 3.X installed. IMHO, having different modules for > every version is not the write way to go. Just make it a configuration > variable in FindPythonLibs.cmake This may become messy. I agree with Andreas that having a separate module for Python3 would be better. Since they are not compatible, I don't see a reason why one module should search for both. 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] Finding Qt4 binaries under Windows
On Saturday 22 August 2009, Sebastian Schuberth wrote: > On 21.08.2009 22:22, Michael Jackson wrote: > > YOU are the one who compiled it in C:\Qt\4.5.1 according to your > > original post. I am simply making you aware of the error. > > Well, I specified "C:/Qt" instead of "C:/Qt/4.5.1" on purpose. The point > is: I have compiled Qt myself, and not used the installer, thus there > are no registry keys and qmake is not in my PATH. So it's clear that > CMake cannot find my Qt installation without any hints from my side. > On the other hand, I want my CMakeLists.txt file to be as generic as > possible, and not mention any version specific directories. As it's sort > of common for people to have Qt installed beneath "C:/Qt" on Windows, I > thought it might be possible to instruct find_package() to recursively > search for Qt / qmake starting at "C:/Qt". > > > So, if you compiled to C:\Qt\4.5.1 then you have a couple of options: > > > > set QTDIR to C:\Qt\4.5.1 in the environment variables. > > > > OR > > > > find_package(Qt4 PATHS "C:/Qt/4/.5.1") like Pau suggested. > > > > If you don't like the version number on there then recompile Qt 4.5.1 so > > that it has a path of C:\Qt and NOT C:\Qt\4.5.1 > > > > Understand? > > Yes, I perfectly understand, it's just not what I want, and I'm a little > disappointed how limited find_package(Qt4) seems to be. > > There is not need to recompile Qt in order to make it available at > "C:/Qt" instead of "C:/Qt/4.5.1", I just would have to move the files. > But like I said, the default install location for Qt on Windows is > "C:/Qt/", and this is what e.g. the PDB files expect when > debugging Qt in Visual Studio. > > But just for the fun of it, I also tried Pau's > > find_package(Qt4 PATHS "C:/Qt/4.5.1") If you use PATHS, cmake looks for a Qt4Config.cmake file, which does not exist. So don't use PATHS or HINTS, just do: find_package(Qt4) (maybe add the REQUIRED keyword). This will load FindQt4.cmake. FindQt4.cmake then tries to find qmake. This is where you can help. There are multiple options: execute cmake from an environment where PATH points to the directory where qmake is: 1) $ export PATH=/opt/qt451/bin:$PATH $ cmake 2) run it from an environment where the env. var. CMAKE_PREFIX_PATH points to the base install directory of Qt: $ export CMAKE_PREFIX_PATH=/opt/qt451:$CMAKE_PREFIX_PATH $ cmake 3) set CMAKE_PREFIX_PATH (the cmake variable) from the command line (via -D) or in the CMakeLists.txt, e.g.: set(CMAKE_PREFIX_PATH /opt/qt451) find_package(Qt4) 4) set QT_QMAKE_EXECUTABLE directly, as Pau suggested 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] out of source command line flag
On 2009-09-05 10:59-0400 Bill Hoffman wrote: Alan W. Irwin wrote: On 2009-09-05 09:38+0200 Hendrik Sattler wrote: The problem with how giving the build-dir/source-dir to cmake is currently too much dependent on other conditions: cmake [options] cmake [options] The first only is true if no CMakeCache.txt exists there. This was actually a bad choice to have that as only possibility. Being able to do an out-of-source build even if there was a previous in-source build would be much appreciated. I second that motion to drop the interpretation (subject to policy protection, of course, assuming there is at least some legitimate use case for .) CMake newbie's natural tendency seems to be to try an in-source build first. Thus, I cannot count how many times PLplot and FreeEOS users out-of-source build experience has been silently messed up by their first build attempt which was in source. I have never heard of users actually using the interpretation except by mistake. However, assuming there is some legitimate use case, I suggest you make a POLICY to drop the interpretation. I would be happy to adopt such a policy for my different software projects simply to drop the volume of necessary advice to first-time users who keep falling into the trap of using by mistake. I use this all the time, and so do lots of people that I know. They do this: cmake . Well, I have a modern shell (bash) with quick access (up arrow or "!cmake") to previous commands so I normally just repeat the exact previous cmake command. Thus, I had completely forgotten about the "cmake ." possibility. The fact remains some projects would like to drop the interpretation altogether (for the reasons I mentioned) and other projects will want to preserve it (for the reasons you mentioned). Can't the needs of both groups be served by a policy? If you would prefer not to have policy about this issue, is there some technical means of detecting when the cmake invocation directory is not the same as the build directory? The combination of cmake invocation directory != build directory AND build_directory == source directory is the one I want to avoid (by erroring out with appropriate message) since that is the combination that appears to get newbies into trouble. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ 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] Compiled file cannot be executed
On Thursday 27 August 2009, Michael Wild wrote:
> On 27. Aug, 2009, at 0:58, Swaroop Ramachandra wrote:
> > Hi,
> >
> > I'm trying to do the following in my CMake file:
> >
> > 1. Generate a "xyz.txt" file
> > 2. Compile a "generate.c" file to give out a "generate" binary in
> > my bin
> > directory.
> > 3. Execute the "generate" binary (The binary just reads contents of
> > "xyz.txt" and creates a copy of "xyz.txt"using read() and write()
> > functions
> > in C)
> >
> > The problem:
> > When I do a fresh build, 1 and 2 succeed. 3 fails with the following
> > error
> > *"bin/generate: Command not found"*
> >
> > However, if I *re-run the build immediately* after, since the
> > "generate"
> > binary is already created, all 3 successfully execute. Here's a
> > snippet of
> > what I have written.
> >
> >
> >
> > /* Code to generate xyz.txt -- Successfully generated each
> > time--*/
> > --
> > -
> > ADD_EXECUTABLE(generate ${CMAKE_CURRENT_SOURCE_DIR}/server/generate.c)
> >
> > set(GEN ${CMAKE_BINARY_DIR}/bin/generate)
> >
> > ADD_CUSTOM_COMMAND(
> > TARGET generate POST_BUILD
> > COMMAND ${GEN}
> > DEPENDS ${CMAKE_BINARY_DIR}/server/xyz.txt}
> > )
> > In my ADD_CUSTOM_COMMAND, I have specified POST_BUILD, which I
> > understood to
> > be that the command will be executed only after creation of the
> > "generate"
> > binary.
>
> That's the wrong way to go about it. the TARGET form of the
> add_custom_command is intended to "finish" the actual target.
Still it should work. The following CMakeLists.txt works for me, blub is
executed after it has been built:
add_executable(blub main.c)
add_custom_command(TARGET blub POST_BUILD
COMMAND ${CMAKE_BINARY_DIR}/blub )
Better would be:
add_executable(blub main.c)
get_target_property(blubLocation blub LOCATION)
add_custom_command(TARGET blub POST_BUILD
COMMAND ${blubLocation} )
Since CMake 2.6.0 you can also simply do:
add_executable(blub main.c)
add_custom_command(TARGET blub POST_BUILD
COMMAND blub )
CMake recognizes the "blub" in COMMAND as name of an executable target and
uses the correct path automatically.
> What you want is something like this:
>
> # no need for absolute paths...
> add_executable(generate server/generate.c)
>
> add_custom_command(
># tell cmake you want to generate xyz.c
>OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/xyz.c
># using the generate program. cmake knows that "generate" refers to
> the above target
>COMMAND generate ${CMAKE_CURRENT_SOURCE_DIR}/xyz.txt
># only run if xyz.txt changed
>DEPENDS xyz.txt
># tell to run in current binary dir
>WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
># some nice comment in the output
>COMMENT "Generating ${CMAKE_CURRENT_BINARY_DIR}/xyz.c"
>VERBATIM
>)
>
>
> And then you simply use ${CMAKE_CURRENT_BINARY_DIR}/xyz.c in one of
> your other targets. CMake will then know that it first needs to create
> target "generate", then run the program on xyz.txt to create $
> {CMAKE_CURRENT_BINARY_DIR}/xyz.c, and finally use that to build the
> actual target.
Are you sure that he said that he needs xyz.c in order to create "generate" ?
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] exit_failure
On Saturday 29 August 2009, Alex H wrote:
> My problem is that in my executable test cpp code, the code may return a
> cpp EXIT_FAILURE macro. Problem is how can I use the cpp macro inside the
> set_tests_properties regex arguments?
Please provide more information.
...just guessing:
test.cpp:
int main()
{
...
return EXIT_FAILURE;
}
in CMakeLists.txt you could do either
set_target_properties(your_test PROPERTIES COMPILE_FLAGS -DEXIT_FAILURE=-7 )
or you could use configure_file() to create a header which #defines
EXIT_FAILURE to something.
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] help with variable usage in target_link_libraries
On Monday 31 August 2009, Eike Kroemer wrote:
> Hi Eric,
>
> > Variable values shoud be retrieve with curly brace, i.e.
> >
> > $LIBS --> ${LIBS}
>
> Yick, I had done that but not cited it correctly in my mail, sorry about
> that.
>
> > Then when you have a list of something you usually use LIST(APPEND
> >
> > LIST(APPEND LIBS "libN")
> >
> > even if
> >
> > SET(LIBS "${LIBS} libN") should work as well.
>
> list(APPEND ...) does the trick (while set doesn't), thanks!
SET(LIBS "${LIBS} libN") should give you one string "libA;libB libN", so you
would link against "-llibA;libB libN" I think.
SET(LIBS ${LIBS} libN)
should work.
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] out of source command line flag
Continued 2) In the same way I did file a bug report for being able to enforce out-of-source if necessary. http://public.kitware.com/Bug/view.php?id=6672 2009/9/5 Bill Hoffman : > > I use this all the time, and so do lots of people that I know. They do this: Yes right I do that too. However it may be easy to follow Roman initial idea and replace: cmake -B ./debug -DDebug=1 . cmake -DDebug=1 ./debug . i.e keep current usage: cmake [options] cmake [options] and add: cmake [options] cmake [options] if you call cmake with 2 paths arguments then one argument should be the source tree other argument should be the build tree. Note however that in this case may not exist at all. CMake may guess which one is the build tree using this algorithm. 1) If there is a CMakeCache.txt in the dir then this is a build tree 2) If the path does not exists then this is a "to be created" build tree error cases are: E1) One gives two existing dir with none containing a CMakeCache.txt ==> send an error message explaining that and abort. E2) One gives two directories E21) both contains a CMakeCache.txt or E22) one contains a CMakeCache.txt and the other does not exists. E21 is plain wrong E22 the source tree may have been polluted with a previous in-source config. E3) One gives a build tree which does not correspond to the given source tree This is easy to check because CMakeCache.txt contains _SOURCE_DIR If this appear CMake should abort and send a message telling the source tree/build tree mismatch. This does not look like that complicated and will keep full backward compatibilty without adding extra "-B" option. To be clear I'm not wanting to apply for providing a patch but may be Roman would like to try ? May be worth trying if other find the idea interesting. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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] out of source command line flag
2009/9/5 Bill Hoffman : > Alan W. Irwin wrote: >> >> On 2009-09-05 09:38+0200 Hendrik Sattler wrote: >> >>> The problem with how giving the build-dir/source-dir to cmake is >>> currently too >>> much dependent on other conditions: >>> cmake [options] >>> cmake [options] >>> >>> The first only is true if no CMakeCache.txt exists there. This was >>> actually a >>> bad choice to have that as only possibility. >>> Being able to do an out-of-source build even if there was a previous >>> in-source >>> build would be much appreciated. >> >> I second that motion to drop the interpretation >> (subject to policy protection, of course, assuming there is at least some >> legitimate use case for .) >> >> CMake newbie's natural tendency seems to be to try an in-source build >> first. >> Thus, I cannot count how many times PLplot and FreeEOS users out-of-source >> build experience has been silently messed up by their first build attempt >> which was in source. It would be at least interesting to be able to programmatically check (from within CMakeLists.txt) that user does in-source build in order to be able to MESSAGE a warning for dubious usage, i.e. 1) "Look like an attempt to do out-of-source but your build will be in-source because of an existing CMakeCache.txt" CMake may setup a CMAKE_BUILDING_INSOURCE when CMakeCache.txt is inside CMAKE_SOURCE_DIR or Working Dir == CMAKE_SOURCE_DIR Thus if Working Dir != CMAKE_SOURCE_DIR AND CMAKE_BUILDING_INSOURCE Then the user may not be doing what he wants. 2) In the same way I did file a >> I have never heard of users actually using the >> interpretation except by mistake. However, >> assuming there is some legitimate use case, I suggest you make a POLICY to >> drop the interpretation. I would be happy to >> adopt >> such a policy for my different software projects simply to drop the volume >> of necessary advice to first-time users who keep falling into the trap of >> using by mistake. >> > I use this all the time, and so do lots of people that I know. They do this: > > cmake . -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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] out of source command line flag
Alan W. Irwin wrote: On 2009-09-05 09:38+0200 Hendrik Sattler wrote: The problem with how giving the build-dir/source-dir to cmake is currently too much dependent on other conditions: cmake [options] cmake [options] The first only is true if no CMakeCache.txt exists there. This was actually a bad choice to have that as only possibility. Being able to do an out-of-source build even if there was a previous in-source build would be much appreciated. I second that motion to drop the interpretation (subject to policy protection, of course, assuming there is at least some legitimate use case for .) CMake newbie's natural tendency seems to be to try an in-source build first. Thus, I cannot count how many times PLplot and FreeEOS users out-of-source build experience has been silently messed up by their first build attempt which was in source. I have never heard of users actually using the interpretation except by mistake. However, assuming there is some legitimate use case, I suggest you make a POLICY to drop the interpretation. I would be happy to adopt such a policy for my different software projects simply to drop the volume of necessary advice to first-time users who keep falling into the trap of using by mistake. I use this all the time, and so do lots of people that I know. They do this: cmake . -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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] out of source command line flag
On 2009-09-05 09:38+0200 Hendrik Sattler wrote: The problem with how giving the build-dir/source-dir to cmake is currently too much dependent on other conditions: cmake [options] cmake [options] The first only is true if no CMakeCache.txt exists there. This was actually a bad choice to have that as only possibility. Being able to do an out-of-source build even if there was a previous in-source build would be much appreciated. I second that motion to drop the interpretation (subject to policy protection, of course, assuming there is at least some legitimate use case for .) CMake newbie's natural tendency seems to be to try an in-source build first. Thus, I cannot count how many times PLplot and FreeEOS users out-of-source build experience has been silently messed up by their first build attempt which was in source. I have never heard of users actually using the interpretation except by mistake. However, assuming there is some legitimate use case, I suggest you make a POLICY to drop the interpretation. I would be happy to adopt such a policy for my different software projects simply to drop the volume of necessary advice to first-time users who keep falling into the trap of using by mistake. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ 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] Module find error running cmake
On Friday 04 September 2009, twf wrote: > When trying to install a program that requires cmake I run into the > following problem. > > First off, the install requires the following command: > > /cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ../ > > During the run, the following error is generated: > > /CMake Error at /usr/local/share/cmake-2.6/Modules/FindKDE4.cmake:84 > (MESSAGE): > ERROR: cmake/modules/FindKDE4Internal.cmake not found in > > /root/.kde/share/apps;/usr/share/kubuntu-default-settings/kde4-profile/defa >ult/share/apps;/usr/share/kde4/apps Call Stack (most recent call first): > CMakeLists.txt:5 (find_package) This list of directories looks ok. Is there maybe a kde4 development package which is not installed ? (don't know how it is organized into packages on kubuntu) /usr/share/kde4/apps/ looks like a good candidate actually. > -- Configuring incomplete, errors occurred!/ > > This has happened on two separate installs. I've tried uninstalling > cmake, then reinstalling. Yes, and that's good (because there was no reason why that should have been the problem). 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] How to build 2 targets from the same source, differing in -D_SWITCHES_ only
Am Freitag 04 September 2009 21:51:59 schrieb Alexander Neundorf:
> On Thursday 27 August 2009, Christian Ehrlicher wrote:
> > > Von: "Marcel Loose"
> > > CC: cmake@cmake.org
> > > Betreff: Re: [CMake] How to build 2 targets from the same
> > > source, differing in -D_SWITCHES_ only
> > >
> > > Hi Eike,
> > >
> > > I think the only safe and reliable way to do this is create several
> > > build directories, e.g. build/type_1 and build/type_2.
> > > When running cmake in build/type_1, you should add -D_TYPE1_ to the
> > > preprocessor flags; same for build/type_2.
> >
> > Why? Does SET_TARGET_PROPERTIES() with COMPILE_FLAGS not work?
>
> So the full code is:
>
> add_executable(foo main.c)
> set_target_properties(foo PROPERTIES COMPILE_FLAGS -D_TYPE1_)
>
> add_executable(bar main.c)
> set_target_properties(bar PROPERTIES COMPILE_FLAGS -D_TYPE2_)
Actually better:
set (foo_DEFS _TYPE1_)
set (bar_DEFS _TYPE2_)
foreach(i foo bar)
add_executable(${i} main.c)
set_target_properties(foo PROPERTIES COMPILE_DEFINITIONS ${${i}_DEFS})
foreach(flag RELEASE DEBUG)
set_target_properties(foo PROPERTIES COMPILE_DEFINITIONS_{flag}
${${i}_DEFS})
endforeach(flag)
endforeach(i)
;-)
HS
___
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] out of source command line flag
Am Freitag 04 September 2009 21:58:02 schrieb Alexander Neundorf: > On Sunday 09 August 2009, Roman Shtylman wrote: > > I have been meaning to try and create such a patch for a while. The > > idea behind the patch is that you can specify the location of the out > > of source build directory on the command line. By itself, this really > > isn't all that useful save having to type mkdir 'some dir', cd 'some > > dir', and 'cmake ..' > > > > I think the use in this feature comes from being able to do something > > like the following from WITHIN the source tree > > > > $> cmake -B ./debug -DDebug=1 . > > $> cmake -B ./release -DRelease=1 . > > > > This will create directories 'debug' and 'release' in the source tree > > where it will put all of the cmake cache files and whatnot from the > > build. Each directory will then be using the appropriate things > > triggered by having set the -D ... note... this is just a simple > > example > > > > I used the -B flag (as it was already there and I couldn't tell what > > else it was currently doing) ... but pardon me if it actually had a > > previous purpose. > > > > This patch is not meat to be exhaustive (as I might have missed a > > usage scenario with cache files or whatnot), but it does demonstrate > > the capability I am looking for. > > > > Feedback is welcome...or if you think this feature is utterly > > worthless let me know :) I wanna hear why it can't work (don't just > > say...well, you could have just made the directory and done all that > > within it...yea...I know...but the point is that I didn't have to :) ) > > Hmm, from my POV this patch doesn't add functionality to cmake, and it adds > a second way to do one thing. Personally I wouldn't vote for including the > patch. > Don't know what the others say. > Documentation is missing. The problem with how giving the build-dir/source-dir to cmake is currently too much dependent on other conditions: cmake [options] cmake [options] The first only is true if no CMakeCache.txt exists there. This was actually a bad choice to have that as only possibility. Being able to do an out-of-source build even if there was a previous in-source build would be much appreciated. HS ___ 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
