Re: Autoconf Digest, Vol 3, Issue 18

[Fred Cook]

address@hidden wrote:

> Send Autoconf mailing list submissions to
>         address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.gnu.org/mailman/listinfo/autoconf
> or, via email, send a message with subject or body 'help' to
>         address@hidden
>
> You can reach the person managing the list at
>         address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Autoconf digest..."
>
> Today's Topics:
>
>    1. Automake 1.7.2b uploaded (beta for 1.7.3) (Alexandre Duret-Lutz)
>    2. Re: Literate programming with noweb ... (Paul Eggert)
>    3. must find the version of gcc (Fred Cook)
>    4. Re: must find the version of gcc (Bob Proulx)
>    5. Re: must find the version of gcc (Ralf Corsepius)
>
> ----------------------------------------------------------------------
>
> Date: Wed, 12 Feb 2003 19:06:44 +0100
> From: Alexandre Duret-Lutz <address@hidden>
> To: address@hidden, address@hidden
> Cc: address@hidden
> Cc: address@hidden
> Subject: Automake 1.7.2b uploaded (beta for 1.7.3)
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Reply-To: address@hidden
> Message: 1
>
> Hi people!
>
> Here is a snapshot of the 1.7.x branch of Automake.
>
>   ftp://alpha.gnu.org/gnu/automake/automake-1.7.2b.tar.gz
>   ftp://alpha.gnu.org/gnu/automake/automake-1.7.2b.tar.bz2
>   ftp://sources.redhat.com/pub/automake/automake-1.7.2b.tar.gz
>   ftp://sources.redhat.com/pub/automake/automake-1.7.2b.tar.bz2
>
> This should be reasonably close to what 1.7.3 will be.
> Please test it and report any problem you have to <address@hidden>.
> I hope we can release 1.7.3 by the middle of next week.
>
>   There is a known bug with VPATH handling of Texinfo and Lex rules
>   which isn't fixed here.  This affects all 1.7.x versions for Texinfo
>   rules.  I think older versions will also fails on Lex rules but I
>   haven't verified.  This is triggered during VPATH builds with (at
>   least) Tru64 make, FreeBSD (current) make, and OpenBSD (3.2) make.
>   In short, these make implementations will *not* perform a
>   VPATH search for dependencies which appear as targets in Makefiles.
>   As far as BSD make is concerned this seems to be a recent change in
>   its behavior, as I believe it worked fine in the past.
>   Fixing this requires too much changes for the 1.7.x branch.
>
>   The following failures in the test suite can denote this bug:
>     lex3.test, txinfo3.test, txinfo13.test, txinfo16.test, txinfo18.test
>
>   Please report these failures anyway, with your system's version,
>   so we know more precisely where this happens.
>
> Here is a list of changes since 1.7.1.  Those that worry me the more
> are the changes to elisp compilation, and the changes to depcomp.  If
> you can test these, by all means please do!
>
> Bugs fixed in 1.7.2b:
> * Fix stamp files numbering (when using multiple AC_CONFIG_HEADERS).
> * Query distutils for `pythondir' and `pythonexecdir', instead of
>   using an hardcoded path.  This should allow builds on 64-bit
>   distributions that usually use lib64/ instead of lib/.
> * AM_PATH_PYTHON will also search for python2.3.
> * elisp files are now built all at once instead of one by one. Besides
>   incurring a speed-up, this is required to support interdependent elisp 
> files.
> * Support for DJGPP:
>   - `make distcheck' will now work in `_inst/' and `_build' instead
>     of `=inst/' and `=build/'
>   - use `_dirstamp' when the file-system doesn't support `.dirstamp'
>   - more changes that affect only the Automake package (not its output)
> * Fix some incompatibilities with upcoming perl-5.10.
> * Properly quote AC_PACKAGE_TARNAME and AC_PACKAGE_VERSION when defining
>   PACKAGE and VERSION.
> * depcomp fixes:
>   - dashmstdout and dashXmstdout modes: don't use `-o /dev/null', this
>     is troublesome with gcc and Solaris compilers. (PR/385)
>   - makedepend mode: work with Libtool. (PR/385 too)
>   - support for ICC.
> * better support for unusual gettext setups, such as multiple po/ directories
>   (PR/381):
>   - Flag missing po/ and intl/ directories as warnings, not errors.
>   - Disable these warnings if po/ does not exist.
> * Noteworthy manual updates:
>   - New FAQ chapter.
>   - Document how AC_CONFIG_AUX_DIR interacts with missing files.
>     (Debian Bug #39542)
>   - Document `AM_YFLAGS = -d'.  (PR/382)
>
> --
> Alexandre Duret-Lutz
>
> ------------------------------
>
> Date: 12 Feb 2003 12:20:47 -0800
> From: Paul Eggert <address@hidden>
> To: "Scott D. Brown" <address@hidden>
> Cc: address@hidden
> Subject: Re: Literate programming with noweb ...
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden> <address@hidden>
>         <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 2
>
> "Scott D. Brown" <address@hidden> writes:
>
> > 1. Can I introduce a "rule" into my Makefile.am (just like a normal
> >     Makefile) that would define how to produce a .o file from the .nw
> >     file.
>
> Sure.
>
> > 2. How do I teach automake that when foo.cpp needs
> >     foo.h that it can be generated from foo.nw using the provided rule.
>
> You can give a rule for generating .h files from .nw files.
>
> Traditionally, "make" has a bit of trouble if a single command
> produces multiple output files, e.g., yacc -d produces both a .h and a
> .c file.  It sounds like you may run into that bit of trouble too; but
> it's usually not a big deal with yacc, since yacc -d updates the
> timestamps of both files.
>
> ------------------------------
>
> Date: Wed, 12 Feb 2003 17:26:43 -0800
> From: Fred Cook <address@hidden>
> To: address@hidden
> Subject: must find the version of gcc
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Precedence: list
> Message: 3
>
> Hi all,
>
> We have a need to find the version of gcc (and ld).  What is the correct
> way of doing this?
>
> -Fred
>
> ------------------------------
>
> Date: Wed, 12 Feb 2003 21:21:28 -0700
> From: address@hidden (Bob Proulx)
> To: Fred Cook <address@hidden>
> Cc: address@hidden
> Subject: Re: must find the version of gcc
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 4
>
> Fred Cook wrote:
> >
> > We have a need to find the version of gcc (and ld).  What is the correct
> > way of doing this?
>
> Generally GNU software implement a '--version' option which will print
> out the version of the program.  There is usually a '--help' as well
> which prints the online documentation.
>
>   gcc --version
>
>   ld --version
>
> Bob
>
> ------------------------------
>
> Date: 13 Feb 2003 07:15:17 +0100
> From: Ralf Corsepius <address@hidden>
> To: Autoconf List <address@hidden>
> Subject: Re: must find the version of gcc
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
> Content-Type: text/plain
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Precedence: list
> Message: 5
>
> Am Don, 2003-02-13 um 02.26 schrieb Fred Cook:
> > Hi all,
> >
> > We have a need to find the version of gcc (and ld).  What is the correct
> > way of doing this?
> Normally, you don't want to do this, because this contradicts autoconf's
> working principles of checking for a tools feature's and not to reley on
> tables of versions of a tool.
>
> Ralf
>
> ------------------------------
>
> _______________________________________________
> Autoconf mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/autoconf
>
> End of Autoconf Digest, Vol 3, Issue 18
> ***************************************

The situation we are up against is this:  We have a product that requires python
for the build process, which is OK.  This product is built on many platforms,
including solaris 2.8.  If you use gcc 3.2.1 to compile the product on solaris 
2.8
then our standard version of python (1.5) will break the build.  If the user
upgrades to python 2.2 then they must also upgrade binutills to 2.13.2 because
binutills 2.13 will not link against python 2.2.   The initial idea was to test
for solaris 2.8, gcc3.2.1, python < 2.2  and binutills < 2.13.2 and if all this 
is
found have configure gen an error message and stop it's work.  What you are 
saying
is to gen a test program and have gcc 3.2.1 compile/link  it with python and if 
it
fails then gen an error message and quit.  This is all OK, but it maybe easier 
to
upgrade to python 2.2 and be done with it.

Thanks for the info

-Fred