[cmake-developers] [CMake 0015377]: CMake cannot test compiler features in Turkish locale

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15377 
== 
Reported By:Ongun Kanat
Assigned To:
== 
Project:CMake
Issue ID:   15377
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   high
Status: new
== 
Date Submitted: 2015-01-27 18:34 EST
Last Modified:  2015-01-27 18:34 EST
== 
Summary:CMake cannot test compiler features in Turkish
locale
Description: 
When using Turkish UTF-8 locale(tr_TR.UTF-8) CMake exits with error below

   CMake Error at /usr/share/cmake-3.1/Modules/CMakeTestCCompiler.cmake:78
(CMAKE_DETERMINE_COMPILE_FEATURES):
  Unknown CMake command "CMAKE_DETERMINE_COMPILE_FEATURES".

Exporting LANG and LC_ALL variables as en_US.UTF-8 fixes problem temporarily.

Steps to Reproduce: 
- Download any source with CMake build support
- Run
  $ export LANG=tr_TR.UTF-8
  $ export LC_ALL=tr_TR.UTF-8
  $ cmake
- It will exit.

Additional Information: 
I suspect that there may be a Turkish 'I' problem in source code. If it does a
uppercase/lowercase conversion there is a risk that the result of conversion
wrong/non-English. 

For detailed info check:
http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html

I'm also adding trace output of cmake.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-01-27 18:34 Ongun KanatNew Issue
2015-01-27 18:34 Ongun KanatFile Added: cmakeout.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: 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] [PATCH] OpenSSL 1.0.2 update

[Rolf Eike Beer]

Rolf Eike Beer wrote:
> Guillaume Belz wrote:
> > Hi,
> > 
> > OpenSSL 1.0.2 was released last week and there is a little change in code,
> > which impact FindOpenSSL.cmake script. The script use a regex to read the
> > version of OpenSLL inside opensslv.h file. In the last commit, this file
> > 
> > was modified with a formatting tool and the line 33 was changed from:
> >  # define OPENSSL_VERSION_NUMBER  0x1010L
> > 
> > to:
> >  #define OPENSSL_VERSION_NUMBER 0x1010L
> > 
> > To fix that, it's possible to change regex in FindOpenSSL.cmake file in
> > 
> > line 288, from:
> >  REGEX "^#define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*")
> > 
> > to:
> >  REGEX "^# *define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*")
> > 
> > It's work on Scientific Linux 7 with OpenSSL 1.0.2 and CMake 3.1.1. I have
> > not checked on other platforms.
> 
> Should there be a patch? Otherwise I'll create one from your mail.

http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c5d9a8283cfac15b4a5a07f18d5eb10c1f388505

Brad, this is based on origin/release. In case there will be a 3.1.2 I think 
this is a good candidate.

Eike
-- 

signature.asc
Description: This is a digitally signed message part.
-- 

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] [PATCH] OpenSSL 1.0.2 update

[Rolf Eike Beer]

Guillaume Belz wrote:
> Hi,
> 
> OpenSSL 1.0.2 was released last week and there is a little change in code,
> which impact FindOpenSSL.cmake script. The script use a regex to read the
> version of OpenSLL inside opensslv.h file. In the last commit, this file
> was modified with a formatting tool and the line 33 was changed from:
> 
>  # define OPENSSL_VERSION_NUMBER  0x1010L
> 
> to:
> 
>  #define OPENSSL_VERSION_NUMBER 0x1010L
> 
> To fix that, it's possible to change regex in FindOpenSSL.cmake file in
> line 288, from:
> 
>  REGEX "^#define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*")
> 
> to:
> 
>  REGEX "^# *define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*")
> 
> It's work on Scientific Linux 7 with OpenSSL 1.0.2 and CMake 3.1.1. I have
> not checked on other platforms.

Should there be a patch? Otherwise I'll create one from your mail.

Eike
-- 

signature.asc
Description: This is a digitally signed message part.
-- 

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

[cmake-developers] [PATCH] OpenSSL 1.0.2 update

[Guillaume Belz]

Hi,

OpenSSL 1.0.2 was released last week and there is a little change in code,
which impact FindOpenSSL.cmake script. The script use a regex to read the
version of OpenSLL inside opensslv.h file. In the last commit, this file
was modified with a formatting tool and the line 33 was changed from:

 # define OPENSSL_VERSION_NUMBER  0x1010L

to:

 #define OPENSSL_VERSION_NUMBER 0x1010L

To fix that, it's possible to change regex in FindOpenSSL.cmake file in
line 288, from:

 REGEX "^#define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*")

to:

 REGEX "^# *define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*")

It's work on Scientific Linux 7 with OpenSSL 1.0.2 and CMake 3.1.1. I have
not checked on other platforms.

Thanks,
Guillaume



Commit on opensslv.h:
https://github.com/openssl/openssl/blob/0f113f3ee4d629ef9a4a30911b22b224772085e5/crypto/opensslv.h
-- 

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] Windows Store generated solution also containing win32 console app?

[Robert Goulet]

Ok, make sense. However, the generator is essentially the same for both Win32 
and WinRT except for a very few properties. Turns out I was able to make a 
patch, however I don't know if that's going to be rejected because of the way I 
did it, but it works really well so far.

This allow me to set the target property VS_WINRT_DISABLE on the projects I 
want, while still targeting Windows Store in the toolchain file. I personally 
find it cleaner to do that in my CMakeLists.txt files rather than using 
multiple CMake root projects. It also works for the add_custom_command rule 
with COMMAND as stated in the documentation: "If COMMAND specifies an 
executable target (created by the add_executable() command) it will 
automatically be replaced by the location of the executable created at build 
time." I can share the same add_custom_command between all platforms instead of 
having a different one just for Windows Store build.

Let me know your thoughts about it.
Thanks!


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Tuesday, January 27, 2015 12:43 PM
To: Robert Goulet
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Windows Store generated solution also 
containing win32 console app?

On 01/27/2015 12:03 PM, Robert Goulet wrote:
> CMake uses a global variable that essentially means that the generator 
> targets a Windows Store app. This makes it difficult to hack it to 
> control this per project rather than globally.

This is a fundamental limitation of the design of CMake, not just of the VS 
generator.  We only support one target arch/platform at a time.
The entire configuration process runs with one platform in mind, and one 
toolchain per language.  This is the same reason one cannot build host binaries 
while cross compiling.  Even if one were to hack the VS generator to set the 
type of one .vcxproj file, it still would not have proper information to 
generate the other properties in the file.

You could try running CMake with execute_process to generate a second nested 
build tree, and then include_external_msproject to make one of its .vcxproj 
files available in the outer .sln.  I've not tried this though.

-Brad



vs-winrt-disable.patch
Description: vs-winrt-disable.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] Improving Vim support in CMake

[Alex Merry]

On Monday 26 January 2015 18:22:41 Ben Boeckel wrote:
> On Mon, Jan 26, 2015 at 22:39:00 +, Alex Merry wrote:
> > Maybe it's just my colour scheme - I'll have a play with the colour
> > settings when I have some free time.
> 
> FWIW, I use neverland-darker, a 256-color scheme. Looking at it with an
> 8-color scheme does indeed have it all being the same. 'Label' seems to
> at least be different than 'String' in all the default color schemes
> whereas 'Constant' is the same as 'String' there. Unfortunately, there's
> no 'Variable' highlighting group and if we don't stick to the defaults
> available, none of the colorschemes will know what to do with it :/ .
> 'Tag' also seems like it might be viable.
> 
> Maybe making cmakeArguments -> Constant and cmakeVariableValue ->
> Identifier would work better? Strings are the same as unquoted words
> there though :/ .

That would explain it. I think variables are used in strings enough that 
making them different colours on standard colour schemes is sensible. I would 
argue that distinguishing variables and constants, say, is less important.

Alex
-- 

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

[cmake-developers] [CMake 0015376]: CMake creates Xcode project with invalid project settings

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15376 
== 
Reported By:tron_thomas
Assigned To:
== 
Project:CMake
Issue ID:   15376
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-01-27 13:48 EST
Last Modified:  2015-01-27 13:48 EST
== 
Summary:CMake creates Xcode project with invalid project
settings
Description: 
A project configured for Xcode will have invalid project settings

Steps to Reproduce: 
Steps:
1.Create a simple hello world C++ module named Hello.cpp
2. Use the following CMake script to configure the project to build with Xcode
6.1.1

cmake_minimum_required (VERSION 3.1.0)

project(Hello)

add_executable(Hello Hello.cpp)

3. Open the Xcode project

Expected:
The project should open with no warnings or errors

Actual:
The project will contain the following warning about overriding architecture
settings

Additional Information: 
This can be particularly bad for project that contains many buildables as Xcode
may take a long time to fix the issue or may get hung up trying to apply the fix

It is also quite annoying when someone frequently reconfigures the project with
CMake as the problem return each time
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-01-27 13:48 tron_thomasNew Issue
==

-- 

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] Setting additional compile flags to .hlsl files?

[Brad King]

On 01/27/2015 01:22 PM, Robert Goulet wrote:
> If the flag would be wrong, compilation would fail.

What if the flag is not added at all because the property is ignored?
The test needs to be something that would fail without this change.

Thanks,
-Brad

-- 

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] Setting additional compile flags to .hlsl files?

[Robert Goulet]

If the flag would be wrong, compilation would fail.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Tuesday, January 27, 2015 12:59 PM
To: Robert Goulet
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Setting additional compile flags to .hlsl files?

On 01/27/2015 12:47 PM, Robert Goulet wrote:
> There you go. Let me know if it's good now.

Thanks.  I've committed the patch and merged for testing:

 VS: Add source file property to set extra hlsl shader flags
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6b9bd827

In the test I see:

 VS_SHADER_FLAGS "/Fh $(OutDir)%(Filename).h"

which can be manually verified but I do not see how the test automatically 
verifies that the flag is correctly used.

Thanks,
-Brad

-- 

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] Setting additional compile flags to .hlsl files?

[Brad King]

On 01/27/2015 12:47 PM, Robert Goulet wrote:
> There you go. Let me know if it's good now.

Thanks.  I've committed the patch and merged for testing:

 VS: Add source file property to set extra hlsl shader flags
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6b9bd827

In the test I see:

 VS_SHADER_FLAGS "/Fh $(OutDir)%(Filename).h"

which can be manually verified but I do not see how the test
automatically verifies that the flag is correctly used.

Thanks,
-Brad

-- 

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] Setting additional compile flags to .hlsl files?

[Robert Goulet]

There you go. Let me know if it's good now.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Monday, January 26, 2015 3:09 PM
To: Robert Goulet
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Setting additional compile flags to .hlsl files?

On 01/26/2015 02:28 PM, Robert Goulet wrote:
> Here's a patch for adding additional compile flags to .hlsl files in 
> Visual Studio. For this I simply added the new VS_SHADER_FLAGS source 
> file property and basically did the same as other VS_SHADER_* 
> properties.

Okay.  Please use spaces instead of tabs and match the surrounding indentation. 
 Also please add/modify:

 Help/prop_sf/VS_SHADER_FLAGS.rst
 Help/manual/cmake-properties.7.rst

to add the documentation, and add a release note as:

 Help/release/dev/vs-shader-flags.rst

following the style of other release note files in that directory.

Also please extend Tests/VSWinStorePhone/CMakeLists.txt with a test for this 
feature.

Thanks,
-Brad



vs-shader-flags.patch
Description: vs-shader-flags.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] Windows Store generated solution also containing win32 console app?

[Brad King]

On 01/27/2015 12:03 PM, Robert Goulet wrote:
> CMake uses a global variable that essentially means that the generator
> targets a Windows Store app. This makes it difficult to hack it to
> control this per project rather than globally.

This is a fundamental limitation of the design of CMake, not just of
the VS generator.  We only support one target arch/platform at a time.
The entire configuration process runs with one platform in mind, and
one toolchain per language.  This is the same reason one cannot build
host binaries while cross compiling.  Even if one were to hack the
VS generator to set the type of one .vcxproj file, it still would not
have proper information to generate the other properties in the file.

You could try running CMake with execute_process to generate a second
nested build tree, and then include_external_msproject to make one of
its .vcxproj files available in the outer .sln.  I've not tried this
though.

-Brad

-- 

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

[cmake-developers] Windows Store generated solution also containing win32 console app?

[Robert Goulet]

Hi all,

When generating VS solution targeting the Windows Store system, it turns out 
that ALL projects gets to target Windows Store. In the event that the solution 
also contains a project that is a simple Win32 console application that perform 
some tasks on files needed by the final Windows Store app, it looks like this 
is currently not possible.

Looking at the code, it seems CMake uses a global variable that essentially 
means that the generator targets a Windows Store app. This makes it difficult 
to hack it to control this per project rather than globally. A quick test shows 
that it is possible to have a solution that contains both Win32 console targets 
as well as Windows Store app targets in Visual Studio.

How should I go about this? I would like to avoid creating two distinct build 
folders with their own solutions and having to deal with paths once we want to 
execute commands. What if CMake could simply force specific projects to be 
Win32 console apps? Or perhaps the other way around, add a new token in 
add_executable to specify if it's a Windows Store app (just like WIN32 or 
MACOSX_BUNDLE, could have a third one: WINSTORE)?

Thoughts?



Robert Goulet
Senior Software Developer
Games Solutions Group
Autodesk Media & Entertainment

MAIN +1 514 393 1616
DIRECT +1 514 954 3911
MOBILE +1 438 397 4075

Autodesk, Inc.
10 Rue Duke
Montreal, QC, H3C 2L7
www.autodesk.com

[Description: Email_Signature_Logobar]

-- 

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] [PATCH][CPack][RPM] multiple path relocation prefixes

[Brad King]

On 01/19/2015 09:31 AM, Brad King wrote:
> Most of the RunCMake tests are for negative tests, but mostly for
> running "cmake".  IIUC you need tests that run "cpack", right?
> For that you can use run_cmake_command.  See use in the
> RunCMake.CTestMemcheck test to run "ctest":
> 
>  Tests/RunCMake/CTestMemcheck/RunCMakeTest.cmake
> 
> See also Tests/RunCMake/CommandLine/RunCMakeTest.cmake for other
> uses to try the non-generator signatures of "cmake".

The topic as of commit 36f93b60 has Tests/CPackRPM/RunCPack.cmake
which should be refactored to use RunCMake infrastructure, perhaps
in a new Tests/RunCMake/CPackRPM test.  Please extend the topic
to move the test over.

Thanks,
-Brad

-- 

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] build on multiple cores

[Bill Hoffman]

On 1/27/2015 10:52 AM, Deepak Garg wrote:

I want to build my cmake code with multiple cores (64). For this I am
trying to test the build on 4 cores by typing

make -j 4

But still build is done by a single core. The time taken for build by

make  and  make -j 4

is same. Can anyone guide me that what am I doing wrong?

http://www.kitware.com/blog/home/post/434

However, if make and make -j4 are the same something is odd.  What 
platform/compiler?  What version of make?


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

[cmake-developers] [CMake 0015375]: Please provide a way to evaluate generator expressions on demand

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15375 
== 
Reported By:raspy
Assigned To:
== 
Project:CMake
Issue ID:   15375
Category:   CMake
Reproducibility:have not tried
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2015-01-27 11:00 EST
Last Modified:  2015-01-27 11:00 EST
== 
Summary:Please provide a way to evaluate generator
expressions on demand
Description: 
I have a use case like this:

I have a custom module which requires to call external script with current
compilation flags. This is performed with execute_process() passing flags
gathered from property COMPILE_OPTIONS, CMAKE_C_FLAGS and
CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE}.

However, with the COMPILE_OPTIONS I get generator expression, which is not
evaluated, i.e. $<$:-g> and passing it further makes no sense. It
would be good if I could in any way (with a variant of set() command maybe?)
force evaluation of such generator expressions to make use of them where they
may be needed but not natively supported.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-01-27 11:00 raspy  New Issue
==

-- 

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] build on multiple cores

[Nils Gladitz]

On 01/27/2015 04:52 PM, Deepak Garg wrote:

I want to build my cmake code with multiple cores (64). For this I am
trying to test the build on 4 cores by typing

make -j 4

But still build is done by a single core. The time taken for build by

make  and  make -j 4

is same. Can anyone guide me that what am I doing wrong?


I think this might be better discussed on the user's rather than 
developer's mailing list.


In general this works for me as-is (with gnu make).

Nils


--

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

[cmake-developers] build on multiple cores

[Deepak Garg]

I want to build my cmake code with multiple cores (64). For this I am
trying to test the build on 4 cores by typing

make -j 4

But still build is done by a single core. The time taken for build by

make  and  make -j 4

is same. Can anyone guide me that what am I doing wrong?


thanks
Deepak
-- 

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

[cmake-developers] [CMake 0015374]: Support generator expresssions in add_definitions()

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15374 
== 
Reported By:raspy
Assigned To:
== 
Project:CMake
Issue ID:   15374
Category:   CMake
Reproducibility:always
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2015-01-27 10:14 EST
Last Modified:  2015-01-27 10:14 EST
== 
Summary:Support generator expresssions in add_definitions()
Description: 
Generator expressions are supported in add_compile_options(),
target_compile_options() and target_compile_definitions(), but not in
add_definitions() which leads to some inconsistency. I would make use of
generator expressions in definitions on a global level, mostly define some
symbols based on CMake's variables setup.

Please add support for generator expressions in add_definitions().
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-01-27 10:14 raspy  New Issue
==

-- 

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

[cmake-developers] [CMake 0015373]: GNUInstallDirs is not correct for ArchLinux

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15373 
== 
Reported By:Dimitri Merejkowsky
Assigned To:
== 
Project:CMake
Issue ID:   15373
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-01-27 09:02 EST
Last Modified:  2015-01-27 09:02 EST
== 
Summary:GNUInstallDirs is not correct for ArchLinux
Description: 
When setting CMAKE_INSTALL_PREFIX to /usr, CMAKE_INSTALL_FULL_LIBDIR is set to
/usr/lib64, which is not correct since the /usr merge :

https://www.archlinux.org/news/update-filesystem-201301-1-and-glibc-217-2-together/



Steps to Reproduce: 
# CMakeLists.txt:

cmake_minimum_required(VERSION 3.1)
project(foo)

include(GNUInstallDirs)

message(STATUS "CMAKE_INSTALL_FULL_LIBDIR: ${CMAKE_INSTALL_FULL_LIBDIR}")


$ cmake -DCMAKE_INSTALL_PREFIX=/usr

Output is /usr/lib64, should be /usr/lib
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-01-27 09:02 Dimitri MerejkowskyNew Issue   

==

-- 

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