On 09/02/2013 02:03 AM, Stephen Kelly wrote:
> Brad King wrote:
>> I think a better name may be "language features" rather than
>> "compiler features"
>
> I don't agree with that.
> [good arguments]
Okay, agreed.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Brad King wrote:
> BTW, I think a better name may be "language features" rather than
> "compiler features" because we are declaring features of language
> versions and variants, not of the compilers.
I don't agree with that. We are enumerating/introspecting the features of
the compiler. The fa
On 08/30/2013 08:15 AM, Stephen Kelly wrote:
> However, thinking about it again, I think you're right that that is not
> necessary.
Okay, it can always be factored out into separate files later anyway.
>> I thought the idea was to specify in target_compiler_features the
>> features needed so the
Brad King wrote:
> On 08/30/2013 08:02 AM, Stephen Kelly wrote:
>> It turns out that in order to do this, the compiler features would
>> have to be listed independently of Modules/Compiler/${ID}.cmake.
>> Otherwise I wouldn't be able to check the MSVC features while using GNU.
>>
>> Maybe they sh
On 08/30/2013 08:02 AM, Stephen Kelly wrote:
> It turns out that in order to do this, the compiler features would
> have to be listed independently of Modules/Compiler/${ID}.cmake. Otherwise I
> wouldn't be able to check the MSVC features while using GNU.
>
> Maybe they should be listed in Modu
Brad King wrote:
> On 08/29/2013 11:14 AM, Stephen Kelly wrote:
>> Another option would be not to have the VERSION in the signature, but
>> always use CMAKE_MINIMUM_VERSION_REQUIRED to determine what to generate.
>>
>> The content generated depends only on the features of the cmake binary
>> bein
On 08/29/2013 11:14 AM, Stephen Kelly wrote:
> Another option would be not to have the VERSION in the signature, but always
> use CMAKE_MINIMUM_VERSION_REQUIRED to determine what to generate.
>
> The content generated depends only on the features of the cmake binary being
> run, so it relieves
Brad King wrote:
>> Yes, versioning is a good idea to think about.
>>
>>write_compiler_detection_header(
>>FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
>>PREFIX Grantlee_
>>VERSION 3
>>)
>
> This could help somewhat because we could change what is produced
> by a newer version w
On 08/28/2013 10:29 AM, Stephen Kelly wrote:
> at least parts of KWIML should fit into this discussion too
[snip]
>> If instead projects distribute their own copies then we have
>> the option of changing the API and it is up to them to deal with it when
>> updating.
>
> Yes. That's what I propose
Brad King wrote:
> On 08/27/2013 05:56 PM, Stephen Kelly wrote:
>>> and the expected results and will be useful for you to
>>> write a more complete solution.
>>
>> I'm sure Eike can do it too. Or at least get started with encoding the
>> detection results into platform files and refactoring the
On 08/27/2013 05:56 PM, Stephen Kelly wrote:
> I don't think the topic should be merged as-is because of the problems with
> the interface we know about so far. If you merge it and we also merge the
> interface which we agree to be better, we'll have two competing interfaces.
I don't plan to mer
Brad King wrote:
> On 08/15/2013 08:37 AM, Stephen Kelly wrote:
>> target_compiler_feature(
>>REQUIRED [ ...])
>> target_compiler_feature(
>>OPTIONAL DEFINE )
>
> Doesn't this require the language (CXX) to be specified somewhere?
> Perhaps the feature names should start with _ e.g.
On 08/15/2013 08:37 AM, Stephen Kelly wrote:
> target_compiler_feature(
>REQUIRED [ ...])
> target_compiler_feature(
>OPTIONAL DEFINE )
Doesn't this require the language (CXX) to be specified somewhere?
Perhaps the feature names should start with _ e.g. CXX_final.
> This is better i
13 matches
Mail list logo
