David Cole wrote:
> Please join us in about 15 minutes for a CMake Developers chat via the IRC
> #cmake room...

Here is the log of the meeting.

[19:47:56] <Dakon> ah, the VIPs are finally arriving ;)
[19:48:36] *** Modus #cmake +o Dakon durch ChanServ
[19:48:47] *** Modus #cmake +v davidcole durch Dakon
[19:58:01] <davidcole> VIP? Where? (looks around… sees nobody else)
[19:58:13] <Dakon> ;)
[19:58:26] <Dakon> aLeSD|: there?
[19:59:38] <davidcole> Can we tell how many are here? I'm not an IRC expert
yet by any stretch
[20:00:30] <wacky> I'm here for the developer discussion.
[20:00:42] <steveire> davidcole: 84 people
[20:00:49] <steveire> But it's always about that many
[20:00:52] <davidcole> Excellent, you are in the right place
[20:01:28] <davidcole> This is going to be sort of free form…
[20:01:37] <davidcole> I don't have any specific agenda
[20:02:35] <davidcole> But I would like to talk about CMake 2.8.10, when we
should anticipate having release candidate 1, talk a little about bugs, and
then see if anybody else has any questions or discussion items
[20:04:38] <Dakon> then let's talk ;)
[20:05:50] <davidcole> OK - first of all, one of the ideas with scheduling this
on Monday was to talk about anything you all would like to bring to my
attention (and Brad's) before our Tuesday merge sessions.
[20:06:20] <davidcole> Before we talk about 2.8.10-rc1, does anybody have any
specific items that they want to chat about w.r.t. tomorrow's merging?
[20:06:26] <steveire> I have an item: Is the qt5-qtdialog-port branch blocked
on something? Waiting for Qt 5 relase or something like thaT?
[20:06:35] <davidcole> The dashboard looks good today.
[20:06:51] <davidcole> qt5 question: hang on, let me take a glance at it...
[20:07:40] <steveire> Oops, I just realized I didn't merge it to next...
[20:07:44] <Dakon> I think I finally fixed the last issue in the document-MSVC-
variables-12567 branch, should be green tomorrow
[20:07:48] <davidcole> The "qt5-qtdialog-port" is not merged to 'next'
according to 'stage print'
[20:08:11] <davidcole> One of these times I'll look up to see what others have
typed before I hit "return" :-P
[20:08:21] <Dakon> hrhr
[20:08:40] <Dakon> I have a fix in bug 13262 but got no response from the
original reporter so far
[20:08:41] <davidcole> great on the "fixing last issue" - thanks, Eike
[20:09:16] <Dakon> I think I'll just push and merge that to next now and let
everyone complain afterwards about the things I broke again ;)
[20:09:16] <davidcole> well….
[20:09:29] <steveire> Merged the qt5 branch to next now.
[20:09:40] <davidcole> w.r.t. 13262, if you don't hear back, but you think
it's probably the right fix, it's ok with me if you want to merge it to 'next'
[20:10:08] <davidcole> the patch for it looks simple enough
[20:10:42] <Dakon> I think I once again will run into problems there is the
list is empty, no?
[20:10:58] <Dakon> will check and then merge
[20:11:39] <Dakon> ah, no, the list can't be empty there
[20:12:11] <Dakon> but I'll change that "set" to "list(APPEND" for sanity
[20:12:31] <davidcole> sounds reasonable
[20:12:42] <davidcole> there are other "not yet in next
[20:12:48] <davidcole> " branches on the stage
[20:13:17] <davidcole> any claimers? for "export-sets-2"
"generate_export_header-fixes" and "AutomocUseTargetProperties"
[20:13:36] <davidcole> will they be in 'next' soon? Or is the stage being used
as a communications channel for these topics?
[20:14:01] <Dakon> the second one sounds like steveire ;)
[20:14:03] <steveire> generate_export_header-fixes is mine. I'll try to come
back to it soon
[20:14:24] <steveire> The last time I merged it, the dashboard blushed.
[20:14:37] <davidcole> It was embarrassed for you?
[20:14:38] <davidcole> '-)
[20:14:40] <davidcole> ;-)
[20:14:59] <davidcole> Looks like export-sets-2 is Alex's
[20:15:00] <steveire> :)
[20:15:18] <steveire> Yes, that's under discussion on the ml atm.
[20:15:22] <Dakon> someone could have noticed that I messed up the argument
order to list(FIND) in that patch
[20:15:30] <steveire> http://public.kitware.com/Bug/view.php?id493#c30781
relates to the third one.
[20:15:31] <davidcole> And so is the other one (also Alex's)
[20:15:58] <davidcole> Dang, do I have to look up the --help-command for list
everytime....?
[20:16:45] <Dakon> hehe ;)
[20:17:01] <Dakon> why should it be simpler for you than for me, hm? ;)
[20:17:08] <davidcole> All right, so it sounds like things are fairly well in
hand for topics already in 'next' and topics coming soon on the stage
[20:17:53] <Dakon> I would like if Brad could go and cherry-pick that kwsys
stuff from VTK he talked about
[20:17:58] <davidcole> Assuming the dashboards look good tomorrow, Brad and I
will review them all and hopefully push most or all of them to master
[20:18:26] <davidcole> I will mention the kwsys/VTK item to him
[20:20:33] <Dakon> can someone try to load one of the Windows machines with a
bunch of open source projects?
[20:21:04] <Dakon> I fear that most Find modules are not tested on windows at
all and will explode once someone will test them
[20:22:00] <davidcole> What do you mean by "load with a bunch"?
[20:22:30] <davidcole> It's really a delicate balancing act trying not to mess
up a dashboard machine that's already successfully submitting for multiple
projects.
[20:22:53] <davidcole> I tend to avoid installing stuff unless it's absolutely
necessary on the stable dashboard machines.
[20:23:04] <davidcole> I can see your point, though
[20:23:20] <davidcole> Just not sure how to achieve the goal without becoming
responsible for "other people'
[20:23:24] <davidcole> s dashboard scripts"
[20:23:29] <Dakon> how are these machines organized at Kitware? physical
hardware? vms?
[20:23:41] <davidcole> mostly physical hardware
[20:23:49] <davidcole> some of the newer ones are vm-based
[20:24:15] <Dakon> maybe you could clone one of them?
[20:25:42] <Dakon> and then just look on the output of AllFindModules test and
install everything that is not found ;)
[20:26:04] <davidcole> Good idea, but I don't have the bandwidth to get to
that anytime soon.
[20:27:04] <steveire> So, next item is RC1?
[20:27:07] <Dakon> well, if it takes another week or 3 it doesn't matter that
much I think
[20:27:09] <davidcole> In fact, my personal bandwidth on CMake is fairly
limited lately to reviewing and organizing the patches and submissions of you
all: you guys are the real CMake VIPs
[20:27:17] <davidcole> yes -- rc1
[20:27:36] <Dakon> I wont mind if you delegate it to someone else ;)
[20:28:10] <davidcole> OK…. so whenever we plan a date for a CMake release, we
tend to just pick a Wednesday out there in the future that's about 3 months
from the previous release and pin it on the calendar
[20:28:13] <Dakon> reminds me of something: is there a description of what
stuff is accepted in what stage of development?
[20:28:30] <davidcole> This time around, I picked 10/31, Halloween, after
releasing 2.8.9 on Aug. 9th
[20:28:50] <Dakon> yeah, let's create a nightmare release ;)
[20:28:51] <davidcole> So -- to hit that, we should really have rc1 a week
from Wednesday, on Sept. 26th
[20:29:14] <davidcole> I'm willing to go further out than that, but that means
we would be in November probably for the real release of 2.8.10
[20:29:23] <steveire> Hmm.
[20:29:39] <steveire> A bit close. What does rc1 mean? No new features?
[20:29:46] <davidcole> The other possibilities are Wed. Oct. 3 and Wed. Oct
17th
[20:30:16] <davidcole> The week of the 10th is out for me, as I will be out of
town with limited computing access
[20:30:38] <davidcole> rc1 means no significant new changes, except for
regression bug fixes
[20:30:45] <davidcole> Think of it this way:
[20:31:07] <davidcole> if rc1 works for somebody who's not encountering a
regression in behavior, then the final release should also work for them
[20:31:27] <Dakon> so things like the processor id stuff will likely not make
it into 2.8.10
[20:31:30] <steveire> Right.
[20:31:30] <Dakon> which is ok for me
[20:31:31] <davidcole> So, Brad and I are very careful, in general, about what
we take into 'master' during a release candidate phase
[20:31:54] <steveire> I'll try to get the config specific include dirs in before
next wed then.
[20:32:39] <steveire> I'll have another refactoring branch to merge to next
tomorrow or the next day, then I might be able to get it in.
[20:32:49] <davidcole> Sounds good
[20:33:02] <davidcole> The reason to favor doing it early from our
perspective...
[20:33:10] <steveire> It's not critical for 2.8.10 anyway, so ok from me.
[20:33:37] <Dakon> davidcole: I have a change that moves the implementation of
cmMessageCommand::GetFullDocumentation() from header to source
[20:33:38] <davidcole> …is that there was fix on the Mac that really really
helps out people using multiple installations of Xcode, or pre-release dev
snapshots from Apple
[20:33:56] <Dakon> it was created while trying to implement something else
which didn't work out
[20:34:07] <Dakon> I wonder if I should merge this or just drop it
[20:34:35] <davidcole> Are other commands in the cxx files now? I thought most
are still in header files...
[20:34:57] <Dakon> heavily depends on the file afaict
[20:36:22] <davidcole> git grep GetFullDocumentation | grep -E "\.h:" | wc
[20:36:30] <davidcole> says that 107 of 119 are in header files
[20:36:38] <davidcole> so just leave that one in the header file too
[20:36:49] <Dakon> ok
[20:37:01] <steveire> So, on to bugs.
[20:37:22] <steveire> (Then I have one discussion item)
[20:37:27] <davidcole> Steve is our moderator, keeping us on schedule
[20:37:30] <davidcole> :-)
[20:37:46] <steveire> :)
[20:37:50] <davidcole> Since it seems to be just mostly 3 of us, there's not
much to talk about bugs I guess
[20:37:59] <davidcole> We have about 30-something on the roadmap
[20:38:05] <davidcole> and I doubt we'll get to them all
[20:38:18] <davidcole> we have fixed 24 according to the change log page since
Aug. 9th
[20:38:59] <davidcole> I was hoping more would be listening in here, and
available to volunteer some man-power in terms of telling us which bugs have
good patches, adding patches, testing.....
[20:39:56] <Dakon> another one ;)
[20:39:56] <steveire> The first meeting being under-attended isn't surprising
anyway. :) A reminder on the mailing lists next time might help with that.
[20:40:00] <davidcole> Any ideas for getting some more folks involved in CMake
development? (And thereby helping us fix bugs at a faster rate…. or at least
being more effective at our communications in the bugs)
[20:40:03] <Dakon> ok, I'll be away for half an hour
[20:40:08] <Dakon> need to pick up my wife
[20:40:09] <AmineKhaldi> hey, I'm here too ! :)
[20:40:17] <Dakon> stay around so we can continue later ;)
[20:40:31] <AmineKhaldi> (I just didn't know what to contribute to the
discussion)
[20:40:43] <davidcole> Hi Amine!
[20:40:49] <AmineKhaldi> hey ;)
[20:41:09] <davidcole> So…. unfortunately, although I put some of your bugs of
interest on the roadmap,
[20:41:20] <davidcole> we have not seen any adopters coming forward to help
out
[20:41:25] <steveire> davidcole: Perhaps add a link to the contribute page
when putting bugs in the backlog.
[20:41:45] <AmineKhaldi> yeah, it's too bad
[20:41:51] <davidcole> That is a very good idea
[20:42:11] <steveire> There are plenty of people using the bug tracker who are
competent enough to contribute more if they knew it would get their patches in
I'm sure.
[20:43:06] <davidcole> Is the contribute page complete, and have good
instructions on it? (Which page do you mean, anyhow? a wiki page, something on
cmake.org, or something else?)
[20:43:18] <davidcole> Yes, there are
[20:43:33] <davidcole> One of the major problems we have with patches attached
to the bug tracker is...
[20:44:09] <steveire> davidcole: http://www.paraview.org/Wiki/CMake/Git or
something similar to it.
[20:44:12] <davidcole> …they're sufficient to fix the problem at hand for
*somebody* , but that person may or may not take into account the fact that
CMake has to work on tens of platforms and even more compilers
[20:44:46] <steveire> http://www.cmake.org/cmake/project/getinvolved.html
could maybe be linked to that wiki page.
[20:45:55] <steveire> Yes, that's something that the person merging has to
take care of.
[20:46:09] <steveire> Which, incidentally, brings me to the point I wanted to
discuss :)
[20:46:28] <davidcole> Good idea on both fronts, Steve. I will take your
advice and add links like that next time I 'backlog' anything
[20:46:40] <davidcole> And I can get a link to the wiki added to that
getinvolved page
[20:46:54] <steveire> I get hit by compiler warnings after I merge things to
next for errors that I should have caught locally.
[20:47:16] <davidcole> Yes, quite common and unfortunate
[20:47:28] <steveire> I expected cmake to have the warnings enabled for
building cmake so that I wouldn't get initialization order wrong, name unused
parameters etc.
[20:47:57] <davidcole> Why did you expect that? ;-)
[20:48:00] <steveire> It should be quite simple to add the warnings for some
base version of gcc/clang so that most people would get them.
[20:48:08] <davidcole> That's a good idea, too
[20:49:12] <steveire> I can see if it works with
[20:49:12] <steveire>   set (CMAKE_C_FLAGS   "${CMAKE_C_FLAGS} -Wno-long-long
-std=iso9899:1990 -Wundef -Wcast-align -Werror-implicit-function-declaration -
Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -
Wmissing-format-attribute -fno-common")
[20:49:12] <steveire>   set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wnon-
virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall
-W -Wpointer-arith -Wformat-security -fno-check-new -fno-common ")
[20:49:12] <steveire> then at some point, which is the magic warnings I use
everywhere.
[20:49:22] <syntheticpp> hi, (syntheticpp == Peter Kuemmel)
[20:49:37] <davidcole> Hello Peter
[20:49:39] <steveire> Hi Peter.
[20:49:44] <AmineKhaldi> Peter ;)
[20:50:20] <syntheticpp> Haven't compiled reactos for a while, sorry ;)
[20:51:11] <syntheticpp> I've a question to ExternalProject: there is this bug
entry http://www.cmake.org/Bug/view.php?id538
[20:51:11] <steveire> I'm going to have to go soon.
[20:51:24] <steveire> Should we post the chat log to the mailing list?
[20:51:27] <davidcole> Steve, now that the compiler variables are well known,
work everywhere, and fully documented, it should be easy enough to add the
flags for warnings in conditional blocks based on the compiler
[20:52:17] <steveire> "now that the compiler variables are well known, work
everywhere, and fully documented, " << What do you mean? Did something change
to make that true?
[20:52:18] <davidcole> So, wrap those set calls in conditional logic based on
the compiler, and push a branch to the stage for that. If it's a branch on the
stage, I will definitely talk to Brad about it.
[20:52:31] <syntheticpp> but I'm not sure if it's not a missing feature in
ExternalProject, David aren't you the EP expert?
[20:52:35] <davidcole> yes, Brad's recent commits (last few weeks)
[20:52:46] <steveire> davidcole: Ah, you mean version checks.
[20:52:50] <steveire> for the compiler version
[20:52:53] <davidcole> yes
[20:53:12] <davidcole> Peter, I am as close as one can get to an EP expert
[20:53:27] <steveire> davidcole: But I'm talking about building cmake itself,
and that requires cmake 2.8.2, right?
[20:53:32] <davidcole> The bug sounds related to files with the SYMBOLIC
property
[20:53:51] <steveire> So I can't make use of the compiler version variables.
[20:53:53] <davidcole> steve, you're right
[20:53:56] <davidcole> sorry
[20:54:09] <davidcole> bad suggestion (but it will be good in about 2
years...)
[20:54:17] <steveire> But I can check for some reasonably recent gcc that
people are likely to be using for primary development anyway.
[20:54:30] <steveire> :) Yes, we can do it that way in 2 years.
[20:54:48] <davidcole> the SYMBOLIC files should end up being .phony targets in
the makefiles (from what I understand)
[20:55:16] <davidcole> I would think that if ninja has 'phony' as a keyword,
it should work the same
[20:56:08] <davidcole> I just read your note in the bug, though, and I think
your analysis is correct
[20:56:20] <davidcole> So never mind what I'm saying about SYMBOLIC and phone
[20:56:22] <davidcole> phony
[20:56:51] <syntheticpp> Yes, it has, but how could it know the target name
and lib name are related?
[20:56:59] <steveire> I'm going to have to roll. Thanks for the meeting. Maybe
Dakon can post the chat log if you think that's useful. He'll have all of it
:).
[20:57:05] <davidcole> it can't -- your analysis is correct
[20:57:13] <davidcole> thanks, Steve
[20:57:18] <davidcole> chat with ya again next week
[20:57:23] <syntheticpp> bye Steve
[20:57:28] <AmineKhaldi> bye steveire
[20:57:29] <steveire> bye
[20:57:58] <davidcole> OK, so before we call it a 'wrap
[20:58:03] <davidcole> ' -- a recap:
[20:58:39] <davidcole> We are hoping to schedule rc1 for next Wed. Sept. 26,
and we will execute on that unless something pops up to prevent it between now
and then
[20:59:33] <davidcole> We still need more contributors, and folks to help us
manage the large amount of stuff we are tracking in our bug database
[21:00:22] <davidcole> And this seems like it was useful, so we'll continue to
schedule chat sessions on Mondays at 2:00 pm Eastern time US
[21:00:46] <davidcole> Any other questions for me before I sign off today?
[21:01:20] <syntheticpp> Could I assign mentioned bug to you?
[21:02:00] <davidcole> Sure
[21:02:07] <AmineKhaldi> davidcole: one question if I may
[21:02:24] <davidcole> He claims it does work with the Makefile generator, but
I don't know how it could. Maybe he's just getting lucky with build ordering.
[21:02:31] <davidcole> Go ahead Amine
[21:03:06] <AmineKhaldi> does any of you guys use VS with a solution that has
more than 20 projects for example ? and if so, when you alter a cmake file
doesn't VS go crazy about "do you want to reload the project" prompt for every
single project in the solution ?
[21:03:13] <davidcole> In fact, that's probably why it appears to work with
make. It probably wouldn't work with a clean+heavily-parallel make…
[21:03:27] <AmineKhaldi> I'm just curious to know, since this happens for us
and we have like 800 modules, so you can see how impractical that is
[21:03:28] <syntheticpp> Yes, I've tested it with nmake and a target, and it
fails like ninja
[21:03:31] <davidcole> yes, VS is constantly going crazy
[21:04:09] <davidcole> I personally cannot stand the way more than about 10
projects seem to overload poor little Visual Studio
[21:04:26] <AmineKhaldi> in light of the recent cleanup around msvc, could
something be considered for this very frequent situation ?
[21:04:31] <davidcole> I always close the solution I'm working on, then run
cmake to re-configure, then re-open the solution when I have to use VS
[21:04:48] <syntheticpp> Amine: I've seen a solution for that in clang,
looking for the link ...
[21:05:10] <AmineKhaldi> ah, this reminds me of another question, since you
mentioned clang
[21:05:16] <AmineKhaldi> clang in windows behaves in two ways
[21:05:20] <AmineKhaldi> gcc mode and msvc mode
[21:05:36] <AmineKhaldi> they have the same driver, but one is compatible with
ld, and the other is compatible with link
[21:05:44] <AmineKhaldi> (and codegen differs of course)
[21:05:51] <syntheticpp> CMakeLists in clang at the end: # Workaround for
MSVS10 to avoid the Dialog Hell
[21:06:00] <syntheticpp> http://llvm.org/svn/llvm-
project/cfe/trunk/CMakeLists.txt
[21:06:16] <davidcole> We have this very old, very well known bug that we have
not been able to fix:
[21:06:17] <davidcole> http://public.kitware.com/Bug/view.php?id258
[21:06:25] <AmineKhaldi> the question is: did you consider something to
support this ? since we can't just if(MSVC) in the case of the msvc compatible
clang
[21:06:27] <davidcole> There is a VS add-on that you can try
[21:07:09] <davidcole> Try the add-on from vscommands.com as a way of
reloading them all in a single swoop
[21:07:13] <AmineKhaldi> syntheticpp: hmm, interesting
[21:07:17] <davidcole> I haven't tried it myself
[21:08:19] <AmineKhaldi> davidcole: another thing, re. the asm defines support,
someone added a patch
[21:08:35] <AmineKhaldi> it was for supporting custom commands for asm files
[21:08:56] <AmineKhaldi> it was missing the defines, so I asked the guy to
consider expanding <DEFINES> but I got no reply
[21:09:08] <AmineKhaldi> is there a chance to pick up his patch and add just
that to it ?
[21:09:12] <davidcole> We do not expand anything for Visual Studio projects
[21:09:51] <AmineKhaldi> hmm, so his patch is incorrect ?
[21:09:55] <Dakon> back
[21:09:58] <AmineKhaldi> as in using an incorrect angle ?
[21:10:14] <davidcole> It may look like we do from a "net result" perspective,
but we don't expand those rule vars for VS, we let VS do it's own thing based
on the generated projects
[21:10:42] <davidcole> which patch are we talking about here? (or bug number)?
[21:12:43] <rindolf> Hi all.
[21:12:48] <rindolf> Is the meeting still on?
[21:13:51] <syntheticpp> Hi, meeting is near the end
[21:13:56] <rindolf> syntheticpp: ah, OK.
[21:14:33] <syntheticpp> but maybe a log is posted
[21:15:36] <davidcole> I am still here…. did you have a question, or did you
just want to observe?
[21:18:29] <Dakon> I wanted to ask one or 2 things, but I'll need a moment to
remember what it was
[21:20:34] <Dakon> davidcole: any news about the QNX builds?
[21:21:55] <Dakon> and what's the problem with amber1[02]?
[21:22:54] <AmineKhaldi> sorry, that was the phone
[21:22:59] -*- AmineKhaldi reads up
[21:24:06] <AmineKhaldi> davidcole: this one:
http://www.cmake.org/Bug/view.php?id�70
[21:30:40] <davidcole> He's calling ExpandRuleVariables from a context in
which it was never designed to be called (a Visual Studio generator)
[21:30:58] <AmineKhaldi> ouch
[21:31:01] <davidcole> It may work, it may not, I've not delved into the rule
variables enough to know
[21:31:23] <AmineKhaldi> well, could having it working for one more var
(DEFINES) be considered a short term solution ?
[21:31:53] <Dakon> davidcole: I also have some good news
[21:32:03] <AmineKhaldi> if this one somehow gets expanded correctly for each
source file, that would be great
[21:32:38] <davidcole> No news that I know of regarding QNX builds. I'll have
to re-ping
[21:32:42] <davidcole> What's your good news?
[21:32:43] <Dakon> aLeSD| is working on perforce integration for CMake
[21:35:29] <davidcole> the problem with amber10 is that Visual Studio 10 has
always been flaky on that machine, but we leave it running our Continuous
anyway
[21:35:41] <davidcole> because it's better than not having one and we don't
have another machine we can put it on right now
[21:36:02] <davidcole> so, the errors it reports are frequently "MSBuild
crashed" while building something
[21:36:07] <davidcole> sorry about that.
[21:38:55] <davidcole> And… amber12, the mingw/msys builds are run in their
own separate command prompt, but in parallel with other dashboards running in
other command prompts
[21:39:15] <davidcole> Seems one of them is ALWAYS timing out, but always on a
different test each night.
[21:39:55] <davidcole> If we could figure the rhyme or reason behind that one,
we'd change it, but at this point, it's better to live with it until we get a
new dashboard for mingw/msys set up on a different machine than it is to give
up on it entirely
[21:40:20] <davidcole> Brad and I discount these types of dashboard errors
when we are considering the state of the system and deciding what gets merged
to 'master'
[21:40:36] <davidcole> I have got to get going for today, but this has been
fun
[21:40:57] <wacky> CU
[21:41:04] <davidcole> Dakon: could you please save a transcript of this, and
post it to the CMake dev mailing list?
[21:41:07] <davidcole> thanks all!
[21:41:11] <Dakon> sure
[21:41:11] <davidcole> bye
[21:41:16] <Dakon> cu next week
[21:42:27] <Dakon> time for some new VMs I would say ;)

Attachment: signature.asc
Description: This is a digitally signed message part.

--

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

Reply via email to