Re: [cmake-developers] qt4_use_modules
Clinton Stimpson wrote: > > On Aug 11, 2012, at 10:36 AM, Alexander Neundorf wrote: > >> On Friday 10 August 2012, Stephen Kelly wrote: >> > David Cole wrote: >> > > I assume it's the "qt4_use_modules" branch on the stage? >> > >> > Yes, sorry, I should have pointed that out. >> What was the plan with the more generic target_use_package() or how it >> was named ? This would do something similar, right ? target_use_targets() in the latest proposal. > I was wondering the same. And how close are we to having the more generic > one working? So far Brad decided on the declarative syntax he wanted and implemented it in a private branch. I'm sure there will be progress during cmake 2.8.10, but it will not be finished by then. There will probably only be me working on it (though parts of it can be parallelized). The existing cmake code has to be refactored, the new features have to be designed (this part has been discussed already) and implemented, unit tested, documented, and maybe used in a few cmake modules. There is a lot to do, and I don't think we can predict the release it will all work in yet. Even then, it will only work with QT_USE_IMPORTED_TARGETS. qt4_use_modules also works without it. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Understanding...
David Cole wrote: > I think we should understand this before we simply exclude the test: > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d44e7b15ab40ba4568ce7c584df587c03caed40 > > Can you point us to the dashboard failure that occurred that you did > not understand? http://open.cdash.org/testDetails.php?test=156064823&build=2506759 Another is: http://open.cdash.org/testDetails.php?test=156133321&build=2511190 Additionally, it seems from the nightly results that exports on some Windows platforms don't work the same for C as for C++ projects: http://open.cdash.org/testSummary.php?project=1&name=Module.GenerateExportHeader&date=2012-08-12 I'm not certain what to do about the above, and I don't think I fully understand them. Also, it looks like the xlc FAIL_REGEX could be extended, but I'm not sure if -f is something special to the xlc compiler or if 'Cannot find or open file' should be added to the regex list: http://open.cdash.org/testDetails.php?test=156120254&build=2510696 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] ReactOS: Important filed bug reports went to backlog en masse
This was actually my exact intent (to re-involve the original reporters via the notification system, since nobody else has picked up on the bugs enough to assign them), and this was just step 1. The bug tracker's roadmap page and what bugs are actually assigned to active CMake developers are two of the most important pieces of information we can get from the bug tracker. Having a bunch of bugs in there that nobody has ever looked at is just as useless as allowing emails on the list to fall through the cracks without any responses. I intend to do the same thing with bugs that are actually assigned to developers that have not been updated in the last 3 or 4 months. (If it hasn't been updated, then it's not really "active"...) If you care about a bug that's assigned to you, and want to get it fixed in CMake 2.8.10, please update it by adding a note by setting the Target Version field and putting it on the roadmap page. The ones that people really care about will be brought back. If nobody cares about an issue, then it's not really an issue. The bug tracker is an imperfect measurement of "care", but it's one of the closest proxies that we have. Thanks for your comments, David On Sun, Aug 12, 2012 at 9:36 PM, Doug wrote: > Just idly, I wonder how practical it would be to automatically close > bugs older than XXX time that haven't been touched or assigned. > > If nothing else it'd generate a notification to the submitter of the > bug that either the bug was over looked or not considered important > and deserves some discussion if they want it fixed. > > I've read a few articles online about doing this sort of thing to > clear the 'fog' of irrelevant issues that clogs up bug trackers, esp. > public ones. > > ~ > Doug. > > On Sun, Aug 12, 2012 at 8:10 PM, David Cole wrote: >> I certainly did not mean to offend anyone with my en masse move of >> issues to 'backlog' -- thanks for speaking up. >> >> I would like to make sure that you guys can continue to use CMake for >> ReactOS. I've got to run right now, but I will reply again tomorrow >> when I have some more time. Do you have time for a quick phone call or >> Google+ hangout this week sometime, so I can understand better what >> your issues are? (And why nobody adopted them when they appeared on >> the mailing list in the form of your bug reports...) >> >> >> Thanks, >> David Cole >> >> >> On Sat, Aug 11, 2012 at 9:42 PM, Amine Khaldi >> wrote: >>> Hello folks, >>> >>> I would like to mention that many (if not all) the bugs coming from us >>> (ReactOS) got into backlog. >>> >>> We're an operating system project, we try to file bug report only for issues >>> that block us, so we do not tend to file trivial bugs. >>> >>> It would be great if the CMake folks tried to pay the attention that our >>> issues deserve.. after all, we started using CMake because we read many >>> positive reviews about the excellent support. >>> >>> Unfortunately, we're not able to use the VS generators due to the lack of >>> support for ASM preprocessed files. We're not able to pass flags to C/C++ >>> source files without affecting the rc (resource) files. We're forced to do >>> many ugly workarounds for the latter, and we found no solution for the >>> former, and these are just examples. >>> >>> All these mentioned issues got into the backlog, so basically we're left >>> off, without any help to get them solved. >>> >>> I'm writing this hopefully as a call to the CMake folks/community to address >>> our issues, that we've been waiting release after release to get them fixed, >>> only to find out that they ended up in backlog now. >>> >>> I'm writing this in the hopes of finding "a CMake developer who has the >>> bandwidth to take it on, and ferry a fix through to our 'next' branch for >>> dashboard testing". >>> >>> Regards, >>> Amine. >>> -- >>> >>> 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 -- Powered by www.kitware.com Visit other Kitware open-source
[cmake-developers] Bug tracker: I need your help
Hi everybody, I need your help. In the next week, if you have time. No doubt you're already sick of reading the emails about the bug tracker from the last couple of days. My main goal here is simply to be able to get a good picture of what's really happening by inspecting bug tracker query results. Goals: - have ZERO "new" bugs that are older than a week or two (new bugs should be assigned to somebody working on them, or sent to the backlog if nobody can take it on in the next 3 or 4 months) - have "assigned" actually mean that the assigned developer is actively working on the bug for the next release of CMake (or perhaps the release after that) - have everything else in the "backlog" for future consideration as developers become available to work on them So, to help achieve these goals, I'd like to ask for your help as follows: - please review your "assigned" bugs (606 among all of us) - if you will work at fixing it for CMake 2.8.10, set the Target Version field. If not, please change its status to "backlog." If you will work on it later, feel free to keep it assigned to you even while it's in the backlog. If you think it should belong to somebody else, please assign it to them for review, or assign it to nobody and just get it into the "backlog" - please review the 30 "new" bugs that are not yet assigned -- the ones that are left as new after my en masse send to backlog operations from the weekend are only from the last month of new bug submissions. If you can take one on, please assign it to yourself, if not, I'll put those in the backlog too after another week or so. - please review the 16 bugs marked as "feedback" "acknowledged" or "confirmed", all, if you can but especially those that are assigned to you -- set these as "assigned" if you'll be working on them, assign to somebody else if appropriate, or send to "backlog" if neither After all of this, the bug tracker should be in pretty good shape, and perhaps even indicate what people are actually working on for 2.8.10. Our average release (2.8.3 to 2.8.9) contains just 79 bug fixes. I'd like to be able to put about 60 to 80 on the roadmap for 2.8.10, and have the rest in the backlog for future consideration. That means that about 580 or so bugs are about to go to the "backlog." Thanks, thanks, THANKS! for your help, 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] Development pause for sweeping style changes
On 08/10/2012 09:27 AM, Brad King wrote: > Since the first step involves making 'master' and 'next' consistent > we plan to disable merge access to 'next' for the first couple days > of next week. Push access to the stage and merge access to 'next' have been disabled in preparation for this sweep. Thanks for your patience. -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] Unique compile definitions
Brad King wrote:
> On 08/10/2012 10:30 AM, Stephen Kelly wrote:
>> I've updated the branch with the API change to use std::set. The XCode
>> generator does not use the cmLocalGenerator::AppendDefines method, but
>> the VisualStudio6Generator does.
>
> That wasn't quite what I had in mind. The string of escaped
> defines for the command line should be paired with a set of
> raw defines.
I'm not a fan of duplicating the information so much, and having to pass
both a set and a string to the method to be modified to contain the define.
I uploaded a compromise compile-definitions-unique branch to my gitorious
(g...@gitorious.org:~steveire/cmake/steveires-cmake.git) which stores the
unescaped definition in the set, and escapes it in the JoinDefines method.
I'm not certain what behavior change you are referring to in the case there
is no duplicate (Ordering?).
Thanks,
Steve.
> Before appending definition to the end of the
> string test set insertion:
>
> if(defined.insert(def).second)
> {
> // first time we see this one
> ...rest of logic to append to "defines" string.
> }
>
> That way no behavior changes unless there is a duplicate.
> IMO it is also cleaner to store the unescaped original
> definitions in the std::set.
>
> -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] Bug tracker: I need your help
Am 2012-08-13 13:35, schrieb David Cole: Hi everybody, I need your help. In the next week, if you have time. No doubt you're already sick of reading the emails about the bug tracker from the last couple of days. My main goal here is simply to be able to get a good picture of what's really happening by inspecting bug tracker query results. Goals: - have ZERO "new" bugs that are older than a week or two (new bugs should be assigned to somebody working on them, or sent to the backlog if nobody can take it on in the next 3 or 4 months) I have added a comment to a few of them to help with that. But what I see is that there are a bunch of bugs for modules that have a maintainer (e.g. Boost, SWIG). I would just assign all bugs in modules to the module maintainers and first and let them judge if that is a useful bug after all. 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] : Module.GenerateExportHeader crash
There is a new failure here: http://open.cdash.org/testDetails.php?test=156059931&build=2506673 -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] : Module.GenerateExportHeader crash
Bill Hoffman wrote: > There is a new failure here: > http://open.cdash.org/testDetails.php?test=156059931&build=2506673 > Is the output truncated somehow, or is that really all of it? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Unique compile definitions
On 08/13/2012 09:09 AM, Stephen Kelly wrote: > I uploaded a compromise compile-definitions-unique branch to my gitorious > (g...@gitorious.org:~steveire/cmake/steveires-cmake.git) which stores the > unescaped definition in the set, and escapes it in the JoinDefines method. Even better, 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] : Module.GenerateExportHeader crash
On 8/13/2012 10:54 AM, Stephen Kelly wrote:
Bill Hoffman wrote:
There is a new failure here:
http://open.cdash.org/testDetails.php?test=156059931&build=2506673
Is the output truncated somehow, or is that really all of it?
I ran it in a debugger, and cmake was crashing, this fixed it, but I
don't think it is the right fix, but should let you know what is going on:
diff --git a/Source/cmNinjaTargetGenerator.cxx
b/Source/cmNinjaTargetGenerator.c
index 3532c8b..1e1c326 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -398,7 +398,7 @@ cmNinjaTargetGenerator
if(useClDeps)
{
-std::string cl = mf->GetDefinition("CMAKE_C_COMPILER");
+std::string cl = mf->GetSafeDefinition("CMAKE_C_COMPILER");
cl = "\"" + cl + "\" ";
cmdLine = clDepsBinary + " " + lang + " $in \"$DEP_FILE\" $out "
+ clShowPrefix + " " + cl + cmdLine;
mf->GetDefinition("CMAKE_C_COMPILER"); is returning null when cmake is
running on the test binary tree.
-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] Bug tracker: I need your help
On Mon, Aug 13, 2012 at 10:26 AM, Rolf Eike Beer wrote: > Am 2012-08-13 13:35, schrieb David Cole: > >> Hi everybody, >> >> I need your help. In the next week, if you have time. >> >> No doubt you're already sick of reading the emails about the bug >> tracker from the last couple of days. >> >> My main goal here is simply to be able to get a good picture of what's >> really happening by inspecting bug tracker query results. >> >> Goals: >> - have ZERO "new" bugs that are older than a week or two (new bugs >> should be assigned to somebody working on them, or sent to the backlog >> if nobody can take it on in the next 3 or 4 months) > > > I have added a comment to a few of them to help with that. But what I see is > that there are a bunch of bugs for modules that have a maintainer (e.g. > Boost, SWIG). I would just assign all bugs in modules to the module > maintainers and first and let them judge if that is a useful bug after all. > > Eike Thanks, Eike -- that's a great idea. I will make a pass through all the backlog bugs after everybody is done (hopefully within a week) and do just that: assign module bugs to the corresponding maintainers. This email should be seen by all of them as well, though, and I would want the same logic to apply to them: if they're not actively working on getting it fixed for 2.8.10, then it *should* be in the backlog. To be reviewed again later, as we start to plan the next release... Thx, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] qt4_use_modules
On 08/13/2012 03:41 AM, Stephen Kelly wrote: >>> What was the plan with the more generic target_use_package() or how it >>> was named ? This would do something similar, right ? > > target_use_targets() in the latest proposal. The discussion thread was here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615 >> I was wondering the same. And how close are we to having the more generic >> one working? > > So far Brad decided on the declarative syntax he wanted and implemented it > in a private branch. That was specifically for conditionals in generator expressions, not the whole feature: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=3965 I'll reply over there. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] conditionals in generator expressions
On 06/11/2012 11:27 AM, Brad King wrote: > I've started a local topic branch and implemented $<0:...>, > $<1:...>, and $. When I get a chance I'll add > some of the other queries, documentation, and tests for the > generator expression features. I've been making occasional progress on this. This morning I packaged up the results into a topic branch and pushed it here: https://gitorious.org/~bradking/cmake/bradkings-cmake/commits/generator-expression-conditions It includes basic documentation and extensive tests. I'll look at merging it after the development pause is over. > I don't think I'll have time to add new places like > INCLUDE_DIRECTORIES that evaluate values through > cmGeneratorExpression. It should be pretty straightforward > for you to try though. This is still the case. You can try it based on my topic. -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] Development pause for sweeping style changes
On 08/13/2012 08:35 AM, Brad King wrote: > On 08/10/2012 09:27 AM, Brad King wrote: >> Since the first step involves making 'master' and 'next' consistent >> we plan to disable merge access to 'next' for the first couple days >> of next week. > > Push access to the stage and merge access to 'next' have been disabled > in preparation for this sweep. Thanks for your patience. Three sweeping style change commits have been merged to 'next': http://cmake.org/gitweb?p=cmake.git;a=commit;h=7bbaa428 http://cmake.org/gitweb?p=cmake.git;a=commit;h=77543bde http://cmake.org/gitweb?p=cmake.git;a=commit;h=9db31162 The first one removes trailing whitespace. The second one converts CMake commands to lower case. The third one removes the arguments of else(), endif(), etc. as Stephen suggested. The three commits have been recorded with "Kitware Robot" as the author so that no one person gets blame/credit in "git blame" output. In the future "git blame" may report one of these sweeping commits. In that case, change the blame line to git blame 7bbaa428~1 -- path/of/file/to/blame.txt We will let this run through dashboard testing tonight on 'next'. If all is well then that will become 'master'. -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] Bug tracker: I need your help
On Monday 13 August 2012, David Cole wrote: > Hi everybody, > > I need your help. In the next week, if you have time. ... Done for my stuff. 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] ReactOS: Important filed bug reports went to backlog en masse
On 2012-08-13 06:54-0400 David Cole wrote: This was actually my exact intent (to re-involve the original reporters via the notification system, since nobody else has picked up on the bugs enough to assign them), and this was just step 1. The bug tracker's roadmap page and what bugs are actually assigned to active CMake developers are two of the most important pieces of information we can get from the bug tracker. Having a bunch of bugs in there that nobody has ever looked at is just as useless as allowing emails on the list to fall through the cracks without any responses. I intend to do the same thing with bugs that are actually assigned to developers that have not been updated in the last 3 or 4 months. (If it hasn't been updated, then it's not really "active"...) If you care about a bug that's assigned to you, and want to get it fixed in CMake 2.8.10, please update it by adding a note by setting the Target Version field and putting it on the roadmap page. The ones that people really care about will be brought back. If nobody cares about an issue, then it's not really an issue. The bug tracker is an imperfect measurement of "care", but it's one of the closest proxies that we have. Thanks for your comments, My comment is this is a really touchy political issue. To be a devil's advocate, backlogging is generally a slap in the face to those of us who have made an effort to present a careful, well-documented bug report which often includes a patch that fixes the issue. My impression is a lot of such high-quality bug reports are still ignored because of lack of resources to even make decisions on whether the proposed fix is acceptable or not, and this lack of resources to do decision making has now been formalized with the backlogging idea. Why should we try to make high-quality bug reports for CMake if we have to periodically do additional and completely non-productive work to justify not throwing our prior good effort on the trash heap (i.e., backlog)? Note, these are devil's advocate points, and I do personally understand the necessity of a measure like this to keep your limited bug-fixing resources focussed on issues where the bug reporter really cares about the outcome, and also to achieve higher signal-to-noise ratio in the bugtracker for issues that are not backlogged. But I would make sure that the period of time before a bug is backlogged is generous (at least a year), and I would advertise that period of time up front on the bugtracker as part of a notice that carefully justifies the measure and which also warns the would-be bug reporter that it is normally a long-term commitment to keep his bug report out of the trash heap if his bug report does not attract the attention of a CMake developer (regardless of whether they are salaried by Kitware or volunteer). Also, this whole issue is a clear sign that CMake does not have enough _organized_ bug report evaluation resources at the moment (for example, to simply test and evaluate all patches that appear on the bug tracker). My impression from all the traffic on this list is the volunteer development community for CMake is growing rapidly, but perhaps you (David) might be able to harness some of that volunteer energy by periodically giving a report on the numbers of unresolved bugs on the bugtracker and asking for volunteers to help with evaluation of those. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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] ReactOS: Important filed bug reports went to backlog en masse
On Mon, Aug 13, 2012 at 3:37 PM, Alan W. Irwin wrote: > On 2012-08-13 06:54-0400 David Cole wrote: > >> This was actually my exact intent (to re-involve the original >> reporters via the notification system, since nobody else has picked up >> on the bugs enough to assign them), and this was just step 1. >> >> The bug tracker's roadmap page and what bugs are actually assigned to >> active CMake developers are two of the most important pieces of >> information we can get from the bug tracker. >> >> Having a bunch of bugs in there that nobody has ever looked at is just >> as useless as allowing emails on the list to fall through the cracks >> without any responses. >> >> I intend to do the same thing with bugs that are actually assigned to >> developers that have not been updated in the last 3 or 4 months. (If >> it hasn't been updated, then it's not really "active"...) If you care >> about a bug that's assigned to you, and want to get it fixed in CMake >> 2.8.10, please update it by adding a note by setting the Target >> Version field and putting it on the roadmap page. >> >> The ones that people really care about will be brought back. If nobody >> cares about an issue, then it's not really an issue. The bug tracker >> is an imperfect measurement of "care", but it's one of the closest >> proxies that we have. >> >> >> Thanks for your comments, > > > My comment is this is a really touchy political issue. > > To be a devil's advocate, backlogging is generally a slap in the face > to those of us who have made an effort to present a careful, > well-documented bug report which often includes a patch that fixes the > issue. My impression is a lot of such high-quality bug reports are > still ignored because of lack of resources to even make decisions on > whether the proposed fix is acceptable or not, and this lack of > resources to do decision making has now been formalized with the > backlogging idea. Why should we try to make high-quality bug reports > for CMake if we have to periodically do additional and completely > non-productive work to justify not throwing our prior good effort on > the trash heap (i.e., backlog)? > > Note, these are devil's advocate points, and I do personally > understand the necessity of a measure like this to keep your limited > bug-fixing resources focussed on issues where the bug reporter really > cares about the outcome, and also to achieve higher signal-to-noise > ratio in the bugtracker for issues that are not backlogged. But I > would make sure that the period of time before a bug is backlogged is > generous (at least a year), and I would advertise that period of time > up front on the bugtracker as part of a notice that carefully > justifies the measure and which also warns the would-be bug reporter > that it is normally a long-term commitment to keep his bug report out > of the trash heap if his bug report does not attract the attention of > a CMake developer (regardless of whether they are salaried by Kitware > or volunteer). > > Also, this whole issue is a clear sign that CMake does not have enough > _organized_ bug report evaluation resources at the moment (for example, > to simply test and evaluate all patches that appear on the bug > tracker). My impression from all the traffic on this list is the > volunteer development community for CMake is growing rapidly, but > perhaps you (David) might be able to harness some of that volunteer > energy by periodically giving a report on the numbers of unresolved > bugs on the bugtracker and asking for volunteers to help with > evaluation of those. > > Alan > > __ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __ > > Linux-powered Science > __ Thanks for your comments, Alan. Your input is always much appreciated and valuable to the whole CMake community. I realize that this is a touchy subject, and tried very hard to word my messages that went along with this action to make it very clear that putting a bug into the 'backlog' is not in the least bit permanent. It literally takes just a second to flip a bug back to 'assigned' for those bugs that are deemed 'must fix'. The 'backlog' is just a bucket (of *open issues* by the way, not closed, and certainly not forgotten) that helps us to focus on the ones that are *not* in it. I am certainly not slapping anyone in the face, or questioning the value of anyone else's time. I do apologize to those of you that felt that way. It's a difficult jo
Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
Here are some simple facts: - There are presently 1,204 open issues in the CMake bug tracker. - We averaged 111 days per release from CMake 2.8.1 to CMake 2.8.9. - Each release contained an average of 79 bug fixes from 2.8.3 to 2.8.9. Hence.. I have a strong desire to focus in on approximately 79 bugs for the CMake 2.8.10 release, and shelve the remaining 1,125 bugs for future consideration. What we're doing here with the 'backlog' category is simply a focusing effort. Thank you, David On Mon, Aug 13, 2012 at 5:23 PM, David Cole wrote: > On Mon, Aug 13, 2012 at 3:37 PM, Alan W. Irwin > wrote: >> On 2012-08-13 06:54-0400 David Cole wrote: >> >>> This was actually my exact intent (to re-involve the original >>> reporters via the notification system, since nobody else has picked up >>> on the bugs enough to assign them), and this was just step 1. >>> >>> The bug tracker's roadmap page and what bugs are actually assigned to >>> active CMake developers are two of the most important pieces of >>> information we can get from the bug tracker. >>> >>> Having a bunch of bugs in there that nobody has ever looked at is just >>> as useless as allowing emails on the list to fall through the cracks >>> without any responses. >>> >>> I intend to do the same thing with bugs that are actually assigned to >>> developers that have not been updated in the last 3 or 4 months. (If >>> it hasn't been updated, then it's not really "active"...) If you care >>> about a bug that's assigned to you, and want to get it fixed in CMake >>> 2.8.10, please update it by adding a note by setting the Target >>> Version field and putting it on the roadmap page. >>> >>> The ones that people really care about will be brought back. If nobody >>> cares about an issue, then it's not really an issue. The bug tracker >>> is an imperfect measurement of "care", but it's one of the closest >>> proxies that we have. >>> >>> >>> Thanks for your comments, >> >> >> My comment is this is a really touchy political issue. >> >> To be a devil's advocate, backlogging is generally a slap in the face >> to those of us who have made an effort to present a careful, >> well-documented bug report which often includes a patch that fixes the >> issue. My impression is a lot of such high-quality bug reports are >> still ignored because of lack of resources to even make decisions on >> whether the proposed fix is acceptable or not, and this lack of >> resources to do decision making has now been formalized with the >> backlogging idea. Why should we try to make high-quality bug reports >> for CMake if we have to periodically do additional and completely >> non-productive work to justify not throwing our prior good effort on >> the trash heap (i.e., backlog)? >> >> Note, these are devil's advocate points, and I do personally >> understand the necessity of a measure like this to keep your limited >> bug-fixing resources focussed on issues where the bug reporter really >> cares about the outcome, and also to achieve higher signal-to-noise >> ratio in the bugtracker for issues that are not backlogged. But I >> would make sure that the period of time before a bug is backlogged is >> generous (at least a year), and I would advertise that period of time >> up front on the bugtracker as part of a notice that carefully >> justifies the measure and which also warns the would-be bug reporter >> that it is normally a long-term commitment to keep his bug report out >> of the trash heap if his bug report does not attract the attention of >> a CMake developer (regardless of whether they are salaried by Kitware >> or volunteer). >> >> Also, this whole issue is a clear sign that CMake does not have enough >> _organized_ bug report evaluation resources at the moment (for example, >> to simply test and evaluate all patches that appear on the bug >> tracker). My impression from all the traffic on this list is the >> volunteer development community for CMake is growing rapidly, but >> perhaps you (David) might be able to harness some of that volunteer >> energy by periodically giving a report on the numbers of unresolved >> bugs on the bugtracker and asking for volunteers to help with >> evaluation of those. >> >> Alan >> >> __ >> Alan W. Irwin >> >> Astronomical research affiliation with Department of Physics and Astronomy, >> University of Victoria (astrowww.phys.uvic.ca). >> >> Programming affiliations with the FreeEOS equation-of-state >> implementation for stellar interiors (freeeos.sf.net); the Time >> Ephemerides project (timeephem.sf.net); PLplot scientific plotting >> software package (plplot.sf.net); the libLASi project >> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); >> and the Linux Brochure Project (lbproject.sf.net). >> __ >> >> Linux-powered Science >> __ > > > Thanks for your comments, Alan. Your input is always much appreciated > and valuable to the whole CMake
Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
On 2012-08-13 17:23-0400 David Cole wrote: I realize that this is a touchy subject, and tried very hard to word my messages that went along with this action to make it very clear that putting a bug into the 'backlog' is not in the least bit permanent. I think the politics of this could be considerably eased if you also put a prominent announcement of what the backlog classification means on the first page of the bug tracker. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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 0013467]: Bug when $ is in the directory path
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13467
==
Reported By:kMh3Bt2pBM
Assigned To:
==
Project:CMake
Issue ID: 13467
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-08-13 22:36 EDT
Last Modified: 2012-08-13 22:36 EDT
==
Summary:Bug when $ is in the directory path
Description:
The following example shows that when '$' is in path, there is a bug in cmake
(on Mac OS but not linux).
/tmp/$/foo_build$ cmake ../foo
-- The C compiler identification is GNU 4.2.1
-- The CXX compiler identification is GNU 4.2.1
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/$/foo_build
/tmp/$/foo_build$ make
Scanning dependencies of target foo
make[2]: *** No rule to make target `/tmp/foo/main.cpp', needed by
`CMakeFiles/foo.dir/main.cpp.o'. Stop.
make[1]: *** [CMakeFiles/foo.dir/all] Error 2
make: *** [all] Error 2
/tmp/$/foo_build$ cat.sh ../foo/
CMakeLists.txt main.cpp
/tmp/$/foo_build$ cat.sh ../foo/*
==> ../foo/CMakeLists.txt <==
add_executable(foo main.cpp)
==> ../foo/main.cpp <==
int main()
{
return 0;
}
==
Issue History
Date ModifiedUsername FieldChange
==
2012-08-13 22:36 kMh3Bt2pBM New Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
