Brad King wrote:
On 10/10/2013 08:55 PM, Stephen Kelly wrote:
Brad King 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
On 07/09/2013 11:30 AM, Stephen Kelly wrote:
Brad King brad.king@... writes:
On 06/07/2013 09:13 AM, Stephen Kelly wrote:
SOURCES $$CONFIG:Debug: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
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 wrapper
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:
On 06/07/2013 09:13 AM, Stephen Kelly wrote:
SOURCES $$CONFIG:Debug: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
Brad King wrote:
On 06/06/2013 11:15 AM, Stephen Kelly wrote:
Also it may be tricky due to the way $TARGET_SOURCES:... 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
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/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
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 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 09:13 AM, Stephen Kelly wrote:
SOURCES $$CONFIG:Debug: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
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 the source
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 language, but
On 06/06/2013 11:15 AM, Stephen Kelly wrote:
Also it may be tricky due to the way $TARGET_SOURCES:... 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?
14 matches
Mail list logo
