Re: AM_V_GEN - better docs
Patrick Rutkowski writes: > I don't get from that page how to apply to all my $(CC) build > commands, and I really want to quiet down this very messy "make" > output I now have. When silent-rules is enabled, you don't need to do anything special in Makefile.am for "normal" commands (those commands which get invoked via standard make rules), only those commands you invoke explicitly. For commands which you invoke explicitly, you can just add $(AM_V_GEN) before the command name, e.g., change: foo.barf: foo.blarghhh barfify -o $@ $< to: foo.barf: foo.blarghhh $(AM_V_GEN)barfify -o $@ $< That just prints "GEN foo.barf" when building foo.barf; to print something more target specific, you can follow the "pkg_..." example in the doc, e.g.: barf_verbose = $(barf_verbose_$(V)) barf_verbose_ = $(barf_verbose_$(AM_DEFAULT_VERBOSITY)) barf_verbose_0 = @echo " BARF " $@; foo.barf: foo.blarghhh $(barf_verbose)barfify -o $@ $< > The doc page there doesn't even suggest where to look to learn how > to apply it to your build. It does, kinda, but maybe it doesn't go far enough; right now it says: "To enable less verbose build rules, both the developer and the user of the package have to take a number of steps. The developer needs to do either of the following: + Add the silent-rules option as argument to AM_INIT_AUTOMAKE. + Call the AM_SILENT_RULES macro from within the configure.ac file." .. but even after you do that, silent-rules mode defaults to "off"; the user may then turn it on by using the --enable-silent-rules option to configure. Maybe it would be good to specify what the should be done to make it default to _on_, e.g.: "+ To enable silent-rules by default, specify an argument of "yes" to AM_SILENT_RULES, i.e., add "AM_SILENT_RULES([yes])" to the configure.ac file" [I know that because somebody else posted it on this list recently :] -miles -- "1971 pickup truck; will trade for guns"
Re: execvp: /bin/sh: Argument list too long
On Thu, Nov 11, 2010 at 09:54:35PM +0100, Ralf Wildenhues wrote: > > In other words, I can't make dist even with GNU make 3.82? What do you > > suggest, then? > > Well, you could try my patch from > http://article.gmane.org/gmane.comp.gnu.make.bugs/4219 > (append /raw to the URL to get it unmangled). > > I still think letting GNU make avoid the issue on Linux systems would be > the easiest way out here. > > As already written, alternative workarounds include reorganizing your > code a bit to have a bit more recursive makefile setup, so that each > makefiles' list would remain below the limit. Hi Ralf, I was able to reduce the number of files sufficiently so I am currently not hitting the limit. In the future, when more tests are added, I will go for your second suggestion. The testsuite/ directory won't suffer much from a recursive setup. I just need to move out the .as -> .c build rule to a common rules file included in all the testsuite makefiles as well as the main build makefile. Thanks, Pippijn signature.asc Description: Digital signature
Re: [RFC] Make build and install dirs used by distcheck configurable. (was: Re: absolute build directory with spaces)
Hello automakers and gnulibers. Is anyone still interested in this feature? If yes, I have some simple updates, second thoughts, and new ideas, for which comments are welcome. If not, let me know before I start investing more time on the implementation! On Monday 06 September 2010, Stefano Lattarini wrote: > On Sunday 05 September 2010, Ralf Wildenhues wrote: > > Hello, > > > > * Jim Meyering wrote on Sat, Sep 04, 2010 at 07:28:58PM CEST: > > > Stefano Lattarini wrote: > > > > What about instead making the names of the temporaries > > > > source/build/install directories used by "make distcheck" > > > > configurable? > It turns out that making the srcdir configurable is not very easy or > natural; also, I don't see any real use case for that. So I didn't > add this feature in the patch series. If anyone would find this > feature useful nonetheless, please speak up. > > > > This will offer more flexibility, and won't > > > > introduce still another automake option which would make > > > > backward-compatibility more problematic. > > > > > > > > I was thinking of something on these lines: > > > > $ cat Makefile.am > > > > ... > > > > AM_DISTCHECK_BUILDDIR_NAME = _ b u i l d ## will be relative to > > > > $(distdir) > > > > AM_DISTCHECK_SRCDIR_NAME = . ## likewise > > > > AM_DISTCHECK_INSTALLDIR_NAME = i...@l1 ## likewise > In the end, I went for the slighty shorter names `AM_DISTCHECK_BUILDDIR' > and `AM_DISTCHECK_INSTALLDIR'. > > > > > > > > If you like the proposal, I might try to implement this (but not > > > > right away). > > > > > > I do like it. Thanks! Nonetheless, I'm starting to think that making `AM_DISTCHECK_BUILDDIR_NAME' and `AM_DISTCHECK_INSTALLDIR_NAME' defined at configure time might be a better policy. This way we could: - warn about bad values for them at "./configure" time rather than at "make distcheck" time; - allow *any* character in their values (also `#' and single-quotes) - allow leading and trailing whitespaces in their values. - make it easier for developers working on more limited system to stick with less stressful values, thus avoiding potential spurious failures. Opinions? > > > > Me too, but the onus for quoting should probably be with the person > > defining the variables, because there is no well-defined way to do > > otherwise. (And of course you cannot have comments in variables.) This problems would be solved by having `AM_DISTCHECK_BUILDDIR_NAME' and `AM_DISTCHECK_INSTALLDIR_NAME' properly processed at configure time. > In my patch, I let Automake take the onus for quoting, the only additional > limit being that AM_DISTCHECK_BUILDDIR and AM_DISTCHECK_INSTALLDIR cannot > contain the single-quote character. Not entirely true, in hindsight. They also can not contain the `#' character and leading and trailing whitespaces. > We might still change this of course, as the attached patch is mostly > tentative. > > I like it also because some packages will never want to care about > > being buildable under more stressful circumstances. Also, some developers will never want to care about making distcheck under more stressful circumstances on some more limited systems. The "configure-time definition" policy would cater to this situation, too. > IMPORTANT NOTE: I still haven't run the whole testsuite against this > patch. I will if they are no serious objection or proposals of > changes/extensions. > > Regards, > Stefano > > -*-*-*- > > Make build and install dirs used by distcheck configurable. > > * automake.in (generate_makefile): Define makefile variables > AM_DISTCHECK_BUILDDIR and AM_DISTCHECK_INSTALLDIR when needed; > they default respectively to `_build' and `_inst'. > * lib/am/distdir.am (distcheck): Sanitize and honour variables > $(AM_DISTCHECK_BUILDDIR) and $(AM_DISTCHECK_INSTALLDIR). > * tests/distcheck0.test: New test script. > * tests/distcheck1a.test: Likewise. > * tests/distcheck1b.test: Likewise. > * tests/distcheck2a.test: Likewise. > * tests/distcheck2b.test: Likewise. > * tests/distcheck3.test: Likewise. > * tests/distcheck4.test: Likewise. > * tests/distcheck5.test: Likewise. > * tests/distcheck6.test: Likewise. > * tests/distcheck7.test: Likewise. > * tests/distcheck8.test: Likewise. > * tests/distcheck9.test: Likewise. Clearer and more expressive names for the new testcases are in order, also. > * tests/Makefile.am (TESTS): Updated. Regards, Stefano
Re: AM_V_GEN - better docs
Hello Patrick, Miles, * Miles Bader wrote on Fri, Nov 12, 2010 at 09:00:55AM CET: > Patrick Rutkowski writes: > > I don't get from that page how to apply to all my $(CC) build > > commands, and I really want to quiet down this very messy "make" > > output I now have. *snip explanations* Thanks. A doc change to improve the situation here would be nice; any volunteers? For example, the silencing stuff could be part of a new section somewhere between the "Miscellaneous" and the "Not Enough" nodes, and it could treat `make -s', `make >/dev/null || make' and other tricks as well as a discussion of silent-rules and maybe even the tradeoffs mentioned in automake/lib/am/depend2.am. (There is no need that a patch does all of this, just one step would be nice already.) > > The doc page there doesn't even suggest where to look to learn how > > to apply it to your build. > > It does, kinda, but maybe it doesn't go far enough; Yes, but I agree that it's also still fairly obscure. Especially the `make V=1' part probably cannot be documented too prominently. [...] > Maybe it would be good to specify what the should be done to make it > default to _on_, e.g.: > > "+ To enable silent-rules by default, specify an argument of "yes" > to AM_SILENT_RULES, i.e., add "AM_SILENT_RULES([yes])" to the > configure.ac file" > > [I know that because somebody else posted it on this list recently :] We've intentionally not documented that yet, because we weren't sure whether it's a good idea having this functionality. At least some distro maintainers would be more happy to see less bug reports with too little data because of this. It might be time to reconsider this decision. Cheers, Ralf
Re: AM_V_GEN - better docs
On Friday 12 November 2010, Ralf Wildenhues wrote: > Hello Patrick, Miles, > > * Miles Bader wrote on Fri, Nov 12, 2010 at 09:00:55AM CET: > > Patrick Rutkowski writes: > > > I don't get from that page how to apply to all my $(CC) build > > > commands, and I really want to quiet down this very messy "make" > > > output I now have. > *snip explanations* > > Thanks. A doc change to improve the situation here would be nice; > any volunteers? I might give it a try (not right now); but I'll probably need some guidance, as I'm not well up on the issue. > For example, the silencing stuff could be part of > a new section somewhere between the "Miscellaneous" and the "Not > Enough" nodes, and it could treat `make -s', `make >/dev/null || make' > and other tricks as well as a discussion of silent-rules and maybe even > the tradeoffs mentioned in automake/lib/am/depend2.am. > (There is no need that a patch does all of this, just one step would > be nice already.) Good. > > > The doc page there doesn't even suggest where to look to learn how > > > to apply it to your build. > > > > It does, kinda, but maybe it doesn't go far enough; > > Yes, but I agree that it's also still fairly obscure. > Especially the `make V=1' part probably cannot be documented > too prominently. > > [...] > > > Maybe it would be good to specify what the should be done to make it > > default to _on_, e.g.: > > > > "+ To enable silent-rules by default, specify an argument of "yes" > > to AM_SILENT_RULES, i.e., add "AM_SILENT_RULES([yes])" to the > > configure.ac file" > > > > [I know that because somebody else posted it on this list recently :] > > We've intentionally not documented that yet, because we weren't sure > whether it's a good idea having this functionality. At least some > distro maintainers would be more happy to see less bug reports with too > little data because of this. > > It might be time to reconsider this decision. If we document it, we should at least advise against it IMHO. Regards, Stefano
Re: AM_V_GEN - better docs
Patrick Rutkowski writes: > I don't get from that page how to apply to all my $(CC) build > commands, and I really want to quiet down this very messy "make" > output I now have. When silent-rules is enabled, you don't need to do anything special in Makefile.am for "normal" commands (those commands which get invoked via standard make rules), only those commands you invoke explicitly. For commands which you invoke explicitly, you can just add $(AM_V_GEN) before the command name, e.g., change: foo.barf: foo.blarghhh barfify -o $@ $< to: foo.barf: foo.blarghhh $(AM_V_GEN)barfify -o $@ $< That just prints "GEN foo.barf" when building foo.barf; to print something more target specific, you can follow the "pkg_..." example in the doc, e.g.: barf_verbose = $(barf_verbose_$(V)) barf_verbose_ = $(barf_verbose_$(AM_DEFAULT_VERBOSITY)) barf_verbose_0 = @echo " BARF " $@; foo.barf: foo.blarghhh $(barf_verbose)barfify -o $@ $< > The doc page there doesn't even suggest where to look to learn how > to apply it to your build. It does, kinda, but maybe it doesn't go far enough; right now it says: "To enable less verbose build rules, both the developer and the user of the package have to take a number of steps. The developer needs to do either of the following: + Add the silent-rules option as argument to AM_INIT_AUTOMAKE. + Call the AM_SILENT_RULES macro from within the configure.ac file." .. but even after you do that, silent-rules mode defaults to "off"; the user may then turn it on by using the --enable-silent-rules option to configure. Maybe it would be good to specify what the should be done to make it default to _on_, e.g.: "+ To enable silent-rules by default, specify an argument of "yes" to AM_SILENT_RULES, i.e., add "AM_SILENT_RULES([yes])" to the configure.ac file" [I know that because somebody else posted it on this list recently :] -miles -- "1971 pickup truck; will trade for guns"
Re: AM_V_GEN - better docs
On Sat, Nov 13, 2010 at 5:19 AM, Stefano Lattarini wrote: >> It might be time to reconsider this decision. > If we document it, we should at least advise against it IMHO. ... or just give the pros and cons. That seems likely to be more convincing and less annoying... -miles -- Cat is power. Cat is peace.
