Re: [cmake-developers] target sources property

2013-10-11 Thread Stephen Kelly 
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 and marking each one excluded in specific
 configurations is sufficient to implement this feature then it
 should work for VS.

Ok, I'll take your word for it :). I don't know enough about the VS 
generators to implement it for them.

 Can you compute the set of sources and objects
 for all configurations before generating any config, and for those
 that are the same across all configs do not do any special markings
 and put it in Xcode too?  Then things would work except in the true
 per-config source file case.

Yes, I think that's possible.

Thanks,

Steve.


--

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] target sources property

2013-07-10 Thread Brad King 
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 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.  I do not see an obvious way to do it
in Xcode though :(

 I looked into this a bit and pushed target-SOURCES-property to my clone. The
 sources would necessarily be config-specific if they are going to depend on
 the linked libraries.
 
 Can you think of any way around that?

No.  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?  I don't think that solution can work for source files.
Perhaps for Xcode we can generate wrapper sources that conditionally
#include the real source based on the configuration.  Hopefully there
is a better way.

BTW, the hunk

-this-SetProperty(SOURCES, ss.str().c_str());
+this-SetProperty(SOURCES_INTERNAL, ss.str().c_str());
+return this-GetProperty(SOURCES_INTERNAL);

does not need to set an internal property.  We can just return the
string.  The only reason the old code set the property was to fall
through to the normal property lookup later in the method.

-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] target sources property

2013-07-10 Thread Stephen Kelly 
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 sources that conditionally
 #include the real source based on the configuration.  Hopefully there
 is a better way.

That doesn't sound very attractive indeed.

 BTW, the hunk
 
 -this-SetProperty(SOURCES, ss.str().c_str());
 +this-SetProperty(SOURCES_INTERNAL, ss.str().c_str());
 +return this-GetProperty(SOURCES_INTERNAL);
 
 does not need to set an internal property.  We can just return the
 string.  The only reason the old code set the property was to fall
 through to the normal property lookup later in the method.
 

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.

Thanks,

Steve.


--

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] target sources property

2013-07-10 Thread Brad King 
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 try to
abuse SOURCES_INTERNAL for something.  Elsewhere IIRC we have C++
class member variables specifically for this purpose.

-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] target sources property

2013-06-08 Thread Stephen Kelly 
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 see if 
I can introduce ignorance of $TARGET_OBJECTS:foo to 
set_source_files_properties.

Thanks,

Steve.



--

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] target sources property

2013-06-07 Thread Stephen Kelly 
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
 something else?
 
 Oops, yes I meant TARGET_OBJECTS.

And what is the trickyness with it?

Thanks,

Steve.


--

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] target sources property

2013-06-07 Thread Brad King 
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.  You'll find
out when you get there :)

-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] target sources property

2013-06-07 Thread Stephen Kelly 
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 than I think though.  You'll find
 out when you get there :)
 

I looked into it a bit and found that the SOURCES target property already 
exists. I was going to just add 



  
+for(std::vectorstd::string::iterator i = this-
ObjectLibraries.begin();   
  
+i != this-ObjectLibraries.end(); ++i) 

   
+  {

   
+  ss  sep;   

   
+  sep = ;;   

   
+  ss  $TARGET_OBJECTS: + *i + ;
+  }  

and make set_source_files_properties ignore entries of the form 
$TARGET_OBJECTS:foo, but I wonder if it would be better to create a new 
property?

Thanks,

Steve.


--

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] target sources property

2013-06-07 Thread Brad King 
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 
 
   
   
   
 +for(std::vectorstd::string::iterator i = this-
 ObjectLibraries.begin(); 
  

 +i != this-ObjectLibraries.end(); ++i)   
   

 +  {  
   

 +  ss  sep; 
   

 +  sep = ;; 
   

 +  ss  $TARGET_OBJECTS: + *i + ;
 +  }  
 
 and make set_source_files_properties ignore entries of the form 
 $TARGET_OBJECTS:foo, but I wonder if it would be better to create a new 
 property?

I wonder if we can use the SOURCES property but lift the read-only
restriction by special-casing the property storage similar to how
you do for include directories.  It should know the cmSourceFile*
internally but present the value as a path to the source file
as specified by the project in the property value.  Then replace
the ObjectLibraries member with another representation in the
special SOURCES property storage vector.

-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] target sources property

2013-06-07 Thread Stephen Kelly 
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
 
  
  
 
 +for(std::vectorstd::string::iterator i = this-
 ObjectLibraries.begin();
 +i != this-ObjectLibraries.end(); ++i)
 +  {
 +  ss  sep;
 +  sep = ;;
 +  ss  $TARGET_OBJECTS: + *i + ;
 +  }
 
 and make set_source_files_properties ignore entries of the form
 $TARGET_OBJECTS:foo, but I wonder if it would be better to create a new
 property?
 
 I wonder if we can use the SOURCES property but lift the read-only
 restriction by special-casing the property storage similar to how
 you do for include directories.  It should know the cmSourceFile*
 internally but present the value as a path to the source file
 as specified by the project in the property value.  Then replace
 the ObjectLibraries member with another representation in the
 special SOURCES property storage vector.
 

Yes, that was the plan sort of.

I guess I can't teach set_source_files_properties to ignore generator 
expressions entirely, because I guess you'd want to do this:

 set_property(TARGET foo APPEND PROPERTY 
   SOURCES $$CONFIG:Debug:other.cpp)
 get_target_property(srcs foo SOURCES)
 set_source_files_properties(${srcs} PROPERTIES ...)

So I guess set_source_files_properties needs to learn about generator 
expressions anyway, and it can skip over $TARGET_OBJECTS entries as it 
can't do anything useful with them.

Thanks,

Steve.


--

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] target sources property

2013-06-07 Thread Brad King 
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 
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] target sources property (was: Linking to OBJECT libraries?)

2013-06-06 Thread Brad King 
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 items of a target after 
 its creation, so I thought that would be disallowed for some reason.
 
 So, what we're talking about is something like a target property 
 SOURCE_ITEMS?
 
  # Only appending to this property allowed:
  set_property(TARGET foo APPEND PROPERTY 
SOURCE_ITEMS
  $TARGET_OBJECTS:bar
  somefile.cpp
  somecompileobject.o
  )
 
 and a corresponding INTERFACE_SOURCE_ITEMS which gets consumed from the link 
 interface?

Yes, something like this is what I had in mind.  I do not think we
need the append only requirement.  Instead we have two options:

(1) Name the property EXTRA_SOURCES and do not expose the
original sources at all so editing is not a problem.

(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 we already document such undefined
behavior for LINKER_LANGUAGE and other properties.

I think I prefer option (2) because it is more general.

Either way we will have a chicken-and-egg problem of things like
$LINK_LANGUAGE affecting this usage requirement which could
bring in sources that affect the link language.  IIRC you have
a similar problem for the WIN32_EXECUTABLE property.

Also it may be tricky due to the way $TARGET_SOURCES:... is
currently handled up front.

-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] target sources property

2013-06-06 Thread Stephen Kelly 
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 we already document such undefined
 behavior for LINKER_LANGUAGE and other properties.
 
 I think I prefer option (2) because it is more general.
 
 Either way we will have a chicken-and-egg problem of things like
 $LINK_LANGUAGE affecting this usage requirement which could
 bring in sources that affect the link language.

I think this is similar to the problem of adding an entry to the link 
libraries based on the value of POSITION_INDEPENDENT_CODE, which might be 
detmined by the INTERFACE_POSITION_INDEPENDENT_CODE of a dependent. That was 
solved with bf5ece51c3827dc05018128fefe8270da88cfefb (Keep track of 
properties used to determine linker libraries., 2012-11-05), which resolved 
the cycle by introducing an error. I recall a discussion about it, but I 
didn't try to find it.

I think we can do something similar in this case - Any properties used to 
determine the SOURCES have their value determined early and it will be an 
error to re-determine their value basd on the SOURCES.

 IIRC you have
 a similar problem for the WIN32_EXECUTABLE property.

You probably mean POSITION_INDEPENDENT_CODE. The only problem I have with 
the WIN32_EXECUTABLE property relates to the VS6 generator: 

 
https://gitorious.org/~steveire/cmake/steveires-cmake/commit/c1bc1fecb44c36a03d33e797703bbe72d0808ff1

 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?

Thanks,

Steve.


--

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] target sources property

2013-06-06 Thread Brad King 
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?

Oops, yes I meant TARGET_OBJECTS.

-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