Re: forwarded message from NIIBE Yutaka
I've been working for porting GNU/Linux to Hitachi SuperH processor. (Please visit http://www.m17n.org/linux-sh/ for the project.) SuperH is the CPU for embedded target, PDA, and video game machine. Our target tuple would be: SH-VENDER-LINUX-GNU [...] Currently, there's the broad vendor as "PC". But the target for SuperH is not PC. How should we name the vendor? Any comments are appriciated. How about using "unknown"? ie. sh-unknown-linux-gnu This is what is typically done for embedded targets. Ben
config.* files via FTP
These files are now checked out and placed in: ftp://ftp.gnu.org/pub/gnu/config/ You can use this as a means of getting the latest versions if you'd rather not bother with anonymous CVS. Ben
Re: config.[guess|sub] (WAS: Re: Is this a bug in autoconf? (patchincluded))
Hi, But anyway, let's apply this patch, it is a basis for further changes. For instance we might implement --update which could wget the files if possible, and --report which could automatically send the message. We have already talked about this some time ago. I'm happy to apply this patch as a step in the right direction. It's been needed for quite some time. I made a minor grammatical fix to your output, plus this important fix to the config.sub patch (you did test it, right?) --version | --vers* | -V ) echo "$version" ; exit 0 ;; ^ `- was just "version" I'm checking the patches in now. Thanks, Ben
Concurrent tests?
With the exception of prerequisite tests, tests in Autoconf are conceptually independent. You can carry out AC_PROG_LEX and AC_PROG_YACC concurrently. Has any thought been given to heading in this direction in the future? On 8-way Linux machines, build times can be dominated by the `configure' script--once configured, a tree can be compiled in a fraction of the overall time. Perhaps the introduced complexity isn't worthwhile, but I wanted to start a discussion. Ben
[mikpos@home.com] proposal for autoconf languages
--- start of forwarded message ---
Return-Path: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Mime-Version: 1.0
From: mike burrell [EMAIL PROTECTED]
Sender: "mike burrell,,," [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: proposal for autoconf languages
Date: Sat, 23 Sep 2000 17:30:30 -0600
i've been trying to wrap autoconf around one of my projects (in progress).
the problem is that my project relies heavily on Objective C. as i'm sure
you know, there is no AC_LANG_OBJC macro :). i'm finding that for Objective
C related things, i'm needlessly reimplementing some of the already existing
macros, e.g. AC_TRY_COMPILE.
rather than proposing AC_LANG_OBJC (which actually wouldn't be too hard),
i'm proposing an AC_LANG_CUSTOM. syntax might look like so:
AC_LANG_CUSTOM(language-name, extension[, compiler[, flags[,
cross]]])
which, in my case, might look something like:
AC_LANG_CUSTOM(Objective C, m, $OBJCC, $OBJCFLAGS)
or maybe
AC_LANG_CUSTOM(Objective C, m, gcc)
or something to that effect.
example (beginnings of) code might look something like:
dnl AC_LANG_CUSTOM()
AC_DEFUN(AC_LANG_CUSTOM,
[define([AC_LANG], $1)dnl
ac_ext=$2
ac_compile='$3 -c $4 $CPPFLAGS conftest.$ac_ext 1AC_FD_CC'
ac_link='$3 -o conftest${ac_exeext} $4 $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS
1AC_FD_CC'
cross_compiling=$5
])
which i've patterned after AC_LANG_C
there are still some things i have yet to figure out: how this would work
with LANG_SAVE and LANG_RESTORE; how to intelligently search for a compiler
(analogous to AC_PROG_CC).
quite frankly i was hoping that you (or someone you know) might have time to
think about this and/or start implementing it. i have a few projects that
i'm working on already that i would like to finish first. if you need to
discuss it more or want me to provide some trivial code, then i can do that,
so long as i don't have to do something that's going to take me days to do
:). i just thought about it a bit this afternoon and there's nothing about
it to me that immediately makes it seem impractical. personally, i think
this would be a much cleaner solution than having a myriad of AC_LANG_*.
cheers
--
/"\ m i k e b u r r e l l
\ / ASCII RIBBON CAMPAIGN [EMAIL PROTECTED]
XAGAINST HTML MAIL,
/ \ AND NEWS TOO, dammit finger [EMAIL PROTECTED] for GPG key
--- end of forwarded message ---
config.guess Linux overhaul
It's that time again. The config.guess script is losing on GNU/Linux and this time, I'm going to fix it. Background: on many GNU/Linux systems, config.guess uses the output of `ld --help' to determine which architecture, object file format and C library version the build system uses. The script loses because it assumes that the primary configuration will appear first in the `supported emulations:' printed by ld(1). This is flawed because a) this is not a meaningful constraint and b) some distributions, such as Caldera OpenLinux, provide a linker that has support for linking in many, many environments (like coff-z8k, if that grabs you!). Instead, I am seeking to replace this cruft with a cleaner and more portable alternative. After much deliberation, the best I have come up with is to use file(1) from GNU fileutils, which is *very* likely to be present on every GNU/Linux system. The one drawback here is that it doesn't help me determine the version of libc installed on the system--and there may even be multiple versions. Which is the "primary"? The one that the current C compiler will link against? Comments, please. Ben
Linux config.guess overhaul
After much pondering on how to best solve the much-needed cleanup for Linux detection in config.guess, I have made a start. Some of the grossness will remain with us for some time until I can be sure that there will be very few users on certain systems--such as a.out SPARC Linux. In the meantime, the development version of config.guess is in subversions.gnu.org's CVS repository on the linux-overhaul-20010122 branch. I have made a rough first pass at this today, although some systems have been intentionally omitted until I receive necessary information. Please try it out and report on failures so I can add support for those systems. Thanks, Ben
Re: Jack Bryans: Re: [ntp:bugs] NeXT vs k25 w/patch
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim autoconf (config.guess) doesn't seem to autodetect NeXT. Akim Jack has the box - if folks have suggestions on how we can fix this it Akim would be appreciated. This is a fairly recently introduced bug in config.guess :-(. Another NeXT user reported the same problem a day or two ago and I'm in the process of fixing it now. Ben
Master for move-if-change?
Is Autoconf the master project these days for the move-if-change script? Thanks, Ben signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Quieten move-if-change?
move-if-change currently outputs file is unchanged when it does nothing. This adds undue noise in GCC builds. Would it be possible to give it more natural behaviour like mv(1) and output nothing, regardless of whether it moves the file? Ben signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, May 20, 2013 at 02:54:20PM +0800, Paul Wise wrote: There are thousands of copies of config.guess/sub (or configure scripts) out there (in tarballs) with no support for this at all. Once it is added to config.guess/sub in git (or autoconf) then it will take many years before the majority of copies of config.guess/sub (or configure scripts) have support for this. This is what I mean by bootstrap phase. Right. Just thinking out loud: isn't the Autoconf concept of aux dir of use here? That's where configure looks for config.guess. The latest version of install-sh, config.guess, etc. could live in such a system-wide directory. Unfortunately, it's not possible to set auxdir from the configure command line as you can with --srcdir, etc. Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
When it comes to people building distro packages, here is another idea
thinking out loud. What's wrong with ..
$ find /tree/of/src/trees -name config.guess -exec ln -sf /etc/config.guess {}
\;
This puts the latest version into the tree, no patching required.
Ben
signature.asc
Description: Digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 07:56:47AM -0400, Earnie Boyd wrote: if [[ -f /usr/local/share/config/config.guess ]] then . /usr/local/share/config/config.guess exit fi First, this does not solve the problem because it requires that every package get a new version of config.guess. We're trying to overcome having to modify every package. Second, I don't like the idea of doing things that surprise users. That will confuse people. Cheers, Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 07:33:49AM -0400, Earnie Boyd wrote: People forgetting about the symlink during distribution of their package. Not all systems support it. Using cp -f would be better. OK, fine. :-) I think there are a few different use cases people have in mind. My understanding of the issue is that people responsible building large numbers of autoconfiscated packages for distros (eg, Debian) are the ones with the real headaches. I tend to use a sub module repository and have config.guess and config.sub in a directory (build-aux/) and I tell autoconf via configure.ac where to find it. Yes, but that requires re-running autoconf. I think we're trying to avoid that because if configure.in is old, you may have a lot of work to do to get autoreconf to work. Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 08:21:09AM -0400, Earnie Boyd wrote: First, this does not solve the problem because it requires that every package get a new version of config.guess. We're trying to overcome having to modify every package. So that's your objection to the symlink/copy idea as well? No .. I don't have any objection to that. It's a rather unobtrusive way and will work with every package, regardless of vintage. Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
I suggested a simple, low impact way of updating the files, particularly for people wanting to build a large number of packages (eg, for a distro). Can anyone tell me why this approach is not satisfactory? Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: config.guess problem with pgcc
On Wed, Aug 20, 2014 at 11:04:52AM -0600, Eric Blake wrote: Oops, I totally overlooked what file you were patching. Autoconf doesn't maintain config.guess; you'll probably want to resubmit the patch upstream to config-patches (cc'd), as mentioned in the header of that file. Once it is upstream, the next autoconf release will automatically pick up the latest copy of that file. I am pretty sure a similar patch has already been applied to the master revision of config.guess: commit 6947a35648e577c2e3a12d5c88d488c6ea94e1c0 Author: Urs Janssen u...@akk.org Date: Wed Feb 12 22:13:37 2014 +1100 * config.guess (Linux|GNU|GNU/*): Strip extraneous whitespace inserted by the preprocessor (eg, pgcc -E). Cheers, Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
--site option
My generated configure script recognises a --site option: -site | --site | --sit) ac_prev=site ;; -site=* | --site=* | --sit=*) site=$ac_optarg ;; However, $site is never referred to. What's the purpose of this? Is it meant to be a command line analogue for the CONFIG_SITE environment variable? Cheers, Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: --site option
On Sun, Apr 03, 2016 at 02:40:57PM -0700, Paul Eggert wrote: > If memory serves, there used to be a -site option in all 'configure' > scripts. That feature was removed decades ago, and the above code > attempts to cater to people who were invoking 'configure' with the > old option. Ah, OK, thanks. The option must be old -- it's not even in Autoconf 2.10! Cheers, Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: man pages for config.guess and friends
I suggest to move the man pages for config.guess and config.sub from autoconf to the config CVS. May be a good idea, if Ben agrees. I think this can safely wait until after Autoconf 2.60, though, which we'd like to release ASAP. I was not even aware that man pages exist; naturally I would be happy to maintain them in the config CVS repository. Thanks, Ben
more humour for the FSF Autoconf page
A few years ago, a friend submitted a Debian bug report against Autoconf because it included `readable' in the permissions mask of the configure script. :-) See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=140837 Ben -- Ben Elliston b...@au.ibm.com Australia Development Lab, IBM
--quiet option not carried through to config.status
When building GCC, I often pass --quiet to the top-level configure script. However, I sometimes find the need to blow away the build tree and rebuild from scratch. When this happens, I use config.status -V to find out what options I passed when the build tree was first set up. eg: $ ./config.status -V config.status configured by /home/bje/source/gcc-trunk/configure, generated by GNU Autoconf 2.59, with options '--disable-bootstrap' '--enable-languages=c,c++' [...] If I configured this tree at the outset with --quiet, this will never be recorded in the config.status output and I must remember to append it when reconstructing the configure command line. This may well also apply to other configure options. A bug? Cheers, Ben -- Ben Elliston b...@au.ibm.com Australia Development Lab, IBM
Re: PATCH: remove config.{guess,sub} man pages
On Thu, Dec 10, 2015 at 06:32:26AM +0100, Pavel Raiskup wrote: > after this patch -- the manual pages are not installed with autoconf > anymore (I tried 'make install'). Is that expected? If yes, how > are the manual pages supposed to be installed? That's correct. The man pages belong with these scripts which have been separately maintained for 15 years. The manual pages can be installed through a package that contains the config.* scripts (eg. autotools-dev on Debian and Ubuntu systems). Cheers, Ben signature.asc Description: Digital signature
update HACKING file
Fairly obvious. Cheers, Ben --- HACKING | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/HACKING b/HACKING index 0005988..a894e1d 100644 --- a/HACKING +++ b/HACKING @@ -18,8 +18,8 @@ If a change fixes a test, mention the test in the ChangeLog entry. To this end, the Autotest-mode is handy. ** Bug reports -If somebody reports a new bug, mention his name in the ChangeLog entry -and in the test case you write. Put him into THANKS. +If somebody reports a new bug, mention their name in the ChangeLog +entry and in the test case you write. Put them into THANKS. The correct response to most actual bugs is to write a new test case which demonstrates the bug. Then fix the bug, re-run the test suite, -- 1.9.1
PATCH: remove config.{guess,sub} man pages
Remove config.{guess,sub} man pages. These are now kept in the master
source tree for config.{guess,sub}.
Thanks,
Ben
---
man/config.guess.x | 24
man/config.sub.x | 4
man/local.mk | 8 +---
3 files changed, 1 insertion(+), 35 deletions(-)
delete mode 100644 man/config.guess.x
delete mode 100644 man/config.sub.x
diff --git a/man/config.guess.x b/man/config.guess.x
deleted file mode 100644
index ce23430..000
--- a/man/config.guess.x
+++ /dev/null
@@ -1,24 +0,0 @@
---no-info
-
-[name]
-config.guess \- guess the build system triplet
-
-[Environment variables]
-config.guess might need to compile and run C code, hence it needs a
-compiler for the `build' machine: use the environment variable
-`CC_FOR_BUILD' to specify the compiler for the build machine. If
-`CC_FOR_BUILD' is not specified, `CC' will be used. Be sure to
-specify `CC_FOR_BUILD' is `CC' is a cross-compiler to the `host'
-machine.
-
- CC_FOR_BUILDa native C compiler, defaults to `cc'
- CC a native C compiler, the previous variable is preferred
-
-[description]
-The GNU build system distinguishes three types of machines, the
-`build' machine on which the compilers are run, the `host' machine
-on which the package being built will run, and, exclusively when you
-build a compiler, assembler etc., the `target' machine, for which the
-compiler being built will produce code.
-
-This script will guess the type of the `build' machine.
diff --git a/man/config.sub.x b/man/config.sub.x
deleted file mode 100644
index 294cfbe..000
--- a/man/config.sub.x
+++ /dev/null
@@ -1,4 +0,0 @@
---no-info
-
-[name]
-config.sub \- validate and canonicalize a configuration triplet
diff --git a/man/local.mk b/man/local.mk
index a9c247a..2767d14 100644
--- a/man/local.mk
+++ b/man/local.mk
@@ -25,9 +25,7 @@ dist_man_MANS = \
$(mansrcdir)/autoreconf.1 \
$(mansrcdir)/autoscan.1 \
$(mansrcdir)/autoupdate.1 \
- $(mansrcdir)/ifnames.1 \
- $(mansrcdir)/config.guess.1 \
- $(mansrcdir)/config.sub.1
+ $(mansrcdir)/ifnames.1
EXTRA_DIST += $(dist_man_MANS:.1=.x) man/common.x
MAINTAINERCLEANFILES += $(dist_man_MANS)
@@ -42,10 +40,6 @@ $(mansrcdir)/autoscan.1: $(common_dep)
$(binsrcdir)/autoscan.in
$(mansrcdir)/autoupdate.1: $(common_dep) $(binsrcdir)/autoupdate.in
$(mansrcdir)/ifnames.1:$(common_dep) $(binsrcdir)/ifnames.in
-# Independent from this package.
-$(mansrcdir)/config.guess.1: $(srcdir)/build-aux/config.guess
-$(mansrcdir)/config.sub.1: $(srcdir)/build-aux/config.sub
-
remove_time_stamp = 's/^\(\.TH[^"]*"[^"]*"[^"]*\)"[^"]*"/\1/'
MOSTLYCLEANFILES += $(srcdir)/man/*.t
--
1.9.1
signature.asc
Description: Digital signature
Re: PATCH: remove config.{guess,sub} man pages
Ping? https://lists.gnu.org/archive/html/autoconf-patches/2015-11/msg0.html Thanks, Ben signature.asc Description: Digital signature
