Brad King wrote:
> On 10/10/2013 08:55 PM, Stephen Kelly wrote:
>> Brad King writes:
>>> I just checked the VS 6, 9 and 11 IDEs and it is possible to mark
>>> a source file as excluded from certain configurations. Those versions
>>> represent all the VS generators.
>
> If listing all sources an
On 10/10/2013 08:55 PM, Stephen Kelly wrote:
> Brad King writes:
>> I just checked the VS 6, 9 and 11 IDEs and it is possible to mark
>> a source file as excluded from certain configurations. Those versions
>> represent all the VS generators.
If listing all sources and marking each one excluded
Brad King writes:
>
> On 07/09/2013 11:30 AM, Stephen Kelly wrote:
> > Brad King ...> writes:
> >> On 06/07/2013 09:13 AM, Stephen Kelly wrote:
> >>>SOURCES $<$:other.cpp>
> >>
> >> That has been requested as a feature occasionally. I'm not sure
> >> it is possible to implement on all the
On 07/10/2013 11:12 AM, Stephen Kelly wrote:
> Yes, but I guess it's also memory management. I can't return str.c_str() if
> str is an automatic variable. I guess I can use the trick of creating a
> static std::string and return that.
Oh, right. I'd rather not expose that to projects that might
Brad King wrote:
> IIRC we have the same problem with inter-target dependencies and
> we solved it by taking the union of dependencies from all configs.
> Is that right?
Yes, I think that's right.
> I don't think that solution can work for source files.
> Perhaps for Xcode we can generate wrappe
On 07/09/2013 11:30 AM, Stephen Kelly wrote:
> Brad King writes:
>> On 06/07/2013 09:13 AM, Stephen Kelly wrote:
>>>SOURCES $<$:other.cpp>
>>
>> That has been requested as a feature occasionally. I'm not sure
>> it is possible to implement on all the generators though.
I just checked the VS
Brad King writes:
>
> On 06/07/2013 09:13 AM, Stephen Kelly wrote:
> >SOURCES $<$:other.cpp>
>
> That has been requested as a feature occasionally. I'm not sure
> it is possible to implement on all the generators though.
>
I looked into this a bit and pushed target-SOURCES-property to my
Brad King wrote:
> On 06/07/2013 09:13 AM, Stephen Kelly wrote:
>>SOURCES $<$:other.cpp>
>
> That has been requested as a feature occasionally. I'm not sure
> it is possible to implement on all the generators though.
Ok. I won't have generator expressions in SOURCES as a goal, but I'll see
On 06/07/2013 09:13 AM, Stephen Kelly wrote:
>SOURCES $<$:other.cpp>
That has been requested as a feature occasionally. I'm not sure
it is possible to implement on all the generators though.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware
Brad King wrote:
> On 06/07/2013 08:35 AM, Stephen Kelly wrote:
>> I looked into it a bit and found that the SOURCES target property already
>> exists. I was going to just add
>>
>>
>>
On 06/07/2013 08:35 AM, Stephen Kelly wrote:
> I looked into it a bit and found that the SOURCES target property already
> exists. I was going to just add
>
>
>
Brad King wrote:
> On 06/07/2013 04:42 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>> Oops, yes I meant TARGET_OBJECTS.
>>
>> And what is the trickyness with it?
>
> It is not currently tricky. I'm saying it may be tricky to
> convert the storage over to a sources target property.
> Perhaps i
On 06/07/2013 04:42 AM, Stephen Kelly wrote:
> Brad King wrote:
>> Oops, yes I meant TARGET_OBJECTS.
>
> And what is the trickyness with it?
It is not currently tricky. I'm saying it may be tricky to
convert the storage over to a sources target property.
Perhaps it is simpler than I think though
Brad King wrote:
> On 06/06/2013 11:15 AM, Stephen Kelly wrote:
>>> Also it may be tricky due to the way $ is
>>> currently handled up front.
>>
>> You mean TARGET_OBJECTS? It seems to only populate a ObjectLibraries
>> container which is later only used at generate-time. Or do you mean
>> someth
On 06/06/2013 11:15 AM, Stephen Kelly wrote:
>> Also it may be tricky due to the way $ is
>> currently handled up front.
>
> You mean TARGET_OBJECTS? It seems to only populate a ObjectLibraries
> container which is later only used at generate-time. Or do you mean
> something else?
Oops, yes I m
Brad King wrote:
> (2) Name the property "SOURCES" and allow projects to edit it.
> Having access to the list of sources for both reading and writing
> has been requested occasionally. It is not safe to edit after
> reading the LOCATION property or something else that computes
> the linker languag
On 06/06/2013 10:41 AM, Stephen Kelly wrote:
> Brad King wrote:
>> Instead let's consider introducing a usage requirement that can bring
>> in object libraries, external objects, or even source files. That
>> would solve this and be pretty cool too.
>
> There's no existing API for manipulating th
17 matches
Mail list logo