I'd like to request the following changes in file names for some future
version of autoconf:
-) use acversion.in, not acversion.m4.in
reason: not all systems support multiple dots in filenames
A similar problem exists in the man directory (the config.guess and
config.sub man pages), but that
> > Lars> A better fix would be to have AC_PATH_PROG (or whichever macro
> > Lars> it is that searches for the compiler) to also consider implied
> > Lars> exe- extensions on systems that use them, and add the extension
> > Lars> to the returned program name.
> >
> > The real good fix will be to
> Not only gross, it wouldn't work on DOS anyway. DOS has a 8.3 filename
> limit. I think these kind of limitations will have to resort to cross
> building to the non-compliant systems. Leave it alone.
Actually, on DJGPP (and I think this is currently the only DOS environment
that is unixy enou
> In lisp/scheme, you name predicates e.g. "is-integer?" or just "integer?".
> The C convention is for Guile to use names like SCM_INTEGER_P(value)
> where _P means it is a predicate. I don't think _P is something we
> should use, and using "?" means changing the m4 word syntax, so it's
> probabl
I'd like to add (at some point) a macro that detects the path separator
used on the _build_ system. This is important for:
a) the path walking macros; they set IFS to ':' assuming this will
break up the PATH into its constituent directories.
b) MANY makefiles, which often use PATH=../src:$PA
> Should we (i) make sure not to use config.site in the test suite, or
> (ii) have this test grep out this message?
>
> It sounds good to have the test suite protected from the user, but
> OTOH, it sounds good to have a means to check configures using the end
> user's config.site.
I'd vote for (
> AC_CHECK_LIB(JTC, notifyAll)
>
> It responds that it cannot find it. Yet I look in the directory and its
> there. I run "grep notifyAll libJTC.so" and it says the binary has a
> match. I know that function exists in the library.
>
> So I am confused why its not working
Given that it's a C++ li
> In _AS_TEST_PREPARE, we might end up echoing errors from non-working
> test commands to the user which is confusing (at least to me).
Didn't consider the possibility of 'test' providing output - sorry.
> A more serious problem is in AS_MKDIR_P. It sets IFS to '\\/' and it
Force of habit; bash
> It would be shame if we release Autoconf with open bugs in the GNATS
> database.
>
> I tried yesterday to analyze or close what I felt I can. But I don't feel
> competent e.g. in the DOS and Fortran problems.
>
> So lets go to
> http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=autoconf
>
> It's not called TARGET. It's called HOST. TARGET is only meaningful for
> compilers and other tools working together to create executables _for_ a
> particular platform.
OK - my bad.
> I'd like to advise you that it would be fair not to support non-UNIX path
> separators on the build system. Au
> After a look through the sources it seems that
> AS_EXECUTABLE_P should use both "test -f" and
> "test -x" on systems that support it, and "test -f"
> otherwise (DOS, Win, ...)
Yes and no. The reason we try to use 'test -x' is so that
'test -x foo' will pick up foo.exe. I had not thought of
th
> > DOES pretend to do)? DJGPP can pretend to be unixy when it comes to pathseps,
> > but ONLY inside bash (granted, that's where it will matter most, but using ':'
> > because bash can handle it would break if used inside perl/m4/whatever).
> Since the test is run by bash and not by something els
> I can send you the offending configure.in if you like. It's the one
> that's checked into the CVS CVS (no, that wasn't a stutter. :). Of
> course, I might want to pull my customizations out of my AM first and try
> again to make sure that's not causing the problem first, but if someone
> else
> It seems to me that falling to `:' is way enough for this case.
I agree - as long as those systems where ';' is needed are able
to grok the test, that's fine. All other systems can happily use
':' as before (regardless of why they failed the test).
> Personally, at least for the time being, we don't care about HOST: as
> said by Pavel, only specific packages will need it, and they certainly
> need it so badly that they already perform their tests. And if they
> don't, the simple fact that Autoconf supports some HOST-path-sep test
> will not
First off, sorry for the delay in replying; I just set up a new PC and
there is still much migrating and configuring to do...
> But I never read explicitly your environment also has this problem.
> Has it, or has it not? Because we can
it has.
> Unix:
> test -x && test -f
>
> DOS says no to te
> Does AUTOCONF provide support for DOS pathnames? ie drive letters,
> '\' in directories and ';' as separators in paths?
It's starting to. The current CVS autoconf has had several patches
applied for better DOS support. It's not quite perfect yet, but a
ges my local autoreconf currently has are
listed below; I don't think they're critical, but they
might as well go in.
2001-02-11 Tim Van Holder <[EMAIL PROTECTED]>
* autoreconf.sh: Improve support for DOS paths.
Index: autoreconf.sh
=
>> >* remake-hdr.am (@STAMP@): Use .T as suffix for the
>> >temporary file.
>>
>> You should probably patch autoconf's autoreconf too.
>
> > What part would need patching?
>
> The one that choose stamp file names like those created by automake.
Right - I hadn't noticed this:
stamp
> Does it work at all?
> I just downloaded the most recent version and ran configure, and among
> other things it said:-
[snip]
[Sorry - fingerslip caused a send]
> Does it work at all?
> I just downloaded the most recent version and ran configure, and among
> other things it said:-
>
> [snip]
That's because 2.49c didn't have the pathsep deduction yet.
The current CVS autoconf should find those apps.
> I stumbled on to this because I had an perl directory.
> I know you probably have worked out your own fix and this probably
> won't fit with your plans, but c'est la vie.
Actually, the problem is that your patch isn't really a fix.
The reason the use of -x was introduced, was that that test allo
> I am wondering if the new preferred way of an empty AC_OUTPUT
> and use of AC_CONFIG_FILES in autoconf-2.49c is presently
> known to automake-1.4d or does automake still require the
> old way of doing AC_OUTPUT. Thanks.
CVS automake, and 1.4d too I believe, should support both the
old and the n
> On DJGPP, can't you find some other tool that would help? For
> instance, is perl necessarily installed? Can we use it?
No, it's not. And the DJGPP maintainers get very upset if you
try forcing users to have too many non-trivial packages
installed (and perl is certainly non-trivial).
I can't t
> Also, should it search the PATH when:-
>
> checking for a BSD compatible install... ?
> Install.exe is on the path, but configure selects ./install-sh -c
> instead.
Yes it should - but the current CVS autoconf does not do this for
AC_PROG_INSTALL. And even if it does, it always seems to selec
> First of all, it is not obvious at all that config.status should run
> this, since Tim still did not convince me that AS_LN_S was a good
> thing. As is, AS_LN_S is just *useless*. We were happier before.
Hmm:
CONFIG_LINKS code BEFORE:
ln -s foo bar || ln foo bar
fine, but breaks DJGPP, whe
You _might_ be running into a pathsep bug.
acgeneral.m4 runs
PATH=".;`pwd`"; conftest.sh
to check whether ';' works as pathsep. But because of the ';' after
the PATH assignment, conftest gets the regular path. So if your
regular PATH contains the current dir, autoconf will assume ';' i
> Niah? I don't understand. Are you telling us that your host does not
> honor PATH assignments?
Hmm - right - I think I was seeing this wrong...
> This is not good, as we don't mean to pass the new PATH to conftest,
> rather we want to have the shell change its own PATH, and *then* to
> look f
I'm still looking into fixing the sub-configure stuff.
If --srcdir or --cache-file contain shell metachars (as
they would on DOS systems, for example, as they use a
backslash as dirsep), they get quoted at the start of
configure (after option parsing is completed).
Because of this, the case statem
> aclocal: configure.in: 76: macro `AM_GNU_GETTEXT' not found in library.
>
> Is this define somewhere? I downloaded and install the CVS version of
> automake 1.4e. The macro is called from configure.in file.
This is normally in a file called gettext.m4. There is probably an 'm4'
directory in the
> Its located in /usr/share/aclocal/gettext.m4
>
> So when I do "aclocal -I /usr/share/aclocal" its passes. Is that the way
> it should be?
Nope. Did you use '--prefix /usr' when configuring automake? If not, it
is probably looking in /usr/local/share/aclocal.
Use a text editor to look in aclocal
> Must be an oddity with my install then.
>
> Rob
First off, please try to use reply below quoted text to preserve
normal conversation flow. I use Outlook too, so I know that doesn't
make it easy, but still...
In any case, it looks like automake is the culprit; the output you
posted clearly show
> | Jim> Not everyone has a /dev/null.
> |
> | Huh??? What for instance?
>
> Er... Well, I guess you've caught me :-)
> I can't name one offhand. And even if I could, it probably
> wouldn't be worth making a change.
DJGPP doesn't (didn't) have one; its bash does support it, so the
current redi
>
> > John> I am using OS/2 which uses DOS paths and seperators, and drive
> > John> letters. Should I expect the path to be searched for sundry
> > John> support files?
> >
> > Support for DOS and OS/2 is not yet complete.
>
> Couldn't any support for OS/2 fall in line with Win32 support?
> T
> This is confusing...
>
> According to my test --help...
>
> -f FILE FILE exists and is a regular file
>
> I don't see why '-f' should search for an executable...
DJGPP's bash can have test -f find an executable simply because many Unixy
scripts (including autoconf's configure) use -f t
> I've tried it under PDKSH, BASH and CMD.EXE. The results are the same
> under each.
>
> > Does `:' work properly on your shell?
>
> When running:-
>
> sh -c :
>
> there is no response, which I guess is what you would expect.
>
If you mean you tried:
$ cmd
c:\> make
and
$ pdksh
$ make
th
On 26 Mar 2001 15:24:16 -0700, Jeremy Slade wrote:
> .made_mode = MyMod.C Makefile.perl
> $(MAKE) -fMakefile.perl
> touch $@
Minor portability issue: try to avoid names starting with leading dots.
If your code is supposed to never run on DOS, this doesn't matter that
much though.
> I also don't see a reason why it would be very useful to maintain
> a version on a configure script separate from the pacage version.
Figure I might as well chuck in my EUR 0.02 as well: what about
GNU configure (PACKAGE VERSION) AC_VERSION
After all, the relevant version number for configur
> I must admit that this contains all the relevant information, but
> I think it violates the coding standard. The text following the last
> space and up until the EOL is supposed to be a version string for the
> _program being run_. I would hazard to say that two versions of a
> package could h
> Almost all of the spam I get these days comes directly from gnu.org.
Same here.
> > Can advertisers
> > and bulk spammers be removed?
>
> Officially, no.
>
> After sending similar complaints months ago (Jan 23, 2001) to the FSF I
> just finally tonight got an "official" reply from the vice pr
> The only *fair* thing to do is to block all e-mail from all known and
> proven open relays and spam sources. *IFF* this ever causes any
> legitimate messages to be blocked then the only effect will be positive
> in that the user who gets the bounce will learn that his site is well
> known as a
> $ ./config.status --version
> GNU Autoconf config.status 2.49e
> generated automatically by GNU Autoconf configure 2.49e
> which was generated by GNU Autoconf 2.49e
> and invoked on nfs.trh.sim.no with the command line
> $ ../autoconf/configure
Having the verbose name of configure
> On Tue, Apr 10, 2001 at 11:39:19AM +0200, Akim Demaille wrote:
> : How about AC_CONFIG_CONFIG_DIR?
>
> AC_CONFIG_SCRIPT_DIR, AC_CONFIG_EXTRA_DIR, AC_CONFIG_STUFF_DIR,
> AC_CONFIG_LIB_DIR, AC_CONFIG_CONF_DIR... "CONFIG_CONFIG" seems a bit
> strange.
>
And the original point was also o be consi
> Anyways, I've tried a slightly changed format:
>
> $ ./config.status --version
> GNU Autoconf config.status 2.49e
> configured by ../autoconf/configure, generated by GNU Autoconf 2.49e,
> for host "nfs.trh.sim.no", with options ""
>
> Copyright 1992, 1993, 1994, 1995, 1996, 1998,
I'd like to add a djgpp subdirectory containing 2 files: a
README for the DJGPP port, and a config.site for use on
systems running DJGPP. Other files may be added later.
Is it allowed to add these to the official tree, so they end
up in the release tarballs, or should these only be part of
the DJ
> On Mon, Apr 16, 2001 at 05:03:43PM +0200, Tim Van Holder wrote:
> : I'd like to add a djgpp subdirectory containing 2 files: a
> : README for the DJGPP port, and a config.site for use on
> : systems running DJGPP.
>
> What do you describe in the README that is specifi
> : Any reason why these shouldn't be part of the autoconf manual? It
> : feels like this is the right place for this kind of information?
>
> I have that feeling too.
Generally, I'd agree.
However,
a) Most, if not all, DJGPP packages come with a DJGPP-specific readme
that identifies the p
I'm preparing a .dsm file for the DJGPP package of
autoconf 2.50. (A .dsm is somewhat like a .spec file).
What I'd like to know is who to list as author(s), and
who as maintainer(s), as the AUTHORS file and the GNU
software directory differ slightly (and there's so many
names :) ).
> I have a list of 'test' directories containing Makefiles. I want to
> omit two of those tests if GNU Bison is not found, because they
> depend on GNU bison. How do I do this?
>
> AC_CHECK_PROG(BISON,bison,bison)
>
> dnl Below, I want the last two directories to be omitted.
> dnl I could
> How does Autoconf handle directory seperators on a DOS file system?
>
> I was under the impression that configure would convert a PATH such as:-
>
> c:\usr\bin;c:\usr\local\bin;
>
> to:
>
> c:/usr/bin;c:/usr/local/bin;
>
> when searching the path for certain executables.
>
> Am I mista
> You found it. Configure.in is loaded with changequote() calls.
>
>
> > That feature is broken in the current alpha versions of autoconf,
> > has been reported a few times (and shows up with this symptom).
>
>
> Something broken? Is it to be fixed before 2.50?
>
OK - tried removing all changequ
> you have to code-around it rather than simply remove them
> (can escape '[' by '[[', for instance).
Hmm - allow me to exclaim 'Duh!'. I guess I should've been
more precise:
"I removed all changequote's, replaced the replacement quotes
by [/] and doubled existing [/]'s where appropriate. This
> Again, I think it is just miscommunication. I really understood
> `changequote is broken' (which is likely since we do redefine it),
> while it should read `people were used to change arbitrarily the
> quotes, i.e., change deeply the environment and were expecting the
> macros invoked in betwee
> (NOTE: This is with a fresh aclocal.m4 but
> a configure.in stripped of changequotes; there may be similar
> showstoppers in the stock configure.in).
Actually, just checked and the macro I posted is the only one causing
problems for the current autoconf in gcc.
> > Tim> And as for the autoheader problem: is it supposed to fail
> > Tim> silently (as it does for me),
> >
> > No, it should not.
> OK - I'll look into possible problems (I expect there'll be some issue
> with FDs/redirection again). For further evidence, is autoheader
> supposed to clean up a
> | [changequote(<<,>>)dnl
> | ac_prog_version=`<<$>>$1 $3 2>&1 |
> |sed -n 's/^.*patsubst(<<$4>>,/,\/).*$/\1/p'`
> | echo "configure:__oline__: version of $2 is $ac_prog_version"
> >&AC_FD_CC
> | case $ac_prog_version in
> | '') gcc_cv_prog_$2_modern=no;;
> |
> I poked around in the source code a bit more
> and found that AC_CYGWIN does a AC_REQUIRE([AC_CANONICAL_HOST])
> and is getting called from my configure.in.
>
> Sure enough, that seemed to be the problem.
> I made the following modification and my
> script started working again.
As AC_CYGWIN sa
Sorry for the delay in replying; my home PC suffered a minor heat
stroke and will be out of action for a while :-)
On 12 May 2001 15:36:53 +0200, Akim Demaille wrote:
> >>>>> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
>
> Tim> The only call is
On 12 May 2001 15:47:10 +0200, Akim Demaille wrote:
>
> On a second thought, the right way to handle this depends upon the
> nature of $1: is it always a literal, or can it be a shell variable?
> If it's always a literal, then your first approach but using
> translit([HAVE_DECL_$1], [a-z], [A-Z])
On 16 May 2001 00:22:43 +0200, Ralf Corsepius wrote:
> Until now this package's configure.in has been using AC_EXEEXT alone
> (w/o AC_PROG_CC), now I seem to need adding AC_PROG_CC, but ..
> .. Adding AC_CANONICAL_HOST would give sense, but this also
> apparently isn't sufficient.
This does seem
> > > Until now this package's configure.in has been using AC_EXEEXT alone
> > > (w/o AC_PROG_CC), now I seem to need adding AC_PROG_CC, but ..
> > > .. Adding AC_CANONICAL_HOST would give sense, but this also
> > > apparently isn't sufficient.
> >
> > This does seem like the right thing to do th
> | Nice patch, but I don't think it works. I'd be surprised if you
> | actually have the #undef templates in config.h.in since you pass an sh
> | var, which is opaque to autoheader. You need `static' values for
> | autoheader. That's why they had the last chunk.
> |
> | Use
> |
> | -if test x
Judging by the interesting appearance and disappearance of files in
the repository, I assume someone (presumably Akim) is in the process of
renaming autoconf.sh and friends to .in, I'd like to take this
opportunity to (re-)request that acversion.m4.in be renamed to
acversion.in (multiple dots are
On 23 May 2001 09:23:49 -0400, Derek R. Price wrote:
> Russ Allbery wrote:
>
> > Derek R Price <[EMAIL PROTECTED]> writes:
> >
> > > By the way, I think I see what you're getting at here, but you really
> > > spoil all of the automatic syntax coloration of my text editor since it
> > > switches f
> +/* On AmigaOS, fork() isn't implemented due to missing MP. */
> +int main ()
> +{
> + if (fork() < 0)
> +exit (1);
> + exit (0);
> +}],
> +[ac_cv_func_fork_works=yes],
> +[ac_cv_func_fork_works=no],
> +[AC_CHECK_FUNC(fork)
> +AC_COMPILE_IFELSE([AC_LANG_
First off, please don't post in HTML. It's rude.
> bash-2.04# autoconf
> bash-2.04# configure
> creating cache ./config.cache
> configure: error: can not run ./config.sub
You're probably using AC_CANONICAL_HOST or a related macro.
These require the config.guess and config.sub scripts to guess
t
On 29 May 2001 23:20:26 +0200, Teun Burgers wrote:
> Hi
>
> I am maintaining the configure script for
> gnugo (http://www.fsf.org/software/gnugo/)
>
> Under autoconf 2.13 when you had AC_EXEEXT
> in you configure.in you could do under cygwin
> a mingw32 build as follows:
>
> env CC='gcc -mno-cy
> bash-2.04# CC=arm-linux-gcc
> ./configure --target=arm-linux --host=i686-pc-linux-gnu
>
> checking for c++... c++
>
> (No, no, no I don't want to test c++, I want to test arm-linux-gcc ! )
>
If you are looking for a C compiler, you use AC_PROG_CC, and
optionally override CC; if you want a C++
On 31 May 2001 15:15:49 +0200, Rüdiger Kuhlmann wrote:
>
> > | + if (fork() < 0)
> > | +exit (1);
>
> > No way to actually *test* the feature?
>
> There _is_ a test. Look carefully. If fork() "always" fails,
> it is a stub. If the fork() succeeds, it is not.
Akim was talki
> Tim> Yes, but some platforms (like DJGPP) are not yet 100% supported
> Tim> directly - we need config.site to make path seraching work.
>
> :(
>
> I don't remember what remains to be done for DJGPP.
Not a lot really. There's probably a few places (AS_DIRNAME comes to
mind) where support for
> > | % autoconf2.50
> > | configure.in:55: error: undefine: undefined: zsh-debug
> > | configure.in:55: the top level
> > |
> > | The offending construct is here.
> > |
> > | undefine([zsh-debug])dnl
> > | AC_ARG_ENABLE(zsh-debug,
> > | [ --enable-zsh-debug compile with debug code and
>
> 2. is it safe to use both an FD to confdefs.h and redirections to
> confdefs.h?
As Lars said, my experiences with config.log suggest that this is
not the case on DOS. I suppose I could raise the issue with the
maintainers of DJGPP's libc and bash to see if this can be resolved
in future version
> Index: .prev-version
Minor nit, but could this be a more dos-friendly name (no leading dot
supported)?
> +# Systems where /bin/sh is not the default shell need this. The $(shell)
> +# command below won't work with e.g. stock DOS/Windows shells.
> +SHELL = /bin/sh
This sounds a bit like the $(
> Alexandre> IMO, the best way to go is for autoconf to come up with a
> Alexandre> safe echo, i.e., one that won't mess up any characters,
> Alexandre> will preserve backslashes, etc, in a similar way that
> Alexandre> libtool does. In fact, this would help libtool a lot as we
> Alexandre> move
> Actually, the original definition of 'vfork' said that one should not
> rely on this behavior. And in the latest POSIX draft (POSIX
> 1003.1-200x draft 5) the rationale states simply "On some
> implementations, vfork() is equivalent to fork()."
Actually, the latest draft is nr 6 (April 2001).
posting to a public forum.
--
Tim Van Holder - Anubex N.V.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was posted using plain text. I do not endorse any
products or services that may be hyperlinked to this message.
On 17 Jun 2001 19:11:05 -0300, Alexandre Oliva wrote:
> On Jun 9, 2001, "Tim Van Holder" <[EMAIL PROTECTED]> wrote:
>
> I'm afraid not even -E is a complete solution. Try, for example:
>
> echo -E -e '\a'
>
> and note that `-e' isn
> I know the above doesn't work, but could it be done in some other,
> hopefully portable, way? Wouldn't it speed up configure by a lot if
> we could apply it to the right sub-tasks?
>
> I was even thinking the "resident" sub-process could be a shell that
> looped over a read+switch/case express
> Thanks Tim, please install!
Will attempt to do so now :-)
When updating, I now get:
cvs server: cannot open /root/.cvsignore: Permission denied
and after a commit:
[cvs server aborted] Cannot chdir(/root).
This seems to be the 'no -f option passed to cvs server in inetd'
problem (probably one of the most-reported CVS problems).
> configure --omfdirs=/opt/share/omf:/usr/share/omf
>
> I couldn't figure out from the docs how to do it. The AC_ARG_ENABLE
> macro looked the closest, but I don't think it is the right one. Or do I
> have to write a macro for this?
Indeed, ARG_ENABLE is not the right one for this type of option
> Sorry Tim, I don't have time to evaluate your proposal now :( I'm
> sympathetic to your problems, but DOS will never be big enough in
> Autoconf's mission to justify additional delays.
I'm okay with that - I'll simply release a DJGPP package that has those
changes applied. I was pressing it mo
> I've been trying to compile one of my programs on a new Linux
> installation (Czech RedHat 7.1), but configure failed:
> ...
> checking whether c++ accepts -g... yes
> checking for ranlib... ranlib
> checking host system type... configure: error: can not guess host type;
> you must specify one
>
> 2.is this the case of cross-compilation?
> means does it require cross-compiler like xpp-elf-gcc(not implemented
> yet)to build the tool( GNU make) for specified target.
You can't compile things with a compiler that doesn't exist...
So either you need to build GNU make using your target's nat
to.
AC_HELP_STRING is actually quite nice, IMHO (and will cause user options
to fit in nicely even if a new version of autoconf changes the --help
layout).
--
Tim Van Holder - Anubex N.V.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was posted using plain text. I do not endorse any
products or services that may be hyperlinked to this message.
> > correctly) and then find out which process is trying to unlink /bin
> > and friends.
My (extremely uneducated) guess would be that it might be the
$tmp cleanup - maybe we're not robust to /tmp being a symlink?
What does the /tmp symlink point to?
> Nowadays, many shared libraries include a -config script e.g. libgtk
> has a gtk-config script, and a companion m4 macro AM_PATH_GTK. The
> header also has version information embedded in it, as does the
> library itself:
>
> #define _MAJOR_VERSION (@_MAJOR_VERSION@)
> #define _MINOR_VER
> The actual advantage of your macro comes of course with config.status
> updates - I hope that I can at one day turn my macro into a form that
> adds its -config file output-generation into config.status. IIRC the
> new autoconf does support some helper routines for exactly that purpose.
> But it
> > . file
> > DESCRIPTION
> > The shell will execute commands from the file in the current
> environment.
> > If file does not contain a slash, the shell will use the search path
> > specified by to find the directory containing file. Unlike
> normal command
Note that the critical piece of in
> Why was `gpp' chosen as a possible executable name for a C++ compiler
> in AC_PROG_CXX (Autoconf 2.52)? This clashes with:
> http://www.math.polytechnique.fr/cmat/auroux/prog/gpp.html
Because gpp is the name for g++ on DOS (where '+' is illegal in filenames).
This used to be gxx; I'm not sure
> I'm the creator of Python.
Like anyone here wouldn't recognize your name. You're quite famous in
certain circles, you know.
> I'm new to this list. We use autoconf (happily, I might add) and I've
> run into a snag. Please look at this Python bug report on SourceForge:
>
> http://sf.net/tra
I should have noticed this earlier, but it's been a while
since I last updated the CVS tree.
I just updated it and ran into an annoying problem: there is both a
lib/Autoconf and a lib/autoconf directory. This is not possible on
case-insensitive filesystems (like DOS and Win32), so CVS tries to
lum
> In fact, I realized that latter on, and changed that, but I suppose
> the mere presence of Autoconf (now renamed Autom4te) on the CVS repo
Actually, no you didn't - the problem is that it still has files in it
(otherwise cvs update -dP would have pruned it).
$ cd lib
$ cvs update -d Autoconf
c
> | > In fact, I realized that latter on, and changed that, but I suppose
> | > the mere presence of Autoconf (now renamed Autom4te) on the CVS repo
> |
> | Actually, no you didn't - the problem is that it still has files in it
> | (otherwise cvs update -dP would have pruned it).
>
> :-)=)
>
> Ahe
> For some reason, the generated tests/testsuite contains
> times >at-times
> all over the place. What is "times"? I can't find it, and it isn't a
> /bin/sh builtin..
I think it's a bash builtin which reports the elapsed time
of all processes in the current shell. I'm not sure if other
shell
> Autoconf complains:
> ./aclocal.m4:2508: error: m4_defn: undefined macro: _m4_divert_diversion
> acfunctions.m4:1108: AM_FUNC_OBSTACK is expanded from...
> ./aclocal.m4:2508: the top level
>
> in aclocal.m4
> AC_DEFUN(AM_FUNC_OBSTACK,
This should be "AC_DEFUN([AM_FUNC_OBSTACK]," - autoconf it
> at_times=:
> times >dev/null 2>&1 && at_times=times
> $at_times >at-times
> echo $?
> times: not found
> 0
This suggests that this works, but that the shell somehow
doesn't let its 'not found' message be redirected :-(
How about
at_times=:
(times) >dev/null 2>&1 && at_times=times
echo at_t
> I like the former more.
So do I. I merely provided the second in case the first
doesn't work.
> Would you install it please? lib/autotest/general.m4. TIA.
Once I see actual confirmation from Patrick that either
solution actually works, I'd be glad to do so.
I've also got some rewordings (de
> BTW, what ``sort'' of Belgian are you? Wallon, Flamand? I'm from
I'm Flemish, I'm afraid. Why else would I want to de-francophonise
things? ;-P
> Lille, and sometimes go and see my parents up there. We might be able
> to meet some day. Hm... Will you go to `la braderie de Lille'?
I might
> quartz% sh foo.sh
> at_times=:
> 0
Excellent - will install this ASAP.
> (et etant francais aussi, nous retrouvons un petit monde
> francophone chez autoconf)
Oh no! They're everywhere! :-)
1 - 100 of 152 matches
Mail list logo
