> "John" == John D Burger <[EMAIL PROTECTED]> writes:
John> Lars Hecking:
>> The names are fairly obvious, and there's a section in the autoconf
>> manual that explains them (Results of Tests->Caching Results->Cache
>> Variable Names).
John> Thomas Dickey:
>> Though the mechanism is (has b
| > I'd like to know what shell you used to document this. None of the
| > shells I tried (zsh, bash, ash) exhibit such a problem.
|
| It was originally discovered by people using some version of FreeBSD's
| /bin/sh. I was able to reproduce it using the version of ash in
| Debian unstable.
He
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> This is the 256th time this is brought up, but could someone
Peter> please do something about it.
Peter> Almost every software package in existence needs to install
Peter> some documentation that is not in info or man format (e
> "Thomas" == Thomas Bushnell <[EMAIL PROTECTED]> writes:
Thomas> Russ Allbery <[EMAIL PROTECTED]> writes:
>> Personally, I'm somewhat annoyed to see yet more paths going into
>> Autoconf that I'll then have to override to get the installation
>> paths that I want (namely a flat tree of bin,
> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:
Ian> Akim Demaille <[EMAIL PROTECTED]> writes:
>> :( It's bad that it only happens now. Back then, the idea was
>> indeed to update everybody, and to simplify all the interfaces.
>> It's a pity the clarification of the semantics does no
> "Stefan" == Stefan Seefeld <[EMAIL PROTECTED]> writes:
Stefan> Akim Demaille wrote:
Thomas> "internals" should be used in its correct sense: describing
Thomas> things that a user cannot see
>> Sorry, I'm doing free software, and therefore there are no
>> internals
>> according to your defi
| > > # AC_FUNC_ERROR_AT_LINE
| > > # -
| > > AC_DEFUN([AC_FUNC_ERROR_AT_LINE],
| > > [AC_LIBSOURCES([error.h, error.c])dnl
| > > AC_CACHE_CHECK([for error_at_line], ac_cv_lib_error_at_line,
| > > [AC_LINK_IFELSE([AC_LANG_PROGRAM([],[error_at_line (0, 0, "", 0, "");])],
| > >
On 7 Feb 2002, Akim Demaille wrote:
> AC_DEFUN([AC_FUNC_ERROR_AT_LINE],
> [AC_LIBSOURCES([error.h, error.c])dnl
> [AC_LINK_IFELSE([AC_LANG_PROGRAM([],[error_at_line (0, 0, "", 0, "");])],
> [AC_LIBOBJ(error)])])
> ])
>
> Anyway, I don't think novices will write such things, t
On 7 Feb 2002, Akim Demaille wrote:
> John> it's less surprising that they might change than that documented
> John> behavior might change. (Of course I don't mean that
> John> ac_cv_header_foobar_h is not mentioned in the Autoconf docs, I
> John> mean even the format of the cache variable that
On Thu, 2002-02-07 at 11:16, Akim Demaille wrote:
> People use a tool which is becoming much bigger than what envisioned
> at its inception. It was originally used only by a set of hackers who
> keep in touch with the author of that tool. They know each other,
> they participate to the developme
Am Don, 2002-02-07 um 13.37 schrieb Tobias Hunger:
> Stefan did complain about the lack of a way to tell private from public
> macros, not about you changing private macros. What should a user of
> autoconf do? Send a list of macros he wants to use to this list to
> figure out which of them are O
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
>> This has been a default in Autoconf for years. I have a few ideas
>> on how to remove this problem, while at the same time enable the
>> implementation of other features. But it requires severe surgery,
>> which is not possible at
Akim Demaille wrote:
> OK, I'll submit another scenario to you.
[...]
oh yes, I know that story. It happens again and again.
And I agree that at some point you need a rupture to rewrite
the tool on a more robust ground. I have no problems with the
fact that you did break backward compatibilit
Am Mon, 2002-02-04 um 22.58 schrieb Tom Tromey:
> > "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> Ralf> But I think, the actual cause for this issue is something different:
>
> Ralf> 3) AM_INIT_AUTOMAKE([no-define]) allows config-headers to be
> Ralf> exported, ie. to export and
Is there any place I can search to find if an app has been succesfully
built with autoconf+friends on a non-Unix platform?
I'm thinking of trying to build Tar 1.13 and see refences to DOS but have
no way of telling whether they are purely historical, (going back to the
last millenium :-) ) o
Can anyone explain what this code in autoupdate does? :-
my $macros = new Autom4te::XFile ("$autoconf"
. " --trace AU_DEFUN:'AU:\$f:\$1'"
. " --trace define:'AC:\$f:\$1'"
. " --melt /dev/null |");
It appears to be causing the error msg:-
no such f
John Poltorak writes:
>
> Can anyone explain what this code in autoupdate does? :-
>
>
> my $macros = new Autom4te::XFile ("$autoconf"
>. " --trace AU_DEFUN:'AU:\$f:\$1'"
>. " --trace define:'AC:\$f:\$1'"
>. " --melt /dev/null |");
This is just
| Can anyone explain what this code in autoupdate does? :-
|
|
| my $macros = new Autom4te::XFile ("$autoconf"
|. " --trace AU_DEFUN:'AU:\$f:\$1'"
|. " --trace define:'AC:\$f:\$1'"
|. " --melt /dev/null |");
|
|
| It appears to be causing the er
Akim Demaille <[EMAIL PROTECTED]> writes:
> But wrt prefix_program, if *you*, Ian, tell me this change is wrong
> (as opposed to good but implies more work elsewhere), then I'm revert
> that bit.
The tone of your message implies that there was some sort of
miscommunication, for which I apologize
On Thu, Feb 07, 2002 at 10:46:27AM +0100, Akim Demaille wrote:
>
> | > I'd like to know what shell you used to document this. None of the
> | > shells I tried (zsh, bash, ash) exhibit such a problem.
> |
> | It was originally discovered by people using some version of FreeBSD's
> | /bin/sh. I
John Poltorak wrote:
>
> Is there any place I can search to find if an app has been succesfully
> built with autoconf+friends on a non-Unix platform?
>
Yes,
www.mingw.org
www.cygwin.com
> I'm thinking of trying to build Tar 1.13 and see refences to DOS but have
> no way of telling whether the
On Thu, Feb 07, 2002 at 02:35:04PM +0100, Akim Demaille wrote:
> >> Anyway, there are so many scripts depending on these names, that
> >> whatever scheme will be chosen, we will keep them.
>
> Thomas> (such as AC_CHECK_LIB ;-)
>
> I must have lost the track here. Many people have asked for its
Es schrieb John Poltorak:
>
> Is there any place I can search to find if an app has been succesfully
> built with autoconf+friends on a non-Unix platform?
>
> I'm thinking of trying to build Tar 1.13 and see refences to DOS but have
> no way of telling whether they are purely historical, (going
On Thu, Feb 07, 2002 at 03:06:59PM -0500, Thomas Dickey wrote:
> On Thu, Feb 07, 2002 at 02:35:04PM +0100, Akim Demaille wrote:
> > >> Anyway, there are so many scripts depending on these names, that
> > >> whatever scheme will be chosen, we will keep them.
> >
> > Thomas> (such as AC_CHECK_LIB ;
On Thu, Feb 07, 2002 at 09:20:56PM +0100, Guido Draheim wrote:
> Es schrieb John Poltorak:
> >
> > Is there any place I can search to find if an app has been succesfully
> > built with autoconf+friends on a non-Unix platform?
> >
> > I'm thinking of trying to build Tar 1.13 and see refences to D
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 07 Feb 2002 11:30:33 +0100
>
> Err, first of all, if you are talking about novices, strip the cache
> part, and go down to
But we shouldn't strip the cache part. Caching should be the normal
case. It should be easy to do, not hard.
> [Simplif
I'm not experienced with enough platforms to tell why
line 5148 in libtool-1.4.2 configure doesn't call grep -e:
if { (eval echo configure:5149: \"$archive_cmds 2\>\&1 \| grep \" -lc \" \
>/dev/null 2\>\&1\") 1>&5; (eval $archive_cmds 2\>\&1 \| grep \" -lc \" \>/dev/n
ull 2\>\&1) 2>&5; }
27 matches
Mail list logo
