Re: [CMake] Supress generation of a Makefile
Am 18. März 2015 23:59:10 MEZ, schrieb aditya siram aditya.si...@gmail.com: Hi all, I have a cross platform project where Linux/Mac users will use the standard autoheader;autoconf;./configure .. routine, but on Windows users will do cmake .; make. that's the wrong command I am using CMake solely to substitute some variables in some subdirectory Makefile.in's. Strange idea, really. The problem is that there is an existing Makefile in the root of the project that must not be disturbed but keeps getting overwritten whenever I run cmake .. How do I stop CMake from generating a Makefile? 1. Don't have any file named CMakeLists.txt in that directory, give it some other name ending usually with .cmake 2. Use cmake -P HS -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] (no subject)
I have written a cmake tool which allows you to modify CMakeLists files from the command line. It is written in pure cmake leverages my cmake token parser/ reflection functions which I added to cmakepp (a free, universial, open source, pure cmake function library) http://thetoeb.de/2015/03/19/cmakepp-reflecting-and-manipulating-cmakelists/ If anyone is interested and has suggestion visit me on https://github.com/toeb/cmakepp Cheers Tobi -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] How to use pkg-config in CMakeLists.txt
Hello All
I'm newer for CMake. Now I'm trying to use CMake in current project, but I met
following issue
CMakeLists.txt :
FIND_PACKAGE(PkgConfig)PKG_CHECK_MODULES(GLIB
glib-2.0)PKG_CHECK_MODULES(GTHREAD gthread-2.0)PKG_CHECK_MODULES(GOBJECT
gobject-2.0)
SET(GLIB_LIBS glib-2.0 gthread-2.0 gobject-2.0)
EXEC_PROGRAM(pkg-config ARGS --cflags ${GLIB_LIBS} OUTPUT_VARIABLE GLIB2_CFLAGS
RETURE_VALUE PKG_CONFIG_RETURE_VALUE)EXEC_PROGRAM(pkg-config ARGS --libs
${GLIB_LIBS} OUTPUT_VARIABLE GLIB2_LIBS RETURN_VALUE
PKG_CONFIG_RETURE_VALUE)MESSAGE(${GLIB2_CFLAGS})MESSAGE(${GLIB2_LIBS})
INCLUDE_DIRECTORIES(AFTER GLIB_INCLUDE_DIRS)INCLUDE_DIRECTORIES(AFTER
GTHREAD_INCLUDE_DIRS)INCLUDE_DIRECTORIES(AFTER GOBJECT_INCLUDE_DIRS)
INCLUDE_DIRECTORIES(AFTER${PROJECT_SOURCE_DIR}/include
${PROJECT_SOURCE_DIR}/include/message)INCLUDE_DIRECTORIES(AFTER
${GLIB2_CFLAGS})
SET(SRC_LIST main.c nmp_args.c nmp_message.c
nmp_sysctl.c)ADD_EXECUTABLE(nmp-cms ${SRC_LIST})TARGET_LINK_LIBRARIES(nmp-cms
${GLIB2_LIBS})
When I execute 'CMake VERBOSE=1', I found its output was the following. How
could I remove the quotation marks ? Or it's incorrect to use the pkg-config in
CMakelist ?
cd /home/compiler/nmp-cms/build/obj/core /usr/bin/gcc
-I/home/compiler/nmp-cms/src/core/GLIB_INCLUDE_DIRS
-I/home/compiler/nmp-cms/src/core/GTHREAD_INCLUDE_DIRS
-I/home/compiler/nmp-cms/src/core/GOBJECT_INCLUDE_DIRS
-I/home/compiler/nmp-cms/include -I/home/compiler/nmp-cms/include/message
-I/home/compiler/nmp-cms/src/core/-pthread -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include-o
CMakeFiles/nmp-cms.dir/main.c.o -c
/home/compiler/nmp-cms/src/core/main.c/home/compiler/nmp-cms/src/core/main.c:5:18:
fatal error: glib.h: No such file or directory
Sean
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v3.2.1-442-ga066f73
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 a066f73263c8c56f968324e51daee717291b3908 (commit) from 486e9f4f49646cf48915781a411edfe9d9ea7618 (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=a066f73263c8c56f968324e51daee717291b3908 commit a066f73263c8c56f968324e51daee717291b3908 Author: Kitware Robot kwro...@kitware.com AuthorDate: Fri Mar 20 00:01:03 2015 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Fri Mar 20 00:01:03 2015 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 7d81aa9..8127464 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 2) -set(CMake_VERSION_PATCH 20150319) +set(CMake_VERSION_PATCH 20150320) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
I just noticed that in some of the new C++ sources you copied the copyright block from other files but forgot to change the notice lines to refer to yourself or your employer. Certainly the current lines do not refer to the author of the content ;) Sorry about that. I updated them. Good start. Please adjust the section header underlines to match the length of the title text. Formatted Also, the new variable/GHS-MULTI document needs to be added to the toctree in 'Help/manual/cmake-variables.7.rst'. Added This time I actually tried building the sources. Some of the classes prefix their inline method definitions: cmGlobalGhsMultiGenerator::GetGhsBuildCommand This is not necessary when it is inside the class, and some compilers do not like it. Fixed. That was a copy and paste error. It probably didn't compile in GCC. Also the new lines you added to Source/cmake.cxx need to be made conditional on the platform. The CMakeLists.txt file already contains the proper platform conditions, so use of the new generator must match. I moved it under #if defined(_WIN32) !defined(__CYGWIN__) # if !defined(CMAKE_BOOT_MINGW) I'm not quite sure why my FindModulesExecuteAll test fails. Seems like boost installation issue, but it isn't an issue in my nighlty test Whether boost is found may depend on the environment, and your nightly test wipes out PATH. It turns out that I upgraded boost without clearing the test's cache. My experimental test does not do a clean build because I'm trying to make it faster. Here's a link to the results: https://open.cdash.org/buildSummary.php?buildid=3735698. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Tuesday, March 17, 2015 1:56 PM To: Geoffrey Viola Cc: cmake-developers@cmake.org Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 03/16/2015 02:03 AM, Geoffrey Viola wrote: Done Thanks for the updates. I just noticed that in some of the new C++ sources you copied the copyright block from other files but forgot to change the notice lines to refer to yourself or your employer. Certainly the current lines do not refer to the author of the content ;) Added some documentation. Good start. Please adjust the section header underlines to match the length of the title text. Also, the new variable/GHS-MULTI document needs to be added to the toctree in 'Help/manual/cmake-variables.7.rst'. This time I actually tried building the sources. Some of the classes prefix their inline method definitions: cmGlobalGhsMultiGenerator::GetGhsBuildCommand This is not necessary when it is inside the class, and some compilers do not like it. Also the new lines you added to Source/cmake.cxx need to be made conditional on the platform. The CMakeLists.txt file already contains the proper platform conditions, so use of the new generator must match. I'm not quite sure why my FindModulesExecuteAll test fails. Seems like boost installation issue, but it isn't an issue in my nighlty test Whether boost is found may depend on the environment, and your nightly test wipes out PATH. Thanks, -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 0001-Added-some-support-for-a-Green-Hills-MULTI.patch Description: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating buildsystem metadata from CMake
Hi Anton,
you raised some good points, all of which I agree with:-)
On Thu, Mar 19, 2015 at 10:18 AM, Anton Makeev
anton.mak...@jetbrains.com wrote:
* If it is useful to preprocess/compile/assemble individual files from
IDEs, as made possible by the Makefiles and Ninja generators, we'll need
to design that.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429
This is definitely useful, but I’m not sure what kind of information needed
here,
as I see it, since we already know the files in the project, we can tell
make/ninja to simply compile it.
You asked me to use cmake --build, so ideally that would be cmake
--build . /full/file/path and ideally it would work with all
generators without magic in the IDE:-)
Since I assume that not all build systems will allow to build
individual files, you might want to add a flag
can_build_individual_files or similar to the metadata that a
generator can use to flag the IDE on whether the generated build
system can build individual files or not. Then the IDE can hide that
option if it is not applicable.
* Some more information from project() may be relevant, but it's not clear
yet. We will likely know more when we have decided the file format and
generated some 'interesting' metadata files.
Project name, list of the configurations are most needed ones.
We also use CMAKE_lang_SOURCEFILE_EXTENSIONS to determine if a given file
is potentially source file or not.
I would also love to see subprojects:-) CMake allows for them, doesn't it?
Will you still need CMAKE_lang_SOURCEFILE_EXTENSIONS when you can
get access to the list of sources as above where each group of files
is flagged with the language, etc.?
snip
As a side note, it seems more natural to me to have one json file with one
or several configurations listed, providing that there is also shared
project info that should be in that files.
something like that:
project: ProjectName
configurations: {
{
name: Debug
targets: {...}
},
{
name: Release
targets: {...}
}
...
}
I'd actually prefer having a configurations key with the list of the
configurations an object applies to.
That can be optional if the object is relevant to all configurations
(default in single-configuration generators;-).
This key would then need to be applicable to targets as well as the
group of source files.
So that would be something like this:
{
project: TestProject,
targets: [ {
name: Debug only,
configurations: [ Debug ],
type: EXECUTABLE,
sources: [ ... ]
},
{
name: Release only,
configurations: [ Release ],
type: EXECUTABLE,
sources: [ ... ]
},
{
name: Run Tests,
sources: sources: {
language: C++,
defines: FOO=1,
sources: [ {
type: sources,
name: Critical source files,
configurations: [ Debug ],
include_paths: /some/path,
files: [ /full/path/a.cpp, /full/path/b.cpp ]
},
{
type: headers,
files: [ /full/path/a.h ]
},
{
type: generated,
files: [ /full/path/config.h ]
},
{
type: sources,
name: Tests,
include_paths: /some/path,
files: [ /full/path/a.cpp, /full/path/b.cpp, /full/path/test.cpp ]
} ]
}
}
That would most likely avoid quite a bit of duplication in the file(s).
This also means that conditions don't need to be added inside the metadata
file for configurations in order to show files 'excluded' by being part of
a non-active configuration. The code implementing discovery of excluded
files is in the generate-metadata branch in my clone.
Yeap, that would be a convenient property for me, too.
snip
* Generating metadata only (without generating buildsystem files) is not
currently in scope. This was requested several times, but it is not
clear why.
It’s simply to be able to get this the information as quickly as possible.
I’m not sure which part is most slow, but, say, InsightToolKit 4.5
(http://www.itk.org/Wiki/ITK/Source), generates in couple of minutes. The
regeneration, even when nothing was changes, a few dozens of seconds.
Plus, we’d prefer being able to open the project without any questions to
user, e.g. not asking, which generator he/she prefers. If we generate using
‘wrong’ default generator we’ll need to regenerate everything again when
user decides to change it.
Another benefit of skipping actual generation is possibly better error
recoverability.
That is, some generators may fail here and there if the project is
incorrectly configured (e.g. source files are missing). Skipping the
generation phase will (probably) help getting the project metadata even in
that case.
But anyway, it seems a little outside of the scope of the discussion.
Very good points that I fully agree with.
* How much information does tooling need about installation? Targets
can use different include directories and compile definitions in their
install
[cmake-developers] [CMake 0015460]: PGI Fortran compiler does not recognise -fPIE
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15460
==
Reported By:Tiago Quintino
Assigned To:
==
Project:CMake
Issue ID: 15460
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2015-03-19 11:02 EDT
Last Modified: 2015-03-19 11:02 EDT
==
Summary:PGI Fortran compiler does not recognise -fPIE
Description:
By selecting POSITION_INDEPENDENT_CODE the PGI compiler settings add
automatically the flag -fPIE.
This flag does not exist for PGI Fortran Compiler.
I have checked this with pgf77, pgf90 and pgfortran.
The only workaround I found is to set the flag:
-DCMAKE_Fortran_FLAGS=-noswitcherror
This turns off the check for flag validity in the compiler, but obviously is not
a long-term solution, since now any test to compiler flags will pass
irrespectively if the flag is recognised or not.
The solution I think is changing Modules/Platform/Linux-PGI.cmake to:
set(CMAKE_${lang}_COMPILE_OPTIONS_PIE )
Note that the flag -fPIE also does not exist for PGI C and C++ compilers.
Steps to Reproduce:
Build the attached CMakeLists.txt project with
cmake -DCMAKE_Fortran_COMPILER=pgf90 ..
Additional Information:
I am using CMake 3.1.2 and PGI Fortran 14.4.
The man page of compiler does not reference this flag whatsoever.
This is the output I get:
-- The C compiler identification is GNU 4.8.1
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- The Fortran compiler identification is PGI
-- Check for working Fortran compiler: /usr/local/apps/pgi/14.4/bin/pgf90
-- Check for working Fortran compiler: /usr/local/apps/pgi/14.4/bin/pgf90 --
broken
CMake Error at
/usr/local/apps/cmake/3.1.2/share/cmake-3.1/Modules/CMakeTestFortranCompiler.cmake:54
(message):
The Fortran compiler /usr/local/apps/pgi/14.4/bin/pgf90 is not able to
compile a simple test program.
It fails with the following output:
Change Dir: /home/ma/matq/git/cmake-test/pgi-pie/build/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/gmake cmTryCompileExec951442437/fast
gmake: Warning: File `Makefile' has modification time 1.9 s in the future
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec951442437.dir/build.make
CMakeFiles/cmTryCompileExec951442437.dir/build
gmake[1]: Entering directory
`/home/ma/matq/git/cmake-test/pgi-pie/build/CMakeFiles/CMakeTmp'
gmake[1]: Warning: File
`CMakeFiles/cmTryCompileExec951442437.dir/flags.make' has modification time
1.9 s in the future
/usr/local/apps/cmake/3.1.2/bin/cmake -E cmake_progress_report
/home/ma/matq/git/cmake-test/pgi-pie/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building Fortran object
CMakeFiles/cmTryCompileExec951442437.dir/testFortranCompiler.f.o
/usr/local/apps/pgi/14.4/bin/pgf90 -Mpreprocess -Kieee -fPIE -c
/home/ma/matq/git/cmake-test/pgi-pie/build/CMakeFiles/CMakeTmp/testFortranCompiler.f
-o CMakeFiles/cmTryCompileExec951442437.dir/testFortranCompiler.f.o
pgf90-Error-Unknown switch: -fPIE
gmake[1]: ***
[CMakeFiles/cmTryCompileExec951442437.dir/testFortranCompiler.f.o] Error 1
gmake[1]: Leaving directory
`/home/ma/matq/git/cmake-test/pgi-pie/build/CMakeFiles/CMakeTmp'
gmake: *** [cmTryCompileExec951442437/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:7 (enable_language)
==
Issue History
Date ModifiedUsername FieldChange
==
2015-03-19 11:02 Tiago Quintino New Issue
2015-03-19 11:02 Tiago Quintino File Added: CMakeLists.txt
==
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses:
Re: [cmake-developers] Generating buildsystem metadata from CMake
Hi Stephen,
On Thu, Mar 19, 2015 at 2:22 AM, Stephen Kelly steve...@gmail.com wrote:
* In Target Properties/Conditional Properties and optional
properties: Would it make sense to have a list of target_files, each
with a filepath and a type? That would be more similar to the targets
which also are a list with name/type.
What semantics would the 'type' have? I don't really understand what you
propose here.
See the examples with the sources below:
sources: [ {
language: C++,
type: sources,
defines: FOO=1,
include_paths: /usr/include,
files: [ /full/path/a.cpp, /full/path/b.cpp ]
},
{
language: C++,
type: headers,
files: [ /full/path/a.h ]
},
{
language: C++,
type: generated,
files: [ /full/path/config.h ]
}]
The type is used to distinguish between the different kinds of files.
Your proposal uses different keys for all the different kinds of
files, my is to use the same key for all sources and distinguish
between them by giving a type.
snip
These configurations are only relevant to generators that can support
e.g. having debug and release builds in the same build directory or
did I misunderstand this?
Yes, your understanding is correct.
How are we supposed to handle a set of files for these configurations?
Yes, that's how I see it working...
How can we notice when one gets added and removed?
I'm not experienced enough with those generators to know. I'm not even
certain whether it is possible to add to the list of configurations for
those generators, or if the list is hardcoded.
Something to look into or get information from someone else on this list if
they know.
I think in the worst case, you'd watch the CMakeCache.txt and read the
CMAKE_CONFIGURATION_TYPES from there. I know you want to care about only one
file, but maybe two is not so bad :), and there is potentially other stuff
in the cache which might be useful, and which might not lend itself to the
json metadata file. We'll have to see.
So we are back to parsing random files in internal formats again:-)
Could you add have a configuration list key in the top level of each
file that lists all available configurations (including itself)? That
might be the lowest overhead solution that does not require parsing
extra files that I can think of right now.
I definitely will not hardcode cmake generator-A has configurations X
and Y while generator-A supports configurations X, Z and D into the
cmake plugin. I do prefer not to support configurations at all to
doing that.
snip
* Make it more easy for an IDE to support actions such as 'remove file
from the project', which requires removing it from the CMakeLists.txt
at the appropriate place, and 'add new file/class to target', which
involves adding code to the CMakeLists.txt file at the appropriate
place. Most likely the easiest way to do the latter is using the
target_sources() command, and to support the former, the location of
the declaration of the target, and all target_sources() calls would
need to be recorded. Even that is not enough because of transitive
consumption of source files through the link interface, but that is
likely irrelevant.
That would be the icing on the cake, but getting a full description of
the project is what I care for at this point.
Can you expand on what 'a full description of the project' means to you? Do
you mean something different than 'how each object is compiled'?
When you open a project in Creator we offer to import existing
builds (at least for qmake-based projects, none of the other build
systems supports this yet). That is very convenient when you blew away
the .user file we put into the sources directory with all the
information on how you built stuff where.
What we do there is to check the default project build location for
folders that contain a build of the current sources.
To do so we need to know which code was built in that directory and
which kit (think set of compiler, Qt, some other settings) were used
to in the built in that directory. We also need to figure out the
exact configuration (parameters passed to the configure step of the
build system) that was built there.
Since this is a feature our qmake users love I would also like to make
that possible with cmake. It would be great if I could get most
answers from the json file.
* I don't generate 'dependencies' (actually the list of files which the
buildsystem re-generation depends on) as Aleix did, because there is no
well-defined usefulness for that list yet.
How is the IDE supposed to know that it needs to re-run cmake then? If
a file changes that may very well change the list of files that the
IDE needs to display, so re-running cmake only at the next build is
not going to work.
Ok, I didn't realize that's the scenario we're talking about for that
content. Are you saying that you would
Set up a
[Cmake-commits] CMake branch, next, updated. v3.2.1-1092-gc52d65d
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 c52d65dbee29af9141d12cfd2f5c1c5b4ac5a3a5 (commit)
via e77c0b4758d3721990e67532f8081abbcb83a23f (commit)
from 80ca453b3313688e40750f0908c05a77d5c4a3d4 (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=c52d65dbee29af9141d12cfd2f5c1c5b4ac5a3a5
commit c52d65dbee29af9141d12cfd2f5c1c5b4ac5a3a5
Merge: 80ca453 e77c0b4
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Mar 19 15:08:13 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Mar 19 15:08:13 2015 -0400
Merge topic 'xcode-xctest' into next
e77c0b47 fixup! Tests: Add XCTest example to test Frameworks and Cocoa App
Bundles
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e77c0b4758d3721990e67532f8081abbcb83a23f
commit e77c0b4758d3721990e67532f8081abbcb83a23f
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Mar 19 14:56:52 2015 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Mar 19 14:57:01 2015 -0400
fixup! Tests: Add XCTest example to test Frameworks and Cocoa App Bundles
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 71cdb0f..aa03f86 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1505,7 +1505,9 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P
${CMake_SOURCE_DIR}/Utilities/Release
)
endif()
- if(CMake_TEST_XCODE_VERSION AND NOT CMake_TEST_XCODE_VERSION VERSION_LESS 5)
+ if(CMake_TEST_XCODE_VERSION AND NOT CMake_TEST_XCODE_VERSION VERSION_LESS 5
+ AND OSX_VERSION MATCHES ^([0-9]+\\.[0-9]+))
+set(XCTest_BUILD_OPTIONS -DCMAKE_OSX_DEPLOYMENT_TARGET=${CMAKE_MATCH_1})
ADD_TEST_MACRO(XCTest ${CMAKE_CTEST_COMMAND} -C $CONFIGURATION -V)
endif()
---
Summary of changes:
Tests/CMakeLists.txt |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[CMake] Understanding dependencies with an external project
Hi there, I only started using CMake a couple days ago so please pardon
the newbie questions. I'm having some trouble understanding the
relationships between add_dependencies, add_custom_command, and
add_custom_target as they relate to forming dependencies on external
project targets.
I am trying to write plugins for a CMake-enabled project. How one goes
about this is by getting the source and adding an optional cmake module
that calls what amounts to a custom externalproject_add() with no
build/install step; the external sources are just copied into the
framework's source tree. That way, when I call `make`, the framework
build includes the plugins. (This inflexible linking mechanism is
necessary due to language constraints that aren't relevant here)
The way I've integrated this into my own project is via my own
externalproject_add() that grabs the framework and, as a custom step,
copies over the module I mentioned:
ExternalProject_Add(framework
# ...
)
ExternalProject_Add_Step(framework copy-plugin-loader
# First symlink so the framework will download from local fs
COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_CURRENT_SOURCE_DIR}
${framework_EXTERNALS_DIR}/my-plugins
# Now link the custom module it needs to find in its modules dir
COMMAND ${CMAKE_COMMAND} -E create_symlink
${CMAKE_CURRENT_BINARY_DIR}/CMake/plugin_loader.cmake
${heka_SOURCE_DIR}/cmake/plugin_loader.cmake
DEPENDERS configure
DEPENDEES download
)
Later on in my CMakeLists I use add_test() and use `ctest` to run my
plugin tests (that only work once my source is grafted onto the
framework's tree; see weird language design choice mentioned above).
My question (finally) is this: how can I tell CMake that, if I change a
source or test file in *my* tree, the framework (specifically, a custom
target defined in _the framework's_ CMakeLists) needs to be rebuilt
before the tests can run? To illustrate, here's my current workflow:
# Edit *my* source files, tests, whatever, then...
% cd framework/binary_dir
% make graft_plugin_sources
% cd -
% ctest .
Ideally, I could just run `ctest` and CMake will handle the rest. I
don't know if that's a thing it does, so, I'd settle for calling the
top-level `make` again. I just can't figure out the proper add_*() calls
to make to tell CMake My project (and/or custom target/command of my
own) depends on this particular target of `framework` so whenever I
change a source file in my project, we gotta re-run it.
Thanks in advance for any insight,
Tom
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Support of codesign
Thanks for providing the patch. http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2c50db26 Clint On Wednesday, March 18, 2015 08:24:36 AM A. Klitzing wrote: Ping? :-) Am 11.03.2015 13:21 schrieb A. Klitzing aklitz...@gmail.com: Hi there! I added another improvement to the codesign feature. Sometimes it is helpful to overwrite or pass additional parameters like --timestamp=none to codesign. But this shouldn't be the default for everyone. So I added the variable CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER. Hope you like it. Regards André 2015-02-20 16:20 GMT+01:00 Clinton Stimpson clin...@elemtech.com: On Friday, February 20, 2015 12:07:55 PM A. Klitzing wrote: Hi Clint, I have another patch to tweak the error output a little bit. If codesign fails it won't be possible to get the error message of codesign itself. That is a little bit confusing because it just fails without an understandable reason. This patch will print the output of codesign if it fails. Thanks. http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=7b582d1 Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] control dependencies in cmake stage
Thank you Mark for hint about that solution. I think the losses may be reduced by distributing #includes directives across many well known files (as in example: GenChunk.tar) Those chunks can be already compiled in parallel. Best regards, Tomasz. 2015-03-12 17:50 GMT+01:00 Mark Abraham mark.j.abra...@gmail.com: Hi, In that case, you could have the generator generate a master source file with a known name that #includes the real generated files. This means that the generation can have clean dependencies, but does lose any benefits from parallel make. It also keeps the intrinsic complexity of the generation close to itself, rather than unduly complicating the build system. Up to you. Mark On 11/03/2015 6:40 pm, Tomasz Majchrowski cont...@majchrowski.de wrote: Thank you Mark for information. The input for the generator is in-house developed language. The decision what kind of files will be generated is made based on the grammar of this language. In the current implementation of the generator the extraction of the file list will take more or less the same time as execution of the generation phase itself. Otherwise we will definitely use make phase. Best regards, Tomasz. 2015-03-11 0:15 GMT+01:00 Mark Abraham mark.j.abra...@gmail.com: Hi, Sure, this is straightforward to do all at make time, if you're prepared to find out what the names of the generated files are. They must follow some pattern ;-). Solutions with make-time globbing are surely impossible, and Petr's IF idea seems brittle to me. See (for example) https://github.com/gromacs/gromacs/blob/master/src/gromacs/CMakeLists.txt#L154. The idea is that you have some target that does the generation, and you make the eventual library/executable depend on its output files. The target that contains the generation command has its own dependencies, so you don't have to re-generate if those don't go out of date. In that example, gmx_configure_version_file just wraps configure_file(), which sets up that dependency chain. You'd need an add_custom_command(), it seems, whose OUTPUT had the list of generated files. There's no problem to use add_library() with a file generated in the build tree - just mention it in an output. There are several much more complicated examples at https://github.com/gromacs/gromacs/blob/master/docs/CMakeLists.txt. For example, we build a gmx binary that writes the same text we display with gmx topic -h instead as topic.rst restructedText, which is then parsed with Sphinx to produce manpages that go in the tarball via CPack, or to produce HTML to go on our webpage. Helper scripts mostly live in https://github.com/gromacs/gromacs/tree/master/cmake Cheers, Mark On Tue, Mar 10, 2015 at 6:06 PM, Tomasz Majchrowski use...@majchrowski.de wrote: (sorry if you received this message twice) Hi Mark This is the set of C++ source code files. This set will be compiled during the make stage. Ideally will be to move generation to make stage. Unfortunately I don't know the name of the files that will be generated before generation phase occurs. Therefore I can't use set_source_files_properties( foo.cxx PROPERTIES GENERATED true) in cmake stage. Please drop a line if you know how to bypass this limitation. Thanks, Tomasz. 2015-03-10 7:05 GMT+01:00 Mark Abraham mark.j.abra...@gmail.com: Hi, What are you generating that must be done at cmake time? Mark On 09/03/2015 5:36 pm, Tomasz Majchrowski use...@majchrowski.de wrote: Hi, I'm wondering if there is an easy way to control the dependencies in the cmake stage. Basically I would like skip execution of some script run over execute_process in case some input files didn't change. The regular way will be to use add_custom_command add_custom_target however those required targets, so the make stage. Please advice how to proceed in case there is need to control this already in cmake stage? Thanks, Tomasz. -- Pozdrawiam/Best regards/Mit freundlichen Grüßen, Tomasz Majchrowski, Information Technology and Services Consultant and Contractor -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Pozdrawiam/Best regards/Mit freundlichen Grüßen, Tomasz Majchrowski, Information Technology and Services Consultant and Contractor http://public.kitware.com/mailman/listinfo/cmake -- Pozdrawiam/Best regards/Mit freundlichen Grüßen, Tomasz
Re: [CMake] nonstandard C++ source filename extension
This works for me:
---CMakeLists.txt
cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
project(asm CXX)
add_executable(foo foo.bar)
set_source_files_properties(foo.bar PROPERTIES LANGUAGE CXX)
---foo.bar---
int main() { return 0;}
$ /cygdrive/c/Program\ Files\ \(x86\)/CMake/bin/cmake -GNinja ..
-- The CXX compiler identification is MSVC 16.0.40219.1
-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/hoffman/foo/b
hoffman@quasar ~/foo/b
$ ninja
[1/2] Building CXX object CMakeFiles\foo.dir\foo.bar.obj
foo.bar
[2/2] Linking CXX executable foo.exe
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Supress generation of a Makefile
On 3/19/2015 2:20 AM, Hendrik Sattler wrote: How do I stop CMake from generating a Makefile? Don't do in source builds. mkdir build. cd build cmake .. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
