Re: [cmake-developers] Should a module attempt to find its own dependencies?

2012-01-08 Thread Michael Wild 
On 01/09/2012 03:07 AM, David Cole wrote:
> 
> 
> On Sunday, January 8, 2012, Alexander Neundorf  > wrote:
>> On Sunday 08 January 2012, Stephen Kelly wrote:
>>> Alexander Neundorf wrote:
>>> > On Sunday 08 January 2012, Stephen Kelly wrote:
>>> >> Hi,
>>> >>
>>> >> I don't think I've ever seen a direct answer to this question.
>>> >
>>> > AFAIK, yes, they should.
>>> > FindKDE4Internal.cmake finds Qt, FindPNG.cmake finds zlib.
>>> >
>>> >> Is it something to be decided on a case by case basis? If so, then why
>>> >> is there no general case?
>>> >>
>>> >> I can see a possible reason that it is not solvable in the general
> case
>>> >> because sometimes the behaviour of find_package can be changed by
>>> >> setting variables (eg, one might use QT_USE_QTXMLPATTERNS before
>>> >> finding Qt4).
>>> >>
>>> >> Specifically this comes up for me because I need to know whether Qt5
>>> >> modules should find their own dependencies. That is, should
>>> >>
>>> >> find_package(Qt5Gui)
>>> >>
>>> >> cause
>>> >>
>>> >> find_package(Qt5Core REQUIRED)
>>> >>
>>> >> to be called or not?
>>> >
>>> > I'd say yes.
>>> > Otherwise the imported targets in Qt5Gui will depend on not yet defined
>>> > targets from Qt5Core.
>>> >
>>> > The same way cmake takes care of adding the required additional
> libraries
>>> > to the link line (like adding zlib when linking libpng), it should also
>>> > take care of this, IMO.
>>> >
>>> > You should just have to state
>>> > find_package(Foo)
>>> > and this will get you Foo.
>>>
>>> That implies that
>>>
>>> * Qt5Gui_INCLUDE_DIRS should also contain Qt5Core_INCLUDE_DIRS
>>>
>>> * Qt5Gui_DEFINITIONS should contain Qt5Core_DEFINITIONS
>>>
>>> * Qt5Gui_COMPILE_DEFINITIONS should contain Qt5Core_COMPILE_DEFINITIONS
>>>
>>> Right?
>>
>>
>> Yes, I'd say so.
>> But let's wait also for some opinions from others.
>>
>> Alex
>> --
>>
>> 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
>>
> 
> I'd say so too. Waiting for a dissenting opinion... ;-)

Not from me... I fully agree with Alex.

Michael

--

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 0012864]: CPackRPM additional variable CPACK_RPM_FILTER_FILELIST to remove well-known directories from %files list

2012-01-08 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=12864 
== 
Reported By:Deborah Pickett
Assigned To:
== 
Project:CMake
Issue ID:   12864
Category:   CPack
Reproducibility:N/A
Severity:   feature
Priority:   low
Status: new
== 
Date Submitted: 2012-01-08 22:44 EST
Last Modified:  2012-01-08 22:44 EST
== 
Summary:CPackRPM additional variable
CPACK_RPM_FILTER_FILELIST to remove well-known directories from %files list
Description: 
As discussed in 0012305, including well-known directories in an RPM .spec %files
list can lead to portability problems.

Example:

%files
/etc
/etc/init.d
/etc/init.d/mydaemon

The above innocuous snippet will lead to this unhelpful error when installing on
Red Hat (but not on Suse):

file /etc/init.d from install of mypackage-1.x86_64 conflicts with file from
package chkconfig-1.3.30.2-2.el5.x86_64

Portable RPMs need to omit "well-known" directories which are certain to be
installed on the destination system, like /usr, /etc, /etc/init.d, /dev.  This
is even more important when the directory is a symbolic link (like /etc/init.d)
or a special filesystem (like /dev).

Feature request: define a variable CPACK_RPM_FILTER_FILELIST which contains a
list of absolute paths that are to be suppressed from the %files list.  By
default it should contain "/usr";"/usr/lib";"/etc";"/etc/init.d";"/lib"
(negotiable).  Also allow user to define additional files/directories in
variable CPACK_RPM_FILTER_USER_FILELIST, which are treated similarly.

Additional Information: 
Probably depends on 0012863
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-01-08 22:44 Deborah PickettNew 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

[cmake-developers] [CMake 0012863]: CPackRPM reports "warning: File listed twice" because it recurses directories in %files

2012-01-08 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=12863 
== 
Reported By:Deborah Pickett
Assigned To:
== 
Project:CMake
Issue ID:   12863
Category:   CPack
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2012-01-08 22:27 EST
Last Modified:  2012-01-08 22:27 EST
== 
Summary:CPackRPM reports "warning: File listed twice"
because it recurses directories in %files
Description: 
During RPM packing, the %files list in the .spec file contains all directory
ancestors of installed files (i.e., it includes /usr and /usr/bin as well as
/usr/bin/foo).  Because unadorned entries in %files that are directories will be
recursively searched, this causes /usr to bring in /usr/bin and /usr/bin/foo
again, and /usr/bin to bring in /usr/bin/foo again-again.  rpmbuld reports this
with "warning: File listed twice: /usr/bin/foo".

Steps to Reproduce: 
Pack any RPM that installs to a directory at least two levels under / (e.g.,
/usr/bin/foo).  Pack with debugging on: cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G
RPM

Additional Information: 
%dir directive for RPM spec:
http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-DIR-DIRECTIVE
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-01-08 22:27 Deborah PickettNew 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] Should a module attempt to find its own dependencies?

2012-01-08 Thread David Cole 
On Sunday, January 8, 2012, Alexander Neundorf  wrote:
> On Sunday 08 January 2012, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>> > On Sunday 08 January 2012, Stephen Kelly wrote:
>> >> Hi,
>> >>
>> >> I don't think I've ever seen a direct answer to this question.
>> >
>> > AFAIK, yes, they should.
>> > FindKDE4Internal.cmake finds Qt, FindPNG.cmake finds zlib.
>> >
>> >> Is it something to be decided on a case by case basis? If so, then why
>> >> is there no general case?
>> >>
>> >> I can see a possible reason that it is not solvable in the general
case
>> >> because sometimes the behaviour of find_package can be changed by
>> >> setting variables (eg, one might use QT_USE_QTXMLPATTERNS before
>> >> finding Qt4).
>> >>
>> >> Specifically this comes up for me because I need to know whether Qt5
>> >> modules should find their own dependencies. That is, should
>> >>
>> >> find_package(Qt5Gui)
>> >>
>> >> cause
>> >>
>> >> find_package(Qt5Core REQUIRED)
>> >>
>> >> to be called or not?
>> >
>> > I'd say yes.
>> > Otherwise the imported targets in Qt5Gui will depend on not yet defined
>> > targets from Qt5Core.
>> >
>> > The same way cmake takes care of adding the required additional
libraries
>> > to the link line (like adding zlib when linking libpng), it should also
>> > take care of this, IMO.
>> >
>> > You should just have to state
>> > find_package(Foo)
>> > and this will get you Foo.
>>
>> That implies that
>>
>> * Qt5Gui_INCLUDE_DIRS should also contain Qt5Core_INCLUDE_DIRS
>>
>> * Qt5Gui_DEFINITIONS should contain Qt5Core_DEFINITIONS
>>
>> * Qt5Gui_COMPILE_DEFINITIONS should contain Qt5Core_COMPILE_DEFINITIONS
>>
>> Right?
>
>
> Yes, I'd say so.
> But let's wait also for some opinions from others.
>
> Alex
> --
>
> 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
>

I'd say so too. Waiting for a dissenting opinion... ;-)
--

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_include_directories branch in stage

2012-01-08 Thread David Cole 
On Sunday, January 8, 2012, Stephen Kelly  wrote:
> On 12/05/2011 03:17 PM, Brad King wrote:
>>
>> On 12/4/2011 12:49 PM, Stephen Kelly wrote:
>>>
>>> I've pushed the branch to my gitorious clone again.
>>>
>>> https://gitorious.org/~steveire/cmake/steveires-cmake
>
> Hi,
>
> I'm revisiting this now that CMake 2.8.7 is out.
>
> I've force pushed my branch:
>
>
https://gitorious.org/~steveire/cmake/steveires-cmake/commits/target-include-directories
>
> For context, the branch as it was on December 4th is preserved here:
>
>
https://gitorious.org/~steveire/cmake/steveires-cmake/commits/target-include-directories-old
>
>>
>> Thanks.  Why do you maintain a special std::vector member
>> to hold the INCLUDE_DIRECTORIES target property?
>
> Mostly to simplify the implementation so that I don't need to serialize
and de-serialize in multiple places. I also figured it must be faster to
serialize and deserialize over const char * all the time in the multiple
places that is needed.
>
>
>> I think the property
>> can be stored just like any other property during configuration.  Then
>> the generators can use ExpandListArguments.
>
> Would that mean that every generator would have to ensure that the
includes were unique etc?
>
>> Initialization from the
>> directory property value can just be added to cmTarget::SetMakefile:
>>
>>  this->SetPropertyDefault("INCLUDE_DIRECTORIES", 0);
>>
>
> I tried this (also removing this->IncludeDirectories = makefileIncludes;
from the same function), and it makes the tests fail. This doesn't surprise
me, as as far as I knew and read from the code, SetPropertyDefault is for
initializing a property with the content of the property with the same name
with a "CMAKE_" prefix.
>
> If I've understood what you meant here, please expand.
>
>> The directory-level IncludeDirectories vector can probably also go
>> away in favor of a normal directory property if things are properly
>> refactored.
>>
>>> The top two commits need to be reviewed and have real fixes decided and
>>> written for them. Should the memoization be removed?
>
> I have removed the last two commits from the branch and added a separate
commit to remove the memoization.
>
> Once again, the tests all pass for me. However, I have only tested with
the "Unix Makefile" generator. The other generators (eg for Windows, Mac?)
likely do not work.
>
> How can this feature now be moved forward? Do I need to convince someone
to volunteer to port the other generators? Should I just file a bug for
porting the other generators and wait (possibly making the feature bitrot)?
>
> 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
>

I volunteer to make sure this branch works with Xcode and Visual Studio.
I'll get to it within the next week...

Thx,
David
--

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] Should a module attempt to find its own dependencies?

2012-01-08 Thread Alexander Neundorf 
On Sunday 08 January 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Sunday 08 January 2012, Stephen Kelly wrote:
> >> Hi,
> >> 
> >> I don't think I've ever seen a direct answer to this question.
> > 
> > AFAIK, yes, they should.
> > FindKDE4Internal.cmake finds Qt, FindPNG.cmake finds zlib.
> > 
> >> Is it something to be decided on a case by case basis? If so, then why
> >> is there no general case?
> >> 
> >> I can see a possible reason that it is not solvable in the general case
> >> because sometimes the behaviour of find_package can be changed by
> >> setting variables (eg, one might use QT_USE_QTXMLPATTERNS before
> >> finding Qt4).
> >> 
> >> Specifically this comes up for me because I need to know whether Qt5
> >> modules should find their own dependencies. That is, should
> >> 
> >> find_package(Qt5Gui)
> >> 
> >> cause
> >> 
> >> find_package(Qt5Core REQUIRED)
> >> 
> >> to be called or not?
> > 
> > I'd say yes.
> > Otherwise the imported targets in Qt5Gui will depend on not yet defined
> > targets from Qt5Core.
> > 
> > The same way cmake takes care of adding the required additional libraries
> > to the link line (like adding zlib when linking libpng), it should also
> > take care of this, IMO.
> > 
> > You should just have to state
> > find_package(Foo)
> > and this will get you Foo.
> 
> That implies that
> 
> * Qt5Gui_INCLUDE_DIRS should also contain Qt5Core_INCLUDE_DIRS
> 
> * Qt5Gui_DEFINITIONS should contain Qt5Core_DEFINITIONS
> 
> * Qt5Gui_COMPILE_DEFINITIONS should contain Qt5Core_COMPILE_DEFINITIONS
> 
> Right?


Yes, I'd say so.
But let's wait also for some opinions from others.

Alex
--

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] Should a module attempt to find its own dependencies?

2012-01-08 Thread Stephen Kelly 
Alexander Neundorf wrote:

> On Sunday 08 January 2012, Stephen Kelly wrote:
>> Hi,
>> 
>> I don't think I've ever seen a direct answer to this question.
> 
> AFAIK, yes, they should.
> FindKDE4Internal.cmake finds Qt, FindPNG.cmake finds zlib.
> 
> 
>> Is it something to be decided on a case by case basis? If so, then why is
>> there no general case?
>> 
>> I can see a possible reason that it is not solvable in the general case
>> because sometimes the behaviour of find_package can be changed by setting
>> variables (eg, one might use QT_USE_QTXMLPATTERNS before finding Qt4).
>> 
>> Specifically this comes up for me because I need to know whether Qt5
>> modules should find their own dependencies. That is, should
>> 
>> find_package(Qt5Gui)
>> 
>> cause
>> 
>> find_package(Qt5Core REQUIRED)
>> 
>> to be called or not?
> 
> I'd say yes.
> Otherwise the imported targets in Qt5Gui will depend on not yet defined
> targets from Qt5Core.
> 
> The same way cmake takes care of adding the required additional libraries
> to the link line (like adding zlib when linking libpng), it should also
> take care of this, IMO.
> 
> You should just have to state
> find_package(Foo)
> and this will get you Foo.

That implies that 

* Qt5Gui_INCLUDE_DIRS should also contain Qt5Core_INCLUDE_DIRS

* Qt5Gui_DEFINITIONS should contain Qt5Core_DEFINITIONS

* Qt5Gui_COMPILE_DEFINITIONS should contain Qt5Core_COMPILE_DEFINITIONS

Right? 

(for the libraries, the dependencies are already part of the link 
dependencies variable).

Otherwise you would be doing this:

find_package(Foo)
include_directories(
  ${Foo_INCLUDE_DIRS}
  ${Bar_INCLUDE_DIRS} # Where does this come from ??
)

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] Should a module attempt to find its own dependencies?

2012-01-08 Thread Alexander Neundorf 
On Sunday 08 January 2012, Stephen Kelly wrote:
> Hi,
> 
> I don't think I've ever seen a direct answer to this question. 

AFAIK, yes, they should.
FindKDE4Internal.cmake finds Qt, FindPNG.cmake finds zlib.


> Is it something to be decided on a case by case basis? If so, then why is
> there no general case?
> 
> I can see a possible reason that it is not solvable in the general case
> because sometimes the behaviour of find_package can be changed by setting
> variables (eg, one might use QT_USE_QTXMLPATTERNS before finding Qt4).
> 
> Specifically this comes up for me because I need to know whether Qt5
> modules should find their own dependencies. That is, should
> 
> find_package(Qt5Gui)
> 
> cause
> 
> find_package(Qt5Core REQUIRED)
> 
> to be called or not? 

I'd say yes.
Otherwise the imported targets in Qt5Gui will depend on not yet defined 
targets from Qt5Core.

The same way cmake takes care of adding the required additional libraries to 
the link line (like adding zlib when linking libpng), it should also take care 
of this, IMO.

You should just have to state
find_package(Foo)
and this will get you Foo.

Alex
--

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] Should a module attempt to find its own dependencies?

2012-01-08 Thread Stephen Kelly 

Hi,

I don't think I've ever seen a direct answer to this question. Is it 
something to be decided on a case by case basis? If so, then why is there no 
general case? 

I can see a possible reason that it is not solvable in the general case 
because sometimes the behaviour of find_package can be changed by setting 
variables (eg, one might use QT_USE_QTXMLPATTERNS before finding Qt4).

Specifically this comes up for me because I need to know whether Qt5 modules 
should find their own dependencies. That is, should 

find_package(Qt5Gui)

cause 

find_package(Qt5Core REQUIRED) 

to be called or not? Should that be the responsibility of the caller?

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_include_directories branch in stage

2012-01-08 Thread Stephen Kelly 

On 12/05/2011 03:17 PM, Brad King wrote:

On 12/4/2011 12:49 PM, Stephen Kelly wrote:

I've pushed the branch to my gitorious clone again.

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


Hi,

I'm revisiting this now that CMake 2.8.7 is out.

I've force pushed my branch:

https://gitorious.org/~steveire/cmake/steveires-cmake/commits/target-include-directories

For context, the branch as it was on December 4th is preserved here:

https://gitorious.org/~steveire/cmake/steveires-cmake/commits/target-include-directories-old



Thanks.  Why do you maintain a special std::vector member
to hold the INCLUDE_DIRECTORIES target property? 


Mostly to simplify the implementation so that I don't need to serialize 
and de-serialize in multiple places. I also figured it must be faster to 
serialize and deserialize over const char * all the time in the multiple 
places that is needed.




I think the property
can be stored just like any other property during configuration.  Then
the generators can use ExpandListArguments. 


Would that mean that every generator would have to ensure that the 
includes were unique etc?



Initialization from the
directory property value can just be added to cmTarget::SetMakefile:

  this->SetPropertyDefault("INCLUDE_DIRECTORIES", 0);



I tried this (also removing this->IncludeDirectories = makefileIncludes; 
from the same function), and it makes the tests fail. This doesn't 
surprise me, as as far as I knew and read from the code, 
SetPropertyDefault is for initializing a property with the content of 
the property with the same name with a "CMAKE_" prefix.


If I've understood what you meant here, please expand.


The directory-level IncludeDirectories vector can probably also go
away in favor of a normal directory property if things are properly
refactored.


The top two commits need to be reviewed and have real fixes decided and
written for them. Should the memoization be removed?


I have removed the last two commits from the branch and added a separate 
commit to remove the memoization.


Once again, the tests all pass for me. However, I have only tested with 
the "Unix Makefile" generator. The other generators (eg for Windows, 
Mac?) likely do not work.


How can this feature now be moved forward? Do I need to convince someone 
to volunteer to port the other generators? Should I just file a bug for 
porting the other generators and wait (possibly making the feature bitrot)?


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

[cmake-developers] [CMake 0012862]: Syntax not documented

2012-01-08 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=12862 
== 
Reported By:manday
Assigned To:
== 
Project:CMake
Issue ID:   12862
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2012-01-08 09:58 EST
Last Modified:  2012-01-08 09:58 EST
== 
Summary:Syntax not documented
Description: 
I suggest that the documentation of commands, variables and properties is
removed from the manpage and the manpage is dedicated to command line synopsis
and CMakeList.txt-file-syntax, only - something which currently isn't documented
anywhere, as it seems, while the commands are more fully documented by
--help-command-list, already.

For example the use of variables and their expansion is explained nowhere.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-01-08 09:58 manday 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