Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
On Sat, 31 Mar 2012, Stefano Lattarini wrote: > Note there's nothing I'm planning to do, nor I should do, in this regard: > the two setups described above are both already supported by the current > automake implementation (but the last one is not encouraged, even though > it makes perfect sense in some *rare* situations). I was just pointing > out that you have to choose one of these setups -- so, if you want to > distribute info files, you must accept to have them build in the srcdir. The approach used in GCC, for example in the libquadmath directory, is a --enable-generated-files-in-srcdir configure option that is used when building a release tarball - so normally the files go in the build directory, but a special configuration is used to put them in the source directory only when building releases. (This does not involve the "cygnus" option.) I think support for that seems more generically useful (and it makes sense to me for automake to look at features used in other packages' configure/build systems, that aren't inherently specific to those packages, and try to provide generic versions of them). The Binutils/GDB release tarball building process is substantially different and I'm not familiar with it. -- Joseph S. Myers jos...@codesourcery.com
Re: Binutils, GDB, GCC and Automake's 'cygnus' option
On Wed, 28 Mar 2012, Stefano Lattarini wrote: > - texinfo.tex is not required if a Texinfo source file is specified. The > assumption is that the file will be supplied, but in a place that > Automake cannot find. This assumption is an artifact of how Cygnus > packages are typically bundled. texinfo.tex is in a known location, but only a single copy for GDB and binutils and a single copy for GCC rather than in each directory needing it. Is the approach used (for example) in libquadmath/Makefile.am TEXINFO_TEX = ../gcc/doc/include/texinfo.tex considered a suitable approach for this case? > - Certain tools will be searched for in the build tree as well as in the > user's PATH. These tools are runtest, expect, makeinfo and texi2dvi. I did previously suggest removing the existing support for building and using these tools in-tree <http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01674.html>, but there was pushback on that. I don't know, however, if it actually depends on anything built into automake. > - The check target doesn't depend on all. I'm not aware of a need for that. -- Joseph S. Myers jos...@codesourcery.com
Re: Binutils, GDB, GCC and Automake's 'cygnus' option
On Wed, 28 Mar 2012, Stefano Lattarini wrote: > But this option is going to be deprecated in Automake 1.12.1 and removed in > Automake 1.13: > > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034> That page isn't very helpful since it doesn't give the non-deprecated way to achieve each part of the effect of "cygnus", if still desired (I think avoiding info documentation being built in the source directory, so that builds could use a non-writable source directory, may have been one part). Is there better transition documentation somewhere? -- Joseph S. Myers jos...@codesourcery.com
Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)
On Tue, 22 Nov 2011, Richard Stallman wrote: > 1. We start requiring GNU make in an "experimental" automake 2.0 >development line (which might, and will, break whathever >backward-compatibility gets in its way). > > If we want to experiment with this, we should not do so in Automake! > > Rather, one GNU package could drop support for ordinary Make, and see > how users react. If the level of complaint is not too high, then GCC dropped support for non-GNU make in version 3.4 (April 2004). -- Joseph S. Myers jos...@codesourcery.com
Re: RFE: allow for computed version number
Another variation on computed versions is also worth mentioning: GCC, Binutils, GDB and EGLIBC support configure options --with-pkgversion and --with-bugurl. --with-pkgversion changes the package name used in --version output (and in manuals), so you get e.g. GNU assembler (GNU Binutils for Ubuntu) 2.19.1 rather than GNU assembler (GNU Binutils) 2.19.1 which clearly marks the binary as being a particular distributor's version without requiring every distributor to maintain their own local patch to the same code changing the package name everywhere (and, if the version string includes a local version number for the packaged version, requiring changes every time that local version number changes). --with-bugurl changes the bug reporting information in --help output (and in manuals) to point to distributor-specific bug reporting information so bug reports for the modified version are directed to the distributor - again, without requiring everyone to have their own local patch to the same code. (<http://gcc.gnu.org/wiki/ConfigVersion> describes an early version of this configuration support.) It might make sense for there to be some direct support in auto* for this feature rather than each package needing to do it locally. -- Joseph S. Myers jos...@codesourcery.com
Re: Problem with building .info files?
On Sun, 19 Nov 2006, Daniel Franke wrote: > The targets quoted above do not employ automake but maintain the Makefile.in > directly and hence rely on handwritten rules for info, dvi, þdf and html > targets. To be consistent with gcc, but inconsistent with GNU coding > standards, it seems that I have to do the same?! Refer to how fastjar (which used automake) worked with --enable-generated-files-in-srcdir before it was removed from the GCC source tree. -- Joseph S. Myers [EMAIL PROTECTED]
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
On Thu, 28 Sep 2006, Nelson H. F. Beebe wrote: > The gcc folks could probably argue that -- is indeed ambiguous, > because there is no way to tell which of the following arguments are > intended for the preprocessor, the compiler, the assembler, or the > linker. There are already -W[x],-option,value options to direct > arguments to specific components. It's not ambiguous; the following arguments should all be treated as input files, not options, and whether the input files are compiled (and as what language) or linked is determined by their suffixes in the documented manner. Thus gcc -- -foo.c -lbar should compile the C source file "-foo.c" and link the resulting object with the object file called "-lbar" (not with the library libbar.a). This does require passing the "--" through to the linker (and I don't know if the linker supports -- as would be required), or rewriting the command as the equivalent gcc ./-foo.c ./-lbar -- Joseph S. Myers [EMAIL PROTECTED]
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
On Thu, 28 Sep 2006, Andreas Schwab wrote: > Eric Blake <[EMAIL PROTECTED]> writes: > > > If they really want to stop parsing options, and pass all remaining > > arguments to gcc, then they should be using -- between the options they > > give gcc and the remaining arguments that they pass unchanged. > > Which unfortunately does not work since gcc interprets -- as an ambigous > abbreviation instead of the end-of-option-marker. This is a GCC bug; please enter it in GCC Bugzilla if not already there. -- Joseph S. Myers [EMAIL PROTECTED]
