Re: [cmake-developers] patch for cmake that adds a new timestamp command
Why is TIMESTAMP misleading? Per default it currently outputs year, month, day, hour, minute and second. This includes both a date (a day on a calendar) as well as time (time of day). Timestamp I'd define as both date and time bound to an event (here the call or the (sub-)command). Date I'd consider inaccurate since it implies that there is no time resolution. Time I'd say would be slightly more accurate since it has higher precision and it matches the naming in C (time_t, tm, strftime ...). DateTime Is accurate and has precedence (e.g. SQL) but is (IMO) not as pretty. To list them in order of personal preference this would for me give: Timestamp, DateTime, Time, Date Nils On 09/27/2012 07:41 PM, Eric Noulard wrote: 2012/9/27 David Cole david.c...@kitware.com: H. Good idea. Should we add a new command for this? Or should it be a sub-command of string( like RANDOM is? And... while we're at it, I've always thought we should add the ability to get the creation/modified/access times from a file via the CMake file command. If we allow getting the current time, we should leverage some of the same transformation-to-string code in the file command to get the various times associated with a file. What do other devs here think: New command or string sub-command for this functionality? string sub-command for me, and agreed with Brad as well for the namespace thing. agreed with file(...) extension as well. that said isn't the TIMESTAMP misleading? shouldn't it be called DATE instead? -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung GmbH Bertha-von-Suttner-Str. 5 D-37085 Göttingen GERMANY Handelsregister Nr. / Trade Register No. B3100 Göttingen Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland Tel: 0049 (0)551 634181-28 E-Mail: glad...@scivis.de Web: www.scivis.de -- 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] patch for cmake that adds a new timestamp command
On Fri, Sep 28, 2012 at 2:28 AM, Nils Gladitz glad...@sci-vis.de wrote:
Why is TIMESTAMP misleading?
Per default it currently outputs year, month, day, hour, minute and second.
This includes both a date (a day on a calendar) as well as time (time of
day).
Timestamp I'd define as both date and time bound to an event (here the
call or the (sub-)command).
Date I'd consider inaccurate since it implies that there is no time
resolution.
Time I'd say would be slightly more accurate since it has higher
precision and it matches the naming in C (time_t, tm, strftime ...).
DateTime Is accurate and has precedence (e.g. SQL) but is (IMO) not as
pretty.
To list them in order of personal preference this would for me give:
Timestamp, DateTime, Time, Date
Nils
On 09/27/2012 07:41 PM, Eric Noulard wrote:
2012/9/27 David Cole david.c...@kitware.com:
H. Good idea.
Should we add a new command for this? Or should it be a sub-command of
string( like RANDOM is?
And... while we're at it, I've always thought we should add the
ability to get the creation/modified/access times from a file via the
CMake file command. If we allow getting the current time, we should
leverage some of the same transformation-to-string code in the file
command to get the various times associated with a file.
What do other devs here think:
New command or string sub-command for this functionality?
string sub-command for me, and agreed with Brad as well
for the namespace thing.
agreed with file(...) extension as well.
that said isn't the TIMESTAMP misleading?
shouldn't it be called DATE instead?
--
Nils Gladitz, B.Sc.
DICOM, Konnektivität und Entwicklung
Scivis wissenschaftliche Bildverarbeitung GmbH
Bertha-von-Suttner-Str. 5
D-37085 Göttingen
GERMANY
Handelsregister Nr. / Trade Register No. B3100 Göttingen
Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland
Tel: 0049 (0)551 634181-28
E-Mail: glad...@scivis.de
Web: www.scivis.de
--
Powered by www.kitware.com
Visit other Kitware open-source projects at http://www.kitware.com/**
opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
I agree with Nils here. I like Timestamp or DateTime best since it has
resolution down to (at least) the second.
Nils, we do not have a formal definition of coding style written out
anywhere.
To summarize our expectations briefly, though, I'd say this:
When modifying existing files, try to blend in with the existing style.
When editing C++ source or header files, keep line length under 80
characters per line. When adding a new file, copy the style from another
file nearby. With *.cmake files, please use lowercase commands. When
defining functions or macros in the CMake language, use ${FileName}_ as a
prefix for functions defined in a *.cmake file, where FileName.cmake is the
name of the containing file.
And ask questions here if there's anything that's unclear.
Thanks,
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] patch for cmake that adds a new timestamp command
Am 2012-09-28 08:44, schrieb Nils Gladitz:
Sorry about the indentation ... I've still got a bit of trouble
switching between coding conventions.
Yeah, kernel style is the only sane one ;)
On that note, are there documented coding conventions, coding
guidelines or similar somewhere?
My point here was that the code between some if's {} was at the same
level as the if, at least on some places, but not on all.
--
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] Exporting dependent library targets in multiple export sets
On 09/24/2012 08:19 AM, Brad King wrote:
On 09/23/2012 01:22 PM, Alexander Neundorf wrote:
This is now in the export-sets-2 branch on stage, including a basic test.
Comments ? Ok to merge into next ?
Yes, thanks.
This commit is a problem:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=21d1619b
--
diff --git a/Tests/ExportImport/Import/A/CMakeLists.txt
b/Tests/ExportImport/Import/A/CMakeLists.txt
index 650af6a..ca7a67a 100644
--- a/Tests/ExportImport/Import/A/CMakeLists.txt
+++ b/Tests/ExportImport/Import/A/CMakeLists.txt
@@ -1,8 +1,9 @@
+# Import targets from the exported install tree.
+include(${CMAKE_INSTALL_PREFIX}/lib/exp/exp.cmake)
+
# Import targets from the exported build tree.
include(${Import_BINARY_DIR}/../Export/ExportBuildTree.cmake)
-# Import targets from the exported install tree.
-include(${CMAKE_INSTALL_PREFIX}/lib/exp/exp.cmake)
# Try referencing an executable imported from the install tree.
add_custom_command(
--
The test has no dependence between exports from the build tree and
exports from the install tree. The new cross-export dependency
finding logic is artificially connecting them.
Export sets created by export() and those created by install()
should be *independent* groups. They cannot cross. It does not
make sense to have a build tree refer to its own install tree or
vice versa.
-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] Exporting dependent library targets in multiple export sets
On Friday 28 September 2012, Brad King wrote:
On 09/24/2012 08:19 AM, Brad King wrote:
On 09/23/2012 01:22 PM, Alexander Neundorf wrote:
This is now in the export-sets-2 branch on stage, including a basic
test.
Comments ? Ok to merge into next ?
Yes, thanks.
This commit is a problem:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=21d1619b
--
diff --git a/Tests/ExportImport/Import/A/CMakeLists.txt
b/Tests/ExportImport/Import/A/CMakeLists.txt index 650af6a..ca7a67a 100644
--- a/Tests/ExportImport/Import/A/CMakeLists.txt
+++ b/Tests/ExportImport/Import/A/CMakeLists.txt
@@ -1,8 +1,9 @@
+# Import targets from the exported install tree.
+include(${CMAKE_INSTALL_PREFIX}/lib/exp/exp.cmake)
+
# Import targets from the exported build tree.
include(${Import_BINARY_DIR}/../Export/ExportBuildTree.cmake)
-# Import targets from the exported install tree.
-include(${CMAKE_INSTALL_PREFIX}/lib/exp/exp.cmake)
# Try referencing an executable imported from the install tree.
add_custom_command(
--
The test has no dependence between exports from the build tree and
exports from the install tree. The new cross-export dependency
finding logic is artificially connecting them.
Export sets created by export() and those created by install()
should be *independent* groups. They cannot cross. It does not
make sense to have a build tree refer to its own install tree or
vice versa.
Hmm.
The imported target bld_testExe2lib in ExportBuildTree.cmake links against the
imported target exp_testExe2libImp created in exp.cmake.
So if exp.cmake is included after ExportBuildTree.cmake this imported library
does not exist yet.
This sounds like a real dependency to me, not an artificial one.
So changing the order seems to me like the right thing to do.
How should an imported target created via export() behave in your opinion ?
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] Exporting dependent library targets in multiple export sets
On 09/28/2012 01:21 PM, Alexander Neundorf wrote: The imported target bld_testExe2lib in ExportBuildTree.cmake links against the imported target exp_testExe2libImp created in exp.cmake. So if exp.cmake is included after ExportBuildTree.cmake this imported library does not exist yet. This sounds like a real dependency to me, not an artificial one. I wrote the test originally. It is not a real dependency. The exp_ and bld_ namespaces should be completely separate. One is from install(EXPORT). One is from export(). The export() case does some targets first and then the rest of them via export(APPEND): export(TARGETS ... testExe2libImp ... NAMESPACE bld_ FILE ExportBuildTree.cmake) export(TARGETS ... testExe2lib ... NAMESPACE bld_ APPEND FILE ExportBuildTree.cmake) The APPEND mode should be appending to the existing export set with the same namespace. Currently the second call is looking at testExe2lib and trying to find another export that provides its dependency testExe2libImp. It is incorrectly finding the exp_ install(EXPORT) for testExe2libImp. This is where the artificial dependency is getting introduced by the C++ code. So changing the order seems to me like the right thing to do. It is not. It is wrong. The C++ code needs to be fixed. The change to the test needs to be reverted. How should an imported target created via export() behave in your opinion ? I'm saying that an *export set* created by export() should not be something that install(EXPORT) can search while looking for dependencies, and vice versa. -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] Exporting dependent library targets in multiple export sets
On Friday 28 September 2012, Brad King wrote: On 09/28/2012 01:21 PM, Alexander Neundorf wrote: The imported target bld_testExe2lib in ExportBuildTree.cmake links against the imported target exp_testExe2libImp created in exp.cmake. So if exp.cmake is included after ExportBuildTree.cmake this imported library does not exist yet. This sounds like a real dependency to me, not an artificial one. I wrote the test originally. It is not a real dependency. The exp_ and bld_ namespaces should be completely separate. One is from install(EXPORT). One is from export(). Ok, I see. ... working on it. 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] merge session today
The following topic branches were merged to master and deleted from the stage today: $ git fetch --all --prune Fetching origin Fetching stage From git://cmake.org/stage/cmake 64d64b4..908f46a master - stage/master x [deleted] (none) - stage/ctest-svn-non-interactive x [deleted] (none) - stage/fix-13549-make-findmpi-quiet x [deleted] (none) - stage/ninja-OBJECT_DEPENDS The following branches were NOT merged because of failing tests and/or changes that occurred today and still need testing on the overnight dashboard runs: # vs-pdb-output | master=0 next=1 # ninja-LIBPATH | master=0 next=1 # ninja-link-rsp-expand | master=0 next=1 See the test failures here: http://open.cdash.org/queryTests.php?project=CMakedate=20120928limit=200filtercount=1showfilters=1limit=200field1=status/stringcompare1=61value1=Failed (especially the ninja-related LinkDirectory test failures and the pdb-related PDBDirectoryAndName test failures) The following branches still need some more work. If they're ready by Monday, we can still get them into 2.8.10-rc1 -- if not, we're going to have to push these features into the next release instead. # generator-expression-target-properties | master=0 next=1 # export-sets-2 | master=0 next=1 The following branches are NOT intended for 2.8.10-rc1 # find_library-NAMES_PER_DIR | master=0 next=1 # generate_export_header-fixes | master=0 next=0 Cheers: have a great weekend! David C. -- 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] merge session today
By the way, the KWStyle fixes are already done. If you are going to extend any of the existing stage topics, please fetch them and sync with the stage first. Thanks, D On Fri, Sep 28, 2012 at 4:08 PM, David Cole david.c...@kitware.com wrote: The following topic branches were merged to master and deleted from the stage today: $ git fetch --all --prune Fetching origin Fetching stage From git://cmake.org/stage/cmake 64d64b4..908f46a master - stage/master x [deleted] (none) - stage/ctest-svn-non-interactive x [deleted] (none) - stage/fix-13549-make-findmpi-quiet x [deleted] (none) - stage/ninja-OBJECT_DEPENDS The following branches were NOT merged because of failing tests and/or changes that occurred today and still need testing on the overnight dashboard runs: # vs-pdb-output | master=0 next=1 # ninja-LIBPATH | master=0 next=1 # ninja-link-rsp-expand | master=0 next=1 See the test failures here: http://open.cdash.org/queryTests.php?project=CMakedate=20120928limit=200filtercount=1showfilters=1limit=200field1=status/stringcompare1=61value1=Failed (especially the ninja-related LinkDirectory test failures and the pdb-related PDBDirectoryAndName test failures) The following branches still need some more work. If they're ready by Monday, we can still get them into 2.8.10-rc1 -- if not, we're going to have to push these features into the next release instead. # generator-expression-target-properties | master=0 next=1 # export-sets-2 | master=0 next=1 The following branches are NOT intended for 2.8.10-rc1 # find_library-NAMES_PER_DIR | master=0 next=1 # generate_export_header-fixes | master=0 next=0 Cheers: have a great weekend! David C. -- 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] merge session today
On Friday 28 September 2012, David Cole wrote: ... The following branches still need some more work. If they're ready by Monday, we can still get them into 2.8.10-rc1 -- if not, we're going to have to push these features into the next release instead. # generator-expression-target-properties | master=0 next=1 # export-sets-2 | master=0 next=1 There is an updated version now on stage. 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] Exporting dependent library targets in multiple export sets
On Friday 28 September 2012, Alexander Neundorf wrote: On Friday 28 September 2012, Brad King wrote: On 09/28/2012 01:21 PM, Alexander Neundorf wrote: The imported target bld_testExe2lib in ExportBuildTree.cmake links against the imported target exp_testExe2libImp created in exp.cmake. So if exp.cmake is included after ExportBuildTree.cmake this imported library does not exist yet. This sounds like a real dependency to me, not an artificial one. I wrote the test originally. It is not a real dependency. The exp_ and bld_ namespaces should be completely separate. One is from install(EXPORT). One is from export(). Ok, I see. ... working on it. There is an updated version now on stage. The behaviour of cmExportBuildFileGenerator now basically is the same as it was before. The collected target exports are not considered at all anymore, error handling and APPEND mode should work again exactly as before. The code for handling missing targets has moved into a virtual function HandleMissingTargets(), which makes it IMO easier to handle all combinations correctly. ComplainAboutMissingTarget() is not virtual anymore now. The test works again as before. 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] merge session today
David Cole wrote: The following branches still need some more work. If they're ready by Monday, we can still get them into 2.8.10-rc1 -- if not, we're going to have to push these features into the next release instead. # generator-expression-target-properties | master=0 next=1 You'll have to be a bit more specific. What more work is needed? 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] merge session today
On 09/28/2012 04:22 PM, Stephen Kelly wrote: David Cole wrote: The following branches still need some more work. If they're ready by Monday, we can still get them into 2.8.10-rc1 -- if not, we're going to have to push these features into the next release instead. # generator-expression-target-properties | master=0 next=1 You'll have to be a bit more specific. What more work is needed? That topic is done but it's tangled with Alex's export-sets topic a bit. I'll handle it. -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] merge session today
Brad King wrote: On 09/28/2012 04:22 PM, Stephen Kelly wrote: David Cole wrote: The following branches still need some more work. If they're ready by Monday, we can still get them into 2.8.10-rc1 -- if not, we're going to have to push these features into the next release instead. # generator-expression-target-properties | master=0 next=1 You'll have to be a bit more specific. What more work is needed? That topic is done but it's tangled with Alex's export-sets topic a bit. I'll handle it. The generator-expression-target-properties branch merges to master cleanly. The export-sets-2 branch was never merged into it. I don't understand what blocked merging it to master, but I'll leave it up to you to handle. 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] Exporting dependent library targets in multiple export sets
On 09/28/2012 04:21 PM, Alexander Neundorf wrote: There is an updated version now on stage. The behaviour of cmExportBuildFileGenerator now basically is the same as it was before. The collected target exports are not considered at all anymore, error handling and APPEND mode should work again exactly as before. The code for handling missing targets has moved into a virtual function HandleMissingTargets(), which makes it IMO easier to handle all combinations correctly. ComplainAboutMissingTarget() is not virtual anymore now. The test works again as before. Thanks. I amended the commit to fix some indentation. Then I merged it to 'next' for testing. After this the install(EXPORT) sets will chain automatically. However, export() will not because nothing records the build tree exports globally at all. I think this is okay for now. Thanks, -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] Exporting dependent library targets in multiple export sets
On 09/28/2012 04:56 PM, Brad King wrote: On 09/28/2012 04:21 PM, Alexander Neundorf wrote: There is an updated version now on stage. The behaviour of cmExportBuildFileGenerator now basically is the same as it was before. The collected target exports are not considered at all anymore, error handling and APPEND mode should work again exactly as before. The code for handling missing targets has moved into a virtual function HandleMissingTargets(), which makes it IMO easier to handle all combinations correctly. ComplainAboutMissingTarget() is not virtual anymore now. The test works again as before. Thanks. I amended the commit to fix some indentation. Then I merged it to 'next' for testing. After this the install(EXPORT) sets will chain automatically. However, export() will not because nothing records the build tree exports globally at all. I think this is okay for now. After rewriting the generator-expression-target-properties topic I was able to rewrite/squash the export-sets-2 topic and replace it with a new export-sets topic that does not merge in the generator-expression-target-properties changes at all. I removed the export-sets-2 topic from the stage. The export-sets topic makes an identical change. If further changes are needed please check out that branch and commit there. Do not add any more commits to the original export-sets-2 history. Thanks, -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] merge session today
On 09/28/2012 04:35 PM, Stephen Kelly wrote: The generator-expression-target-properties branch merges to master cleanly. The export-sets-2 branch was never merged into it. I don't understand what blocked merging it to master, but I'll leave it up to you to handle. I rewrote/squashed generator-expression-target-properties and merged to master. I replaced export-sets-2 with a rewritten version export-sets that does not merge your topic in. -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
