Re: [cmake-developers] Anyone going to FOSDEM?
Hi Steve, Zitat von Stephen Kelly <steve...@gmail.com>: Benjamin Eikel wrote: Hi Gregor, Am Mittwoch, 30. Dezember 2015, 14:33:08 schrieb Gregor Jasny via cmake- developers: Hello, I wonder if any of you CMake Developers go to FOSDEM [1] this year? I am not a CMake developer, but, more or less, an advanced user, but I will go to FOSDEM next year. ;-) At least Stephen Kelly [2] will be there, too. Yep. Maybe we could arrange to meet in the Sunday evening. I leave on the Monday. unfortunately, I will leave already on Sunday. But we can have a chat directly after your talk. Cheers Benjamin Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Anyone going to FOSDEM?
Hi Gregor, Am Mittwoch, 30. Dezember 2015, 14:33:08 schrieb Gregor Jasny via cmake- developers: > Hello, > > I wonder if any of you CMake Developers go to FOSDEM [1] this year? I am not a CMake developer, but, more or less, an advanced user, but I will go to FOSDEM next year. ;-) At least Stephen Kelly [2] will be there, too. Kind regards Benjamin [2] https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Best practices questions
Hello, Am Dienstag, 16. Oktober 2012 um 16:36:49 schrieb Petr Kmoch: 2) Is there a code style document I could read somewhere? I now understand line width is preferred at 79 columns max. and I believe I've figured out brace indenting; anything else I should follow? for writing CMake code I have created a configuration file for Uncrustify [1]. I have attached it to this e-mail. It was created for my personal use and is not official. But maybe it is helpful to someone. If there is going to be some interest, one could think about putting it in a repository somewhere. Kind regards Benjamin [1] http://uncrustify.sourceforge.net/ tok_split_gte=false utf8_byte=false utf8_force=false indent_cmt_with_tabs=false indent_align_string=false indent_braces=true indent_braces_no_func=true indent_braces_no_class=true indent_braces_no_struct=true indent_brace_parent=false indent_namespace=false indent_extern=false indent_class=false indent_class_colon=false indent_else_if=false indent_var_def_cont=false indent_func_call_param=false indent_func_def_param=false indent_func_proto_param=false indent_func_class_param=false indent_func_ctor_var_param=false indent_template_param=false indent_func_param_double=false indent_relative_single_line_comments=false indent_col1_comment=false indent_access_spec_body=true indent_paren_nl=false indent_comma_paren=false indent_bool_paren=false indent_first_bool_expr=false indent_square_nl=false indent_preserve_sql=false indent_align_assign=true sp_balance_nested_parens=false align_keep_tabs=false align_with_tabs=false align_on_tabstop=false align_number_left=false align_func_params=false align_same_func_call_params=false align_var_def_colon=false align_var_def_attribute=false align_var_def_inline=false align_right_cmt_mix=false align_on_operator=false align_mix_var_proto=false align_single_line_func=false align_single_line_brace=false align_nl_cont=false align_left_shift=true align_oc_decl_colon=false nl_collapse_empty_body=false nl_assign_leave_one_liners=false nl_class_leave_one_liners=false nl_enum_leave_one_liners=false nl_getset_leave_one_liners=false nl_func_leave_one_liners=false nl_if_leave_one_liners=false nl_multi_line_cond=false nl_multi_line_define=false nl_before_case=false nl_after_case=false nl_after_return=false nl_after_semicolon=true nl_after_brace_open=false nl_after_brace_open_cmt=false nl_after_vbrace_open=false nl_after_vbrace_open_empty=false nl_after_brace_close=false nl_after_vbrace_close=false nl_define_macro=false nl_squeeze_ifdef=false nl_ds_struct_enum_cmt=false nl_ds_struct_enum_close_brace=false nl_create_if_one_liner=false nl_create_for_one_liner=false nl_create_while_one_liner=false ls_for_split_full=false ls_func_split_full=false nl_after_multiline_comment=false eat_blanks_after_open_brace=false eat_blanks_before_close_brace=false mod_full_brace_if_chain=false mod_pawn_semicolon=false mod_full_paren_if_bool=false mod_remove_extra_semicolon=true mod_sort_import=false mod_sort_using=false mod_sort_include=false mod_move_case_break=false mod_remove_empty_return=true cmt_indent_multi=false cmt_c_group=false cmt_c_nl_start=false cmt_c_nl_end=false cmt_cpp_group=false cmt_cpp_nl_start=false cmt_cpp_nl_end=false cmt_cpp_to_c=false cmt_star_cont=true cmt_multi_check_last=false cmt_insert_before_preproc=false pp_indent_at_level=false pp_region_indent_code=false pp_if_indent_code=false pp_define_at_level=false output_tab_size=2 indent_columns=2 indent_switch_case=2 nl_end_of_file_min=1 code_width=79 indent_with_tabs=0 sp_arith=force sp_assign=force sp_bool=force sp_compare=force sp_inside_paren=remove sp_paren_paren=remove sp_paren_brace=force sp_before_ptr_star=add sp_before_unnamed_ptr_star=add sp_between_ptr_star=force sp_after_ptr_star=force sp_before_byref=force sp_before_unnamed_byref=remove sp_after_byref=force sp_after_type=force sp_template_angle=remove sp_before_angle=remove sp_inside_angle=remove sp_after_angle=remove sp_angle_paren=remove sp_angle_word=force sp_before_sparen=force sp_inside_sparen=remove sp_sparen_brace=force sp_before_semi_for=remove sp_before_semi_for_empty=remove sp_after_semi_for_empty=remove sp_before_square=remove sp_before_squares=remove sp_inside_square=remove sp_after_comma=force sp_before_comma=remove sp_after_class_colon=force sp_before_class_colon=force sp_before_case_colon=remove sp_after_operator=remove sp_after_operator_sym=remove sp_sizeof_paren=remove sp_inside_braces_enum=remove sp_inside_braces_struct=remove sp_inside_braces=remove sp_inside_braces_empty=remove sp_type_func=force sp_func_def_paren=remove sp_inside_fparens=remove sp_inside_fparen=remove sp_square_fparen=remove sp_fparen_brace=force sp_func_call_paren=remove sp_func_class_paren=remove sp_return_paren=force sp_defined_paren=force sp_throw_paren=force sp_macro=force sp_else_brace=force sp_brace_else=force sp_brace_typedef=force sp_catch_brace=force sp_brace_catch=force sp_finally_brace=force sp_brace_finally=force sp_try_brace=force
Re: [cmake-developers] Using the internal Code::Blocks builder
Am Donnerstag, 6. September 2012 um 09:24:39 schrieb Benjamin Eikel: Am Mittwoch, 5. September 2012 um 22:29:59 schrieb Bill Hoffman: On 9/5/2012 3:11 PM, Benjamin Eikel wrote: That might become a problem. I tried codeblocks --build --target=MyTarget MyProject.cbp which works and builds the specified target inside the project. But that opens a log window. I have not found a possibility to execute that without a display, yet. http://www.codeblocks.org/docs/manual_en.pdf IDE CodeBlocks can be executed from the command line without a graphic interface. In such a case, there are several switches available for controlling the build process of a project. Since CodeBlocks is thus scriptable, the creation of executables can be integrated into your own work processes. codeblocks.exe /na /nd --no-splash-screen --built name.cbp --target=’Release’ I also read this, but it is not true. Even with all these command line switches a window appears showing the build log. If I set the DISPLAY environment variable to an invalid value, I get the error message Error: Unable to initialize gtk, is DISPLAY set properly?. There is also an old forum discussion about this: http://forums.codeblocks.org/index.php/topic,9731.0.html I asked for help in the Code::Blocks forums: http://forums.codeblocks.org/index.php/topic,16892.new.html -- 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 -- 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] New find module: FindGLEW.cmake
Am Mittwoch, 12. September 2012 um 21:50:35 schrieb Alexander Neundorf: On Tuesday 11 September 2012, Benjamin Eikel wrote: Am Dienstag, 11. September 2012 um 21:44:29 schrieb Alexander Neundorf: On Thursday 30 August 2012, Benjamin Eikel wrote: Am Mittwoch, 29. August 2012 um 18:53:51 schrieb Brad King: On 08/29/2012 05:43 AM, Benjamin Eikel wrote: I have written a find module for the OpenGL Extension Wrangler (GLEW) [1] library (see attachment). I tried to follow all the instructions that I have found. I am willing to maintain that module. Great, thanks for your work! Please proceed through steps 5 and 6 here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer You're welcome to work on other modules (like SDL) as well, but please bring up changes for discussion on the list with the current maintainer of each. glew.h does not contain any version information. It looks like there are version macros that evaluate to runtime tests. How is one supposed to do any preprocessor conditionals based on the version when using GLEW? I do not know of any preprocessor tests. There is a possiblity at runtime to call glewGetString(GLEW_VERSION), but I think it would be too resource intensive to compile and run an application in the find module. Any progress here ? I did not plan to include a test that runs an application to determine the version. Do you think that this should be done? My personal opinion: a FindGLEW.cmake which does not test the version is better than no FindGLEW.cmake at all . Yes, okay. But in your opinion, do you think version support is worth the test by running an application? I cannot estimate how large the running time of such a find module will increase (compiling and running an application). Is it common to use such a test in find modules? I believe that you have much more experience in using CMake and can give me a suggestion if it should be implemented. 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] Using the internal Code::Blocks builder
Am Sonntag, 9. September 2012 um 20:02:37 schrieb Peter Kümmel:
On 09.09.2012 19:50, Benjamin Eikel wrote:
Dear CMake developers,
I looked at the output of my CMake build/bin/cmake
--system-information with the Unix Makefiles generator and the new
Code::Blocks generator. For the new Code::Blocks generator, the
variables CMAKE_LIBRARY_ARCHITECTURE (and the analogous ones for the
languages), CMAKE_${LANG}_IMPLICIT_LINK_DIRECTORIES, and
CMAKE_${LANG}_IMPLICIT_LINK_LIBRARIES are empty. They are not empty for
the Unix Makefiles generator. I have searched the place where they are
set and tried to trace it back to the generator code. But I still have
not found it. Can you tell me what I have to do to make these variables
get the same content when using the new Code::Blocks generator?
When you are looking for some cmake variables you should also search in the
Modules/ folder not only C++ files in Source/, because cmake by itself uses
cmake files.
Yes, thanks, but I knew that. I have found these variables there. But as
stated before, I cannot find the place where the other generator somehow
triggers that these variables are set and my generator does not.
Kind regards
Benjamin
--
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
--
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
--
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] Using the internal Code::Blocks builder
Dear CMake developers,
I looked at the output of my CMake build/bin/cmake --system-information
with the Unix Makefiles generator and the new Code::Blocks generator. For the
new Code::Blocks generator, the variables CMAKE_LIBRARY_ARCHITECTURE (and the
analogous ones for the languages), CMAKE_${LANG}_IMPLICIT_LINK_DIRECTORIES,
and CMAKE_${LANG}_IMPLICIT_LINK_LIBRARIES are empty. They are not empty for
the Unix Makefiles generator. I have searched the place where they are set and
tried to trace it back to the generator code. But I still have not found it.
Can you tell me what I have to do to make these variables get the same content
when using the new Code::Blocks generator?
Kind regards
Benjamin
--
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] Using the internal Code::Blocks builder
Am Freitag, 7. September 2012 um 18:59:49 schrieb Bill Hoffman: On 9/7/2012 12:13 PM, Benjamin Eikel wrote: Yes, I have seen that in the beginning when the generator did not work as expected. At the moment, it builds from the command line, but only if you give it access to a display (a window is opened by C::B, but that closes immediately after the build has finished). So try-compiles work, but the situation with the window is unacceptable. I have to see if somebody from the C::B community is willing to help. OK, well, if that is working. Then build cmake, and then do ./bin/ctest, it should run all the tests and show what you need to do. Doing that everything seems to be fine (complex, complexOneConfig and CMake.CheckSourceTree fail with master branch for me, too). But I have the feeling that the new generator is used only in very few tests. I tried setting CMAKE_TEST_GENERATOR to the name of the new generator and that makes more tests fail. -Bill -- 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 -- 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] Using the internal Code::Blocks builder
Am Samstag, 8. September 2012 um 16:53:56 schrieb David Cole: On Sat, Sep 8, 2012 at 6:38 AM, Peter Kümmel syntheti...@gmx.net wrote: On 08.09.2012 11:51, Benjamin Eikel wrote: Am Freitag, 7. September 2012 um 18:59:49 schrieb Bill Hoffman: On 9/7/2012 12:13 PM, Benjamin Eikel wrote: Yes, I have seen that in the beginning when the generator did not work as expected. At the moment, it builds from the command line, but only if you give it access to a display (a window is opened by C::B, but that closes immediately after the build has finished). So try-compiles work, but the situation with the window is unacceptable. I have to see if somebody from the C::B community is willing to help. OK, well, if that is working. Then build cmake, and then do ./bin/ctest, it should run all the tests and show what you need to do. Doing that everything seems to be fine (complex, complexOneConfig and CMake.CheckSourceTree fail with master branch for me, too). But I have the feeling that the new generator is used only in very few tests. I tried setting CMAKE_TEST_GENERATOR to the name of the new generator and that makes more tests fail. When you build cmake with your new generator it would be selected automatically. But it's a chicken-egg problem then. [... snip ...] How many/what percentage tests fail when you set CMAKE_TEST_GENERATOR to your new generator? A lot of tests fail if I do this ( 50%). Without setting this variable, are all generators tested that are enabled for the current platform? -- 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] Using the internal Code::Blocks builder
Hello again, the generator works rudimentary. I am able to generate Code::Blocks projects for simple CMake projects. I still have to fix a bug with link interface libraries and have to see what I can do about the window that is shown by Code::Blocks when doing command line builds (I am still waiting for a Code::Blocks forum account to be accepted). Is there a set of CMake projects that can be used to put the new generator to the acid test? Kind regards Benjamin -- 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] Using the internal Code::Blocks builder
Am Freitag, 7. September 2012 um 17:07:28 schrieb Bill Hoffman: On 9/7/2012 11:02 AM, Benjamin Eikel wrote: Hello again, the generator works rudimentary. I am able to generate Code::Blocks projects for simple CMake projects. I still have to fix a bug with link interface libraries and have to see what I can do about the window that is shown by Code::Blocks when doing command line builds (I am still waiting for a Code::Blocks forum account to be accepted). Is there a set of CMake projects that can be used to put the new generator to the acid test? You have to have some command line building working or else try-compiles won't run, and it can not verify the compile. Yes, I have seen that in the beginning when the generator did not work as expected. At the moment, it builds from the command line, but only if you give it access to a display (a window is opened by C::B, but that closes immediately after the build has finished). So try-compiles work, but the situation with the window is unacceptable. I have to see if somebody from the C::B community is willing to help. -Bill -- 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] Using the internal Code::Blocks builder
Am Mittwoch, 5. September 2012 um 22:29:59 schrieb Bill Hoffman: On 9/5/2012 3:11 PM, Benjamin Eikel wrote: That might become a problem. I tried codeblocks --build --target=MyTarget MyProject.cbp which works and builds the specified target inside the project. But that opens a log window. I have not found a possibility to execute that without a display, yet. http://www.codeblocks.org/docs/manual_en.pdf IDE CodeBlocks can be executed from the command line without a graphic interface. In such a case, there are several switches available for controlling the build process of a project. Since CodeBlocks is thus scriptable, the creation of executables can be integrated into your own work processes. codeblocks.exe /na /nd --no-splash-screen --built name.cbp --target=’Release’ I also read this, but it is not true. Even with all these command line switches a window appears showing the build log. If I set the DISPLAY environment variable to an invalid value, I get the error message Error: Unable to initialize gtk, is DISPLAY set properly?. There is also an old forum discussion about this: http://forums.codeblocks.org/index.php/topic,9731.0.html -- 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] Using the internal Code::Blocks builder
Dear CMake developers,
I wanted to know if it is possible to let CMake generate a project that uses
the internal build system of the Code::Blocks IDE.
My motivation for this was that a friend of mine, who works together with me
on different projects that use CMake, uses Code::Blocks for years. He tried
CMake's Code::Blocks generator with Makefiles several times and has never been
satisfied (parallel builds not working, stopping of build not working, slow
make on Windows etc.). He ended up creating a Code::Blocks project manually.
I have written a number of hacks that modify the existing Code::Blocks
generator to generate a project that does not use the generated Makefile, but
the build system of Code::Blocks instead. I do not intend to push these
patches, they were only ment as a proof-of-concept implementation. With these
patches applied I am able to build several of our projects (shared libraries,
dependencies on external libraries, applications using them) with the
generated Code::Blocks project.
My questions to you are:
1. Is the CMake community interested in a project generator for CMake that
generates native Code::Blocks projects? If you say that this is something that
you do not want to have, I will stop my work and give my friend a custom CMake
build containing my hacks. If you are nothing loath to have such generator, I
want to try to find a way to do it right and prepare a topic branch.
2. What would be the right way to write such a generator? I think modifying
the cmExtraCodeBlocksGenerator class is not the right way. Maybe one would
have to write a new subclass of cmGlobalGenerator?
Kind regards
Benjamin
From 38a1e84b3719192f4f28f4c72da5ae39430812ca Mon Sep 17 00:00:00 2001
From: Benjamin Eikel cm...@eikel.org
Date: Sun, 2 Sep 2012 16:31:55 +0200
Subject: [PATCH 1/9] Dirty hack to use Code::Blocks internal builder without
a need for a Makefile
---
Source/cmExtraCodeBlocksGenerator.cxx | 35 -
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/Source/cmExtraCodeBlocksGenerator.cxx b/Source/cmExtraCodeBlocksGenerator.cxx
index ad4ab76..419e9b7 100644
--- a/Source/cmExtraCodeBlocksGenerator.cxx
+++ b/Source/cmExtraCodeBlocksGenerator.cxx
@@ -315,7 +315,7 @@ void cmExtraCodeBlocksGenerator
FileVersion major=\1\ minor=\6\ /\n
Project\n
Option title=\ mf-GetProjectName()\ /\n
- Option makefile_is_custom=\1\ /\n
+ Option makefile_is_custom=\0\ /\n
Option compiler=\ compiler \ /\n
virtualFolders\n
Build\n;
@@ -632,6 +632,39 @@ void cmExtraCodeBlocksGenerator::AppendTarget(cmGeneratedFileStream fout,
fout Add option=\-D safedef.str() \ /\n;
}
}
+const char* cflags = target-GetProperty(COMPILE_FLAGS);
+if(cflags)
+ {
+ // Expand the list.
+ std::vectorstd::string flags;
+ cmSystemTools::ExpandListArgument(cflags, flags);
+ for(std::vectorstd::string::const_iterator fi = flags.begin();
+ fi != flags.end(); ++fi)
+{
+cmXMLSafe safeflag(fi-c_str());
+fout Add option=\ safeflag.str() \ /\n;
+}
+ }
+
+std::string sharedLibFlagsVar = CMAKE_SHARED_LIBRARY_CXX_FLAGS;
+if (this-GlobalGenerator-GetLanguageEnabled(CXX) == false)
+ {
+sharedLibFlagsVar = CMAKE_SHARED_LIBRARY_C_FLAGS;
+ }
+const char* sldefs = target-GetMakefile()-GetSafeDefinition(
+ CMAKE_SHARED_LIBRARY_CXX_FLAGS);
+if(sldefs)
+ {
+ // Expand the list.
+ std::vectorstd::string defs;
+ cmSystemTools::ExpandListArgument(sldefs, defs);
+ for(std::vectorstd::string::const_iterator di = defs.begin();
+ di != defs.end(); ++di)
+{
+cmXMLSafe safedef(di-c_str());
+fout Add option=\ safedef.str() \ /\n;
+}
+ }
// the include directories for this target
std::setstd::string uniqIncludeDirs;
--
1.7.10.4
From 54def9141a6477d65e49ed81fb20b7ce930dc467 Mon Sep 17 00:00:00 2001
From: Benjamin Eikel cm...@eikel.org
Date: Tue, 4 Sep 2012 18:23:06 +0200
Subject: [PATCH 2/9] Build a virtual target All referencing all other
targets built
---
Source/cmExtraCodeBlocksGenerator.cxx | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Source/cmExtraCodeBlocksGenerator.cxx b/Source/cmExtraCodeBlocksGenerator.cxx
index 419e9b7..d4ecae5 100644
--- a/Source/cmExtraCodeBlocksGenerator.cxx
+++ b/Source/cmExtraCodeBlocksGenerator.cxx
@@ -322,6 +322,7 @@ void cmExtraCodeBlocksGenerator
this-AppendTarget(fout, all, 0, make.c_str(), mf, compiler.c_str());
+ std::vectorstd::string virtualTargetDeps;
// add all executable and library targets and some of the GLOBAL
// and UTILITY targets
for (std::vectorcmLocalGenerator*::const_iterator lg=lgs.begin();
@@ -388,6
Re: [cmake-developers] Using the internal Code::Blocks builder
Hello Alex, Am Mittwoch, 5. September 2012 um 19:34:56 schrieb Alexander Neundorf: On Wednesday 05 September 2012, Benjamin Eikel wrote: Dear CMake developers, I wanted to know if it is possible to let CMake generate a project that uses the internal build system of the Code::Blocks IDE. My motivation for this was that a friend of mine, who works together with me on different projects that use CMake, uses Code::Blocks for years. He tried CMake's Code::Blocks generator with Makefiles several times and has never been satisfied (parallel builds not working, stopping of build not working, slow make on Windows etc.). He ended up creating a Code::Blocks project manually. I have written a number of hacks that modify the existing Code::Blocks generator to generate a project that does not use the generated Makefile, but the build system of Code::Blocks instead. I do not intend to push these patches, they were only ment as a proof-of-concept implementation. With these patches applied I am able to build several of our projects (shared libraries, dependencies on external libraries, applications using them) with the generated Code::Blocks project. My questions to you are: 1. Is the CMake community interested in a project generator for CMake that generates native Code::Blocks projects? If you say that this is something that you do not want to have, I will stop my work and give my friend a custom CMake build containing my hacks. If you are nothing loath to have such generator, I want to try to find a way to do it right and prepare a topic branch. I wrote the existing CodeBlocks generator, and I'd be happy if you write a real one. So, go ahead :-) Is it possible to build a CodeBlocks project from the command line ? I think this is necessary so all the tests can be executed. if the new CMake generator builds an XML project file like it is done at the moment, sure. Why shouldn't that be possible? At the moment you can build one with e.g. cmake -G CodeBlocks - Unix Makefiles (I am sure you know that. But especially because of that, I do not fully understand your question). 2. What would be the right way to write such a generator? I think modifying the cmExtraCodeBlocksGenerator class is not the right way. Maybe one would have to write a new subclass of cmGlobalGenerator? Yes. Alright. Thank you for your fast answer. Kind regards Benjamin 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] Using the internal Code::Blocks builder
Am Mittwoch, 5. September 2012 um 20:54:57 schrieb Alexander Neundorf: On Wednesday 05 September 2012, Benjamin Eikel wrote: Hello Alex, Am Mittwoch, 5. September 2012 um 19:34:56 schrieb Alexander Neundorf: On Wednesday 05 September 2012, Benjamin Eikel wrote: Dear CMake developers, I wanted to know if it is possible to let CMake generate a project that uses the internal build system of the Code::Blocks IDE. My motivation for this was that a friend of mine, who works together with me on different projects that use CMake, uses Code::Blocks for years. He tried CMake's Code::Blocks generator with Makefiles several times and has never been satisfied (parallel builds not working, stopping of build not working, slow make on Windows etc.). He ended up creating a Code::Blocks project manually. I have written a number of hacks that modify the existing Code::Blocks generator to generate a project that does not use the generated Makefile, but the build system of Code::Blocks instead. I do not intend to push these patches, they were only ment as a proof-of-concept implementation. With these patches applied I am able to build several of our projects (shared libraries, dependencies on external libraries, applications using them) with the generated Code::Blocks project. My questions to you are: 1. Is the CMake community interested in a project generator for CMake that generates native Code::Blocks projects? If you say that this is something that you do not want to have, I will stop my work and give my friend a custom CMake build containing my hacks. If you are nothing loath to have such generator, I want to try to find a way to do it right and prepare a topic branch. I wrote the existing CodeBlocks generator, and I'd be happy if you write a real one. So, go ahead :-) Is it possible to build a CodeBlocks project from the command line ? I think this is necessary so all the tests can be executed. if the new CMake generator builds an XML project file like it is done at the moment, sure. Why shouldn't that be possible? At the moment you can build one with e.g. cmake -G CodeBlocks - Unix Makefiles (I am sure you know that. But especially because of that, I do not fully understand your question). Yes, this is not what I meant. Once cmake has generated a codeblocks project, let's say foo.cbp, is it possible to build (compile) this project using codeblocks from the command line ? Something like $ codeblocks --build foo.cbp This is more or less necessary so cmake can run its test suite to verify the generator works correctly. That might become a problem. I tried codeblocks --build --target=MyTarget MyProject.cbp which works and builds the specified target inside the project. But that opens a log window. I have not found a possibility to execute that without a display, yet. 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] CMake command line options -H and -B
Hello, I have a question concerning the command line options -H and -B. The usage information says that -H shows the help, which is true when -H does not receive any parameters (see cmDocumentation.cxx:1120ff). But when there is a parameter, it sets the source directory (see cmake.cxx:663ff). This is not documented when calling cmake --help and is somehow ambiguous. Furthermore the -B option is not documented there. I encountered the options by looking at the rebuild_cache make target. Are they hidden with intent? Kind regards Benjamin -- 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] Version support for FindSDL_net.cmake
Hello again, Am Mittwoch, 29. August 2012 um 12:39:28 schrieb Benjamin Eikel: Dear CMake developers, I extended the find module for SDL_net by version support (see the attached patch). If you are interested, I am willing to write similar patches for the other SDL_.* modules or one for SDL_gfx (see issue 0012004). The find module has a problem: It does not define SDL_net_FOUND, but SDLNET_FOUND. Therefore, FeatureSummary does not work as expected. Shall I open a bug report for this? because there was no feedback yet – especially not by the maintainer – would it be okay to prepare a topic and push that to the staging area for review? Kind regards Benjamin -- 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] New find module: FindGLEW.cmake
Am Mittwoch, 29. August 2012 um 18:53:51 schrieb Brad King: On 08/29/2012 05:43 AM, Benjamin Eikel wrote: I have written a find module for the OpenGL Extension Wrangler (GLEW) [1] library (see attachment). I tried to follow all the instructions that I have found. I am willing to maintain that module. Great, thanks for your work! Please proceed through steps 5 and 6 here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer You're welcome to work on other modules (like SDL) as well, but please bring up changes for discussion on the list with the current maintainer of each. glew.h does not contain any version information. It looks like there are version macros that evaluate to runtime tests. How is one supposed to do any preprocessor conditionals based on the version when using GLEW? I do not know of any preprocessor tests. There is a possiblity at runtime to call glewGetString(GLEW_VERSION), but I think it would be too resource intensive to compile and run an application in the find module. I could extract version information using PkgConfig, but I have in mind that using PkgConfig is discouraged. There is nothing wrong with using PkgConfig when it is available, but it does not work for all toolchains on all platforms we support. -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] New find module: FindGLEW.cmake
Am Mittwoch, 29. August 2012 um 19:54:58 schrieb Alexander Neundorf: On Wednesday 29 August 2012, Benjamin Eikel wrote: Dear CMake developers, I have written a find module for the OpenGL Extension Wrangler (GLEW) [1] library (see attachment). I tried to follow all the instructions that I have found. I am willing to maintain that module. Unfortunately, the header file glew.h does not contain any version information. I could Cool :-) From looking a bit around on the web, it seems other alternative names for the glew library are glew and glew32s Maybe you can add those two names to the find_library() call ? You are right, I was able to find both in GLEW's Makefile. glew32s is the name of the static library. I will add both of them. Thank you. extract version information using PkgConfig, but I have in mind that using PkgConfig is discouraged. I am looking forward to your feedback. If possible, it'd be nice to do that without pkg-config, that's right. glew.h on my system contains several version-related macros, isn't any of these usable ? /usr/include/GL$ grep VERSION * ... glew.h:/* - GL_VERSION_1_1 */ glew.h:#ifndef GL_VERSION_1_1 glew.h:#define GL_VERSION_1_1 1 glew.h:#define GL_VERSION 0x1F02 glew.h:#define GLEW_VERSION_1_1 GLEW_GET_VAR(__GLEW_VERSION_1_1) glew.h:#endif /* GL_VERSION_1_1 */ glew.h:/* - GL_VERSION_1_2 */ glew.h:#ifndef GL_VERSION_1_2 glew.h:#define GL_VERSION_1_2 1 glew.h:#define GLEW_VERSION_1_2 GLEW_GET_VAR(__GLEW_VERSION_1_2) glew.h:#endif /* GL_VERSION_1_2 */ glew.h:/* GL_VERSION_1_2_1 --- */ glew.h:#ifndef GL_VERSION_1_2_1 glew.h:#define GL_VERSION_1_2_1 1 glew.h:#define GLEW_VERSION_1_2_1 GLEW_GET_VAR(__GLEW_VERSION_1_2_1) glew.h:#endif /* GL_VERSION_1_2_1 */ glew.h:/* - GL_VERSION_1_3 */ glew.h:#ifndef GL_VERSION_1_3 glew.h:#define GL_VERSION_1_3 1 glew.h:#define GLEW_VERSION_1_3 GLEW_GET_VAR(__GLEW_VERSION_1_3) glew.h:#endif /* GL_VERSION_1_3 */ glew.h:/* - GL_VERSION_1_4 */ glew.h:#ifndef GL_VERSION_1_4 glew.h:#define GL_VERSION_1_4 1 glew.h:#define GLEW_VERSION_1_4 GLEW_GET_VAR(__GLEW_VERSION_1_4) glew.h:#endif /* GL_VERSION_1_4 */ glew.h:/* - GL_VERSION_1_5 */ glew.h:#ifndef GL_VERSION_1_5 glew.h:#define GL_VERSION_1_5 1 glew.h:#define GLEW_VERSION_1_5 GLEW_GET_VAR(__GLEW_VERSION_1_5) glew.h:#endif /* GL_VERSION_1_5 */ glew.h:/* - GL_VERSION_2_0 */ glew.h:#ifndef GL_VERSION_2_0 glew.h:#define GL_VERSION_2_0 1 glew.h:#define GL_SHADING_LANGUAGE_VERSION 0x8B8C glew.h:#define GLEW_VERSION_2_0 GLEW_GET_VAR(__GLEW_VERSION_2_0) glew.h:#endif /* GL_VERSION_2_0 */ glew.h:/* - GL_VERSION_2_1 */ glew.h:#ifndef GL_VERSION_2_1 glew.h:#define GL_VERSION_2_1 1 glew.h:#define GLEW_VERSION_2_1 GLEW_GET_VAR(__GLEW_VERSION_2_1) glew.h:#endif /* GL_VERSION_2_1 */ glew.h:/* - GL_VERSION_3_0 */ glew.h:#ifndef GL_VERSION_3_0 glew.h:#define GL_VERSION_3_0 1 glew.h:#define GL_MAJOR_VERSION 0x821B glew.h:#define GL_MINOR_VERSION 0x821C glew.h:#define GLEW_VERSION_3_0 GLEW_GET_VAR(__GLEW_VERSION_3_0) glew.h:#endif /* GL_VERSION_3_0 */ glew.h:/* - GL_VERSION_3_1 */ glew.h:#ifndef GL_VERSION_3_1 glew.h:#define GL_VERSION_3_1 1 glew.h:#define GLEW_VERSION_3_1 GLEW_GET_VAR(__GLEW_VERSION_3_1) glew.h:#endif /* GL_VERSION_3_1 */ glew.h:/* - GL_VERSION_3_2 */ glew.h:#ifndef GL_VERSION_3_2 glew.h:#define GL_VERSION_3_2 1 glew.h:#define GLEW_VERSION_3_2 GLEW_GET_VAR(__GLEW_VERSION_3_2) glew.h:#endif /* GL_VERSION_3_2 */ glew.h:/* - GL_VERSION_3_3 */ glew.h:#ifndef GL_VERSION_3_3 glew.h:#define GL_VERSION_3_3 1 glew.h:#define GLEW_VERSION_3_3 GLEW_GET_VAR(__GLEW_VERSION_3_3) glew.h:#endif /* GL_VERSION_3_3 */ glew.h:/* - GL_VERSION_4_0 */ glew.h:#ifndef GL_VERSION_4_0 glew.h:#define GL_VERSION_4_0 1 glew.h:#define GLEW_VERSION_4_0 GLEW_GET_VAR(__GLEW_VERSION_4_0) glew.h:#endif /* GL_VERSION_4_0 */ glew.h:/* - GL_VERSION_4_1 */ glew.h:#ifndef GL_VERSION_4_1 glew.h:#define GL_VERSION_4_1 1 glew.h:#define GLEW_VERSION_4_1 GLEW_GET_VAR(__GLEW_VERSION_4_1) glew.h:#endif /* GL_VERSION_4_1 */ The GL_VERSION_... constants only tell what GL version GLEW supports. glew.h:#define GL_SHADING_LANGUAGE_VERSION_ARB 0x8B8C
Re: [cmake-developers] New find module: FindGLEW.cmake
Am Donnerstag, 30. August 2012 um 13:00:48 schrieb Rolf Eike Beer: Alexander Neundorf wrote: On Wednesday 29 August 2012, Benjamin Eikel wrote: Dear CMake developers, I have written a find module for the OpenGL Extension Wrangler (GLEW) [1] library (see attachment). I tried to follow all the instructions that I have found. I am willing to maintain that module. Unfortunately, the header file glew.h does not contain any version information. I could Cool :-) From looking a bit around on the web, it seems other alternative names for the glew library are glew and glew32s Maybe you can add those two names to the find_library() call ? extract version information using PkgConfig, but I have in mind that using PkgConfig is discouraged. I am looking forward to your feedback. If possible, it'd be nice to do that without pkg-config, that's right. glew.h on my system contains several version-related macros, isn't any of these usable ? Why? My guess would be to check whatever works, i.e. test pkg-config first and if that doesn't give anything suitable then do the normal scanning. Cheking pkg-config first is possible. But that would mean that the result of the find module depends on the availability of pkg-config (a version is reported if and only if pkg-config is available). Is that desirable? Or did you mean do not _require_ pkg-config? Because pkg-config is not available on all platforms, it is unwise to require it. Eike -- -- 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] New find module: FindGLEW.cmake
Dear CMake developers,
I have written a find module for the OpenGL Extension Wrangler (GLEW) [1]
library (see attachment). I tried to follow all the instructions that I have
found. I am willing to maintain that module. Unfortunately, the header file
glew.h does not contain any version information. I could extract version
information using PkgConfig, but I have in mind that using PkgConfig is
discouraged. I am looking forward to your feedback.
Kind regards
Benjamin
[1] http://glew.sourceforge.net/
# - Find the OpenGL Extension Wrangler Library (GLEW)
# This module defines the following variables:
# GLEW_INCLUDE_DIRS - include directories for GLEW
# GLEW_LIBRARIES - libraries to link against GLEW
# GLEW_FOUND - true if GLEW has been found and can be used
#=
# Copyright 2012 Benjamin Eikel
#
# Distributed under the OSI-approved BSD License (the License);
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
#=
# (To distribute this file outside of CMake, substitute the full
# License text for the above reference.)
find_path(GLEW_INCLUDE_DIR GL/glew.h)
find_library(GLEW_LIBRARY NAMES GLEW glew32 PATH_SUFFIXES lib64)
set(GLEW_INCLUDE_DIRS ${GLEW_INCLUDE_DIR})
set(GLEW_LIBRARIES ${GLEW_LIBRARY})
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
find_package_handle_standard_args(GLEW
REQUIRED_VARS GLEW_INCLUDE_DIR GLEW_LIBRARY)
mark_as_advanced(GLEW_INCLUDE_DIR GLEW_LIBRARY)
--
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] Version support for FindSDL_net.cmake
Dear CMake developers,
I extended the find module for SDL_net by version support (see the attached
patch). If you are interested, I am willing to write similar patches for the
other SDL_.* modules or one for SDL_gfx (see issue 0012004).
The find module has a problem: It does not define SDL_net_FOUND, but
SDLNET_FOUND. Therefore, FeatureSummary does not work as expected. Shall I
open a bug report for this?
Kind regards
Benjamin
--- /usr/share/cmake-2.8/Modules/FindSDL_net.cmake 2012-08-09 20:15:19.0 +0200
+++ /usr/share/cmake-2.8/Modules/FindSDL_net.cmake 2012-08-29 12:29:56.0 +0200
@@ -3,6 +3,7 @@
# SDLNET_LIBRARY, the name of the library to link against
# SDLNET_FOUND, if false, do not try to link against
# SDLNET_INCLUDE_DIR, where to find the headers
+# SDLNET_VERSION_STRING - human-readable string containing the version of SDL_net
#
# $SDLDIR is an environment variable that would
# correspond to the ./configure --prefix=$SDLDIR
@@ -63,7 +64,24 @@
/opt
)
+IF(SDLNET_INCLUDE_DIR AND EXISTS ${SDLNET_INCLUDE_DIR}/SDL_net.h)
+ FILE(STRINGS ${SDLNET_INCLUDE_DIR}/SDL_net.h SDLNET_VERSION_MAJOR_LINE REGEX ^#define[ \t]+SDL_NET_MAJOR_VERSION[ \t]+[0-9]+$)
+ FILE(STRINGS ${SDLNET_INCLUDE_DIR}/SDL_net.h SDLNET_VERSION_MINOR_LINE REGEX ^#define[ \t]+SDL_NET_MINOR_VERSION[ \t]+[0-9]+$)
+ FILE(STRINGS ${SDLNET_INCLUDE_DIR}/SDL_net.h SDLNET_VERSION_PATCH_LINE REGEX ^#define[ \t]+SDL_NET_PATCHLEVEL[ \t]+[0-9]+$)
+ STRING(REGEX REPLACE ^#define[ \t]+SDL_NET_MAJOR_VERSION[ \t]+([0-9]+)$ \\1 SDLNET_VERSION_MAJOR ${SDLNET_VERSION_MAJOR_LINE})
+ STRING(REGEX REPLACE ^#define[ \t]+SDL_NET_MINOR_VERSION[ \t]+([0-9]+)$ \\1 SDLNET_VERSION_MINOR ${SDLNET_VERSION_MINOR_LINE})
+ STRING(REGEX REPLACE ^#define[ \t]+SDL_NET_PATCHLEVEL[ \t]+([0-9]+)$ \\1 SDLNET_VERSION_PATCH ${SDLNET_VERSION_PATCH_LINE})
+ SET(SDLNET_VERSION_STRING ${SDLNET_VERSION_MAJOR}.${SDLNET_VERSION_MINOR}.${SDLNET_VERSION_PATCH})
+ UNSET(SDLNET_VERSION_MAJOR_LINE)
+ UNSET(SDLNET_VERSION_MINOR_LINE)
+ UNSET(SDLNET_VERSION_PATCH_LINE)
+ UNSET(SDLNET_VERSION_MAJOR)
+ UNSET(SDLNET_VERSION_MINOR)
+ UNSET(SDLNET_VERSION_PATCH)
+ENDIF()
+
INCLUDE(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(SDLNET
- REQUIRED_VARS SDLNET_LIBRARY SDLNET_INCLUDE_DIR)
+ REQUIRED_VARS SDLNET_LIBRARY SDLNET_INCLUDE_DIR
+ VERSION_VAR SDLNET_VERSION_STRING)
--
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
