reporting requirements [Re: does not rebuild Makefile.in]
As for the original (not of make) issue, confirming my [not a bug] posted on Wed, 20 Aug 2008 22:49:44 +0400 ([EMAIL PROTECTED]). As for attitude expressed in your reply of Wed, 20 Aug 2008 02:57:21 +0400 (MSD) ([EMAIL PROTECTED]), it is pretty widespread in many free sofware mailing lists, fora, so commenting on it. You wrote: Nice way to be helpful Followed it with assorted what was this, what was that questions, followed by Are we supposed to just *guess*??! This may seem justified, and is at least understandable. And complying with all of this takes in most cases even more work than isolating (and even possibly fixing) the bug entirely on one's own. So the posting becomes pointless. Sadly, with this particular software issue it was exactly what happened. The lesson? In [[The Moon Is A Harsh Mistress]] (by Robert A. Heinlein) even a machine Mike was designed, even before augmented, to answer questions tentatively on insufficient data like you do Mike was designed to operate on incomplete data. People are generally able to do that pretty well. This is reason for users posting issues (including me) to hope ones replying to exercise this ability, rather than request users to supply complete data ;-) . You'd rather make people Posted message by itself makes people do nothing. Also note the detailed bug description (of Wed, 20 Aug 2008 22:43:38 +0400 ([EMAIL PROTECTED])) on [EMAIL PROTECTED] (and proposed fix (of Wed, 20 Aug 2008 22:43:53 +0400 ([EMAIL PROTECTED])) on [EMAIL PROTECTED]). The bug is shown to be pretty portable, its manifestation thus does not depend on (answers to) most of your [what was?] questions. Trying random automake input ((source) package) made perfect sense. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: reporting requirements [Re: does not rebuild Makefile.in]
On Thu, 2008-08-21 at 23:50 +0400, Ilya N. Golubev wrote: This may seem justified, and is at least understandable. And complying with all of this takes in most cases even more work than isolating (and even possibly fixing) the bug entirely on one's own. So the posting becomes pointless. Yes. That's a GOOD THING, and exactly what Philip intended. People reading this list are volunteers. No one is getting paid, and in fact most people are helping here to the detriment of other things they could be doing for their jobs, families, health, recreation, etc. As such, it's incumbent upon the people asking for help to not abuse this generosity. That means making an honest, _serious_ effort to solve problems yourself _before_ asking for help. By asking for all this information and requiring people to provide it, we are ensuring not only that we can actually help them, but also that they've made enough of an effort to fix their own problem that it's worthwhile for us to take time from whatever other important things we're doing to assist them. You're exactly right that half the time the effort they put in to collecting all this data leads them to find the problem themselves, and then they can delete the email they're writing to the list. That's the best possible outcome for everyone; it's what we hope for. Yes, of course, we are smarter than machines and we are able to infer a lot from less data, if we want to expend the effort to do so. But we don't want to expend that effort. We have no reason to make that effort to help people who won't first spend some effort to help themselves. It may sound harsh, and some people will put it more bluntly than others, but that's the way things work in open source software. You aren't paying for support with money, but that doesn't mean it's free. Instead you have to pay for it with effort. Plus, look at it this way: by making that effort and fixing your own problem you learned a lot more than you would have if we'd just given you the answer :-). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
not a bug [does not rebuild Makefile.in]
Considering what desribed in does not rebuild Makefile.in posted on Tue, 19 Aug 2008 23:55:34 +0400 to bug-make@gnu.org ([EMAIL PROTECTED]) to be bug of `make' input, more precisely, that of automake (generating said input). The issue for `make' considering thus closed, not a bug, invalid. My apologies. Described the automake bug in Makefile.in in subdir not generated posted to [EMAIL PROTECTED] on ([EMAIL PROTECTED]). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
does not rebuild Makefile.in
Version: 3.81
Occurs in any `Makefile' obtained from
Makefile.in generated by automake 1.10.1 from Makefile.am.
so reproducing should be easy. `automake' args was:
--gnu
All `Makefile' modification was removing `Makefile' target. The
reason was obvious: otherwise `make' would fail due to `Makefile' not
remade.
Build and source directories were different.
Below, assuming that `srcdir' shell variable has the same value as in
`Makefile', so that can refer to it in shell commands.
Invoked:
rm -f ${srcdir}/Makefile.in;make ${srcdir}/Makefile.in
`make' invoked no commands to remake it.
This also means that, with unchanged `Makefile' generated
automatically, can not remake it.
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: does not rebuild Makefile.in
On Tue, Aug 19, 2008 at 1:55 PM, Ilya N. Golubev [EMAIL PROTECTED] wrote: ... Occurs in any `Makefile' obtained from Makefile.in generated by automake 1.10.1 from Makefile.am. so reproducing should be easy. You'd rather make people download and install something they may not need instead of copy-n-pasting the Makefile into to your email. Nice way to be helpful there when asking for help! Note that you haven't actually provided enough information to reproduce the situation even if I did have a copy of automake 1.10.1 on hand: what specific package was this with? What arguments were passed to 'configure'? What directory layout? What arguments passed to make? Are we supposed to just *guess*??! All `Makefile' modification was removing `Makefile' target. Umm, what? If you remove the 'Makefile' target, then why would make care that the Makefile.in file is out of date? Are you including it as a target on the command line? For that matter, how are you invoking make in your tests? Please describe the behavior when you do *not* edit the Makefile to remove the 'Makefile' target. The reason was obvious: otherwise `make' would fail due to `Makefile' not remade. Could you please show the actual command output and error messages and makefile contents? Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
