Re: [cmake-developers] Objective-C support

2014-02-14 Thread Ben Boeckel 
On Fri, Feb 14, 2014 at 18:02:18 -0500, Sean McBride wrote:
> What I mean is that with C++, and STL especially, it's hard to build a
> library with a given compiler/standard library combination and link
> that library into an executable built with a different
> compiler/standard library combination.  (Harder than with say C.)
> That's the case on any platform.  I was only trying to point out that
> 10.9 Mavericks is not special in this regard.

Ah, so standard library *compatibility*, not *stability* then? I agree
with that.

--Ben
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Objective-C support

2014-02-14 Thread Steve Wilson 
I was really looking for a way to add the the STL library as a library on the 
command line and then I realized that I had forgotten that on the Mac, the 
Objective-C++ compiler driver is clang++/g++.   I was only thinking about 
clang/gcc.  Sorry for the noise.


On Feb 14, 2014, at 4:02 PM, Sean McBride  wrote:

> On Fri, 14 Feb 2014 17:47:00 -0500, Ben Boeckel said:
> 
>>> Same in 10.7 and 10.8, and any OS really, since C++ ABIs are not super
>>> stable.
>> 
>> Hmm? The only one I know of recently is 4.7.0 and 4.7.1 breaking
>> std::string ABI with C++11 support enabled (4.7.2 fixed it to be
>> compatible with < 4.7.0 and I'd, personally, blacklist those two
>> versions if you use C++11).
> 
> What I mean is that with C++, and STL especially, it's hard to build a 
> library with a given compiler/standard library combination and link that 
> library into an executable built with a different compiler/standard library 
> combination.  (Harder than with say C.)  That's the case on any platform.  I 
> was only trying to point out that 10.9 Mavericks is not special in this 
> regard.
> 
> Cheers,
> 
> --
> 
> Sean McBride, B. Eng s...@rogue-research.com
> Rogue Researchwww.rogue-research.com
> Mac Software Developer  Montréal, Québec, Canada
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Objective-C support

2014-02-14 Thread Sean McBride 
On Fri, 14 Feb 2014 17:47:00 -0500, Ben Boeckel said:

>> Same in 10.7 and 10.8, and any OS really, since C++ ABIs are not super
>> stable.
>
>Hmm? The only one I know of recently is 4.7.0 and 4.7.1 breaking
>std::string ABI with C++11 support enabled (4.7.2 fixed it to be
>compatible with < 4.7.0 and I'd, personally, blacklist those two
>versions if you use C++11).

What I mean is that with C++, and STL especially, it's hard to build a library 
with a given compiler/standard library combination and link that library into 
an executable built with a different compiler/standard library combination.  
(Harder than with say C.)  That's the case on any platform.  I was only trying 
to point out that 10.9 Mavericks is not special in this regard.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada


-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Objective-C support

2014-02-14 Thread Ben Boeckel 
On Fri, Feb 14, 2014 at 17:22:13 -0500, Sean McBride wrote:
> Same in 10.7 and 10.8, and any OS really, since C++ ABIs are not super
> stable.

Hmm? The only one I know of recently is 4.7.0 and 4.7.1 breaking
std::string ABI with C++11 support enabled (4.7.2 fixed it to be
compatible with < 4.7.0 and I'd, personally, blacklist those two
versions if you use C++11).

--Ben
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Objective-C support

2014-02-14 Thread Sean McBride 
On Fri, 14 Feb 2014 15:14:23 -0700, Steve Wilson said:

>On Mavericks (OS X 10.9) there are two STL implementations: libstdc++
>and libc++. 

That was also the case in 10.7 and 10.8.  In 10.9 the default changed from 
libstdc++ to libc++ though.

>I’m adding support for Objective-C++ and on Mavericks it
>matters which C++ library is used for linking.

Same in 10.7 and 10.8, and any OS really, since C++ ABIs are not super stable.

>Is there a standard
>mechanism already in place for handling the difference in CMake.   I
>checked for the -stdlib command line flag in the sources, but didn’t
>find it anywhere.Or put it another way, do we require users to
>decide themselves with STL implementation  to use?

To me, it's something the user (of CMake) chooses, very much like choosing to 
build as C89 or C99 or C++03 or C++11.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Objective-C support

2014-02-14 Thread Steve Wilson 
On Mavericks (OS X 10.9) there are two STL implementations: libstdc++ and 
libc++.   I’m adding support for Objective-C++ and on Mavericks it matters 
which C++ library is used for linking.   Is there a standard mechanism already 
in place for handling the difference in CMake.   I checked for the -stdlib 
command line flag in the sources, but didn’t find it anywhere.Or put it 
another way, do we require users to decide themselves with STL implementation  
to use?




signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] visual-studio-preprocessor-undefine fix for /U problems

2014-02-14 Thread Steve Wilson 
I pushed a updated version of the topic branch to stage.   It refactors the 
OutputPreprocessorDefinitions method into a a new method OutputDefinitionsByTag 
and adds an argument that lets you specify the tag.I also fixed the test 
case.

SteveW


On Feb 14, 2014, at 11:26 AM, Brad King  wrote:

> On 2/13/2014 7:33 PM, Steve Wilson wrote:
>> The topic is visual-studio-preprocessor-undefine.
> 
> Thanks.  The method
> 
> cmVisualStudioGeneratorOptions
> ::OutputUndefinePreprocessorDefinitions
> 
> appears to duplicate a lot of code from
> 
> cmVisualStudioGeneratorOptions
> ::OutputPreprocessorDefinitions
> 
> Please factor out and parameterize the common pieces to
> avoid the duplication.
> 
> Also, the test case appears to undef a macro in a specific
> source file and test that it is undefined, but never defines
> the macro for the whole target so of course it will never
> be defined and the test will always pass.
> 
> Thanks,
> -Brad
> -- 
> 
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] visual-studio-preprocessor-undefine fix for /U problems

2014-02-14 Thread Brad King 
On 2/14/2014 3:48 PM, Steve Wilson wrote:
> In the refactor of these functions, would you like to see that
> refactor as a separate commit or merged in with the commit for
> the other changes?

I have a slight preference for a separate commit that first
factors the common part out and calls it from the one site,
and then the main commit that adds the new call site.  I
wouldn't reject it (for that reason) either way though.

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] visual-studio-preprocessor-undefine fix for /U problems

2014-02-14 Thread Steve Wilson 

On Feb 14, 2014, at 11:26 AM, Brad King  wrote:

> On 2/13/2014 7:33 PM, Steve Wilson wrote:
>> The topic is visual-studio-preprocessor-undefine.
> 
> Thanks.  The method
> 
> cmVisualStudioGeneratorOptions
> ::OutputUndefinePreprocessorDefinitions
> 
> appears to duplicate a lot of code from
> 
> cmVisualStudioGeneratorOptions
> ::OutputPreprocessorDefinitions

In the refactor of these functions, would you like to see that refactor as a 
separate commit or merged in with the commit for the other changes?

SteveW


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Objective-C support

2014-02-14 Thread Brad King 
On 2/14/2014 3:08 PM, Steve Wilson wrote:
> the preference I do have is for the OBJC (OBJCXX) form simply because
> it matches the capital cases of C and CXX in the CMAKE_* variables

We do have "Fortran" already: CMAKE_Fortran_FLAGS, etc. but this
is a valid point:

 CMAKE_OBJC_FLAGS
 CMAKE_OBJCXX_FLAGS

v.

 CMAKE_ObjC_FLAGS
 CMAKE_ObjCXX_FLAGS

I think the uppercase names look nicer in the variable names so
let's stick with what you proposed unless others chime in.

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Objective-C support

2014-02-14 Thread Steve Wilson 

On Feb 14, 2014, at 12:06 PM, Brad King  wrote:

> On 2/13/2014 7:35 PM, Steve Wilson wrote:
>> The topic name is ‘objective-c-support.’
> 
> Currently if CXX is enabled then .m sources get compiled as CXX.
> See Modules/CMakeCXXCompiler.cmake.in:
> 
> set(CMAKE_CXX_SOURCE_FILE_EXTENSIONS C;M;c++;cc;cpp;cxx;m;mm;CPP)
> 
> In order to be compatible we need to make sure that is still
> the case.  However, if OBJC is enabled then that should be
> preferred to CXX for .m sources.  

There isn’t anything specific in the code to make an accounting for this type 
of requirement.   I’ll see what I can do and update the tests.

> Is that the case with these
> changes?  Please add test cases to cover these combinations.
> 
> IMO the capitalization "ObjC" looks nicer than "OBJC" and will
> extend better to "ObjCXX" than "OBJCXX".  I have no strong
> preference if others disagree though.

I don’t have a strong preference, but the preference I do have is for the OBJC 
(OBJCXX) form simply because it matches the capital cases of C and CXX in the 
CMAKE_* variables, which is the most common language type that users encounter.


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0014756]: RFE: Report changes to cached values

2014-02-14 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=14756 
== 
Reported By:Ben Boeckel
Assigned To:
== 
Project:CMake
Issue ID:   14756
Category:   CMake
Reproducibility:have not tried
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2014-02-14 14:20 EST
Last Modified:  2014-02-14 14:20 EST
== 
Summary:RFE: Report changes to cached values
Description: 
Add a variable to CMake such that it will report when a cached variable's value
is different from the default being set. For example:

set(var dflt CACHE STRING "description")

could output:

path/to/CMakeLists.txt:42: var 'dflt' -> 'cachedvalue'

and could also, at the end of configure, print out a command line (or initial
cache file) to be used to duplicate the build on another machine. I was thinking
of 'CMAKE_REPORT_DELTA' as the control variable.

Came up from a gn thread:
https://groups.google.com/a/chromium.org/d/msg/gn-dev/la6vwV3x-o4/hkJJ78a7rqwJ
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2014-02-14 14:20 Ben BoeckelNew Issue
==

-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Objective-C support

2014-02-14 Thread Brad King 
On 2/13/2014 7:35 PM, Steve Wilson wrote:
> The topic name is ‘objective-c-support.’

Currently if CXX is enabled then .m sources get compiled as CXX.
See Modules/CMakeCXXCompiler.cmake.in:

 set(CMAKE_CXX_SOURCE_FILE_EXTENSIONS C;M;c++;cc;cpp;cxx;m;mm;CPP)

In order to be compatible we need to make sure that is still
the case.  However, if OBJC is enabled then that should be
preferred to CXX for .m sources.  Is that the case with these
changes?  Please add test cases to cover these combinations.

IMO the capitalization "ObjC" looks nicer than "OBJC" and will
extend better to "ObjCXX" than "OBJCXX".  I have no strong
preference if others disagree though.

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] visual-studio-preprocessor-undefine fix for /U problems

2014-02-14 Thread Steve Wilson 
Will do.

On Feb 14, 2014, at 11:26 AM, Brad King  wrote:

> On 2/13/2014 7:33 PM, Steve Wilson wrote:
>> The topic is visual-studio-preprocessor-undefine.
> 
> Thanks.  The method
> 
> cmVisualStudioGeneratorOptions
> ::OutputUndefinePreprocessorDefinitions
> 
> appears to duplicate a lot of code from
> 
> cmVisualStudioGeneratorOptions
> ::OutputPreprocessorDefinitions
> 
> Please factor out and parameterize the common pieces to
> avoid the duplication.
> 
> Also, the test case appears to undef a macro in a specific
> source file and test that it is undefined, but never defines
> the macro for the whole target so of course it will never
> be defined and the test will always pass.
> 
> Thanks,
> -Brad
> -- 
> 
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] visual-studio-preprocessor-undefine fix for /U problems

2014-02-14 Thread Brad King 
On 2/13/2014 7:33 PM, Steve Wilson wrote:
> The topic is visual-studio-preprocessor-undefine.

Thanks.  The method

 cmVisualStudioGeneratorOptions
 ::OutputUndefinePreprocessorDefinitions

appears to duplicate a lot of code from

 cmVisualStudioGeneratorOptions
 ::OutputPreprocessorDefinitions

Please factor out and parameterize the common pieces to
avoid the duplication.

Also, the test case appears to undef a macro in a specific
source file and test that it is undefined, but never defines
the macro for the whole target so of course it will never
be defined and the test will always pass.

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Objective-C support

2014-02-14 Thread Steve Wilson 
Yes, it does, less support for Objective-C++.   I haven’t add support for 
Objective-C++.It shouldn’t be too hard to add support for Objective-C++ 
though.


On Feb 14, 2014, at 8:42 AM, Sean McBride  wrote:

> On Thu, 13 Feb 2014 17:35:42 -0700, Steve Wilson said:
> 
>> I just pushed a small topic branch to stage the introduces support for
>> Objective-C as a ‘supported’ language with a separate identity from C/
>> CXX.   The topic name is ‘objective-c-support.’
> 
> Does that solve this by any chance:
> 
> 
> Cheers,
> 
> -- 
> 
> Sean McBride, B. Eng s...@rogue-research.com
> Rogue Researchwww.rogue-research.com 
> Mac Software Developer  Montréal, Québec, Canada



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Objective-C support

2014-02-14 Thread Sean McBride 
On Thu, 13 Feb 2014 17:35:42 -0700, Steve Wilson said:

>I just pushed a small topic branch to stage the introduces support for
>Objective-C as a ‘supported’ language with a separate identity from C/
>CXX.   The topic name is ‘objective-c-support.’

Does that solve this by any chance:


Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0014755]: Cannot use VisualStudio 2013 Express with Windows7.1SDK for 64Bit builds

2014-02-14 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14755 
== 
Reported By:jest
Assigned To:
== 
Project:CMake
Issue ID:   14755
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2014-02-14 06:13 EST
Last Modified:  2014-02-14 06:13 EST
== 
Summary:Cannot use VisualStudio 2013 Express with
Windows7.1SDK for 64Bit builds
Description: 
I'm trying to use VisualStudio 2013 Express with the 64 Bit Compiler from
VisualStudio 2010. Since VisualStudio 2010 Express doesn't contain the 64Bit
compiler, Windows7.1SDK is required to.

The Compiler test of CMake doesn't pass.

Steps to Reproduce: 
tried
cmake -G "Visual Studio 12 Win64" -T "v100"
as well as
cmake -G "Visual Studio 12 Win64" -T "Windows7.1SDK"

Workaround:
cmake -G "Visual Studio 12 Win64"
and manually select Windows7.1SDK in VisualStudio
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2014-02-14 06:13 jest   New Issue
==

-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers