On Tue, 9 May 2000, Felix Lee wrote:
>
> perhaps it would be nice to set up a farm of assorted
> systems, available for general nonprofit freesoftware use,
> but I can't think of a reasonable way of doing it offhand.
> --
It would be very nice indeed, there is a small grouping of
Tru64 Linux and
On May 9, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Hmm. I'm pretty sure autoconf 2.13 set target to "NONE".
> Yes, it did, definitely. But it makes the code much simpler not to
> give a default value. Now, if you think t
On Tue, May 09, 2000 at 12:10:06PM +0200, Akim Demaille wrote:
> > "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
>
> Gary> Hmm. I'm pretty sure autoconf 2.13 set target to "NONE".
>
> Yes, it did, definitely. But it makes the code much simpler not to
> give a default value. Now, if
Phil Edwards <[EMAIL PROTECTED]> writes:
> Just for the record and to provide more kindling, the XPG4/POSIX sh in
> question is, in fact, the basic Korn shell (wrapped for viewing):
> % uname -sr
> SunOS 5.8
> % ls -lF /usr/xpg4/bin/sh
> lrwxrwxrwx 1 root root 13 A
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
-8<-
>
> > If we can deal with ":" - fine, if we cannot - no problem.
>
> It might be sensible for GNU Make to try and introduce quoting rules
> that would allow ':' to be used in filenames. However I would hope that
> wouldn't mean that the GNU Co
> "Greg" == Greg A Woods <[EMAIL PROTECTED]> writes:
>> If we can deal with ":" - fine, if we cannot - no problem.
Greg> It might be sensible for GNU Make to try and introduce quoting
Greg> rules that would allow ':' to be used in filenames. However I
Greg> would hope that wouldn't mean tha
[ On Tuesday, May 9, 2000 at 15:40:58 (-0400), Pavel Roskin wrote: ]
> Subject: Re: Possible bug involving ':' in directory names
>
> From GNU Coding Standards (by RMS):
>
> Utilities reading files should not drop NUL characters, or any other
> nonprinting characters @emph{including those with c
Donn Terry <[EMAIL PROTECTED]>:
> Sort of as a poll: on what systems is the getconf
> command not present, and which ones have it but not
of the systems I have easy access to, these are the oldest
that have it and the newest that don't.
aix 4.2 /bin/getconf
hpux 10.01
Hello, Greg!
> If anyone really and truly believes that it should be possible to
> include any character except perhaps '/' and '\0' in a filename then I
>From GNU Coding Standards (by RMS):
Utilities reading files should not drop NUL characters, or any other
nonprinting characters @emph{inclu
--- Felix Lee <[EMAIL PROTECTED]> wrote:
> Akim Demaille <[EMAIL PROTECTED]>:
> > PS/ I have a bizarre demand to make: does anybody know a means for me
> > to have an access to a wide set of old systems?
>
> how about, work for a company that supports them? cygnus
> has a couple of old systems l
> Date: Tue, 9 May 2000 10:18:19 -0400 (EDT)
> From: "Paul D. Smith" <[EMAIL PROTECTED]>
>
> BTW, while Eli Zaretskii is still providing excellent support for the
> DOS port of GNU make, it would be great if we had a few more pretesters
> for this port, as well.
I second this. (By "the DOS port
Donn Terry <[EMAIL PROTECTED]>:
> The current partial solution involves having two the-same-but-different
> versions of the same string, with different levels of \ quoting
> of ` (to allow nesting of `).
what do you gain from nesting `` that you can't do by using
temp variables? I can't think of
[ On Tuesday, May 9, 2000 at 09:11:02 (-0700), Tom Tromey wrote: ]
> Subject: Re: Possible bug involving ':' in directory names
>
> And once you get past the autoconf problems, you still have to contend
> with make. If a ":" ends up in your Makefile, you are doomed (more or
> less). This sucks,
On Tue, May 09, 2000 at 12:28:33PM +0200, Akim Demaille wrote:
>
> Your point is very valid. Could you come up with a specification of
> what you think should be the right behavior? autoheader could check
> that the set of the AC_CONFIG_HEADERS properly templates all the
> symbols which are use
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Gasps. Yes it would. Groumph. What is the need which requires
Akim> sinclude?
Some people apparently don't want to use aclocal.
So they sinclude some other macro file.
I argued against this, of course, but I don't always have th
Donn Terry wrote:
>
> Sort of as a poll: on what systems is the getconf
> command not present, and which ones have it but not
> in the default path? Since
> getconf CS_PATH
> is supposed to return the path to the POSIX conforming
That's the path all right. I think the exe name is needed...
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> You're right. Actually, I just discovered that autoconf
dv> doesn't print warnings anymore by default, which partly explains
dv> the surprises I recently got with some macros order
Akim Demaille <[EMAIL PROTECTED]>:
> PS/ I have a bizarre demand to make: does anybody know a means for me
> to have an access to a wide set of old systems?
how about, work for a company that supports them? cygnus
has a couple of old systems lying around. no 4.3bsd though.
perhaps it would be
Akim Demaille wrote:
> > "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
>
> dv> You're right. Actually, I just discovered that autoconf
> dv> doesn't print warnings anymore by default, which partly explains
> dv> the surprises I recently got with some macros ordering problems.
>
>
Sort of as a poll: on what systems is the getconf
command not present, and which ones have it but not
in the default path? Since
getconf CS_PATH
is supposed to return the path to the POSIX conforming
shell, if is pervasive enough in reality, then
that might be a way to deal with the "finding
t
I agree that finding it may be a bit of a challenge, but
it's probably worth it. (I'll see what I can do about
making that better in another life ;-) ).
The specific case I'm dealing with involves passing the
CC command down to lower levels of make, which in turn
involves doing command substitut
In message <[EMAIL PROTECTED]>you write:
> Thanks for the feedback. But I am still suspicious. There are way
> too many myths around Autoconf, and I'm willing to believe what I see.
> Have you really tried?
Yes. 4.3BSD and its immediate descendants were my primary development
platform
On May 9, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> You're right. Actually, I just discovered that autoconf
dv> doesn't print warnings anymore by default, which partly explains
dv> the surprises I recently got with some macros orde
On May 9, 2000, Michael Bletzinger <[EMAIL PROTECTED]> wrote:
> cvs says I do not have read write access
> for the file cvs/autoconf/CVSROOT/history
Are you still using the Sourceware CVS repo? Autoconf moved to GNU
subversions.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.
On May 9, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> I'm not surprised you found such problems: the colon is used in many
> places to separate various file names.
Moreover, it's a very important component of `make's syntax. So,
trying to fix it would be hopeless.
--
Alexandre Oliva
On Tue, May 09, 2000 at 06:26:55PM +0200, Didier Verna wrote:
: Akim Demaille wrote:
:
: > Hm...
: >
: > 2.13:
: > undefine([eval])
: > undefine([include])
: > undefine([shift])
: > undefine([format])
: >
: > CVS:
: > m4_rename([eval], [m4_eval])
: > m4_rename([shift], [m4_shift])
: > m4_ren
On May 8, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> what I said still stands
Yup
>> We'll have to review this code and remove all references to target,
>> and use host wherever we currently refer to target.
> Well volunteered ;')
Yup, it's in my to-do list.
--
Alexandre Oliva
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> This might be a stupid (because blind) question, but instead of
dv> renaming m4 macros as m4_*, wouldn't it be better to let m4 alone,
dv> and use a prefix for autoconf itself, like au_* ?
Nope, because it belongs to a sub part named `li
Opera Portables, Inc. is offering "by invitation" visits to our web site. Packed full
of exciting projects and news, Opera is leading the industry with displays that are as
much eye-popping as they are eye catching.
Winner of numerous industry awards, including Ernst & Young's Crescendo Award,
Akim Demaille wrote:
> Hm...
>
> 2.13:
> undefine([eval])
> undefine([include])
> undefine([shift])
> undefine([format])
>
> CVS:
> m4_rename([eval], [m4_eval])
> m4_rename([shift], [m4_shift])
> m4_rename([format], [m4_format])
> # Stuff about m4_s?include
> undefine([include])
> undefine([
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> You're right. Actually, I just discovered that autoconf
dv> doesn't print warnings anymore by default, which partly explains
dv> the surprises I recently got with some macros ordering problems.
I can reenable the `syntax' categor
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Well, you are right, it is new that they are being renamed,
Akim> before they were just removed :)
Tom> Is this going to break a configure.in that uses
Tom> sinclude(some-file)?
Akim Demaille wrote:
> Your point is valid, but I think you just revealed that
> AC_CONFIG_AUX_DIR should AC_BEFORE([AC_CONFIG_SUBDIRS]).
You're right. Actually, I just discovered that autoconf doesn't print
warnings anymore by default, which partly explains the surprises I recently
got
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> "Keith" == Keith Thompson <[EMAIL PROTECTED]> writes:
Keith> I recently discovered that the generated configure scripts have
Keith> problems when the software is installed in a directory whose
Keith> name contains ':' characters. (I
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Well, you are right, it is new that they are being renamed,
Akim> before they were just removed :)
Is this going to break a configure.in that uses sinclude(some-file)?
Believe it or not, there are configure.in's like that around her
Russ Allbery <[EMAIL PROTECTED]>:
> The POSIX-compliant Bourne shell on a Solaris system is located in
> /usr/xpg4/bin/sh and is part of an extra optional package. There is no
> extra charge for this package, but it is also not part of a minimal OS
> install and therefore some folks may not have
,
| AC_PREREQ(2.14a)
| AC_INIT(configure.in)
| AC_CONFIG_SUBDIRS(sub) dnl calls AC_CONFIG_AUX_DIR_DEFAULT
| AM_INIT_AUTOMAKE(test, 1)
| AC_CONFIG_AUX_DIR(aux) dnl Wrong: second call to AC_CONFIG_AUX_DIRS
| AC_OUTPUT(Makefile)
`-
Your point is valid, but I think you just reveal
Akim Demaille wrote:
> dv> something that I consider as a real bug in the current interface:
> dv> if the macro A requires the macro B, and the macro B is present in
> dv> configure.in after A, A should not just call B. It should abort at
> dv> autoconf time and nicely ask the package writer to s
Paul,
Thanks for your comments. I believe that
someone could devote more time than I have and do
a lot of good things to improve the WIN32 story for GNU make.
I have certainly enjoyed working on the tool. I hope
someone else will seize the challenge. I am glad to
facilitate the transition as wel
Hello Akim,
Akim Demaille wrote:
>
> Are you sure your patch changes something? I mean, the problem is
> probably with the confdefs.undef file, not confdefs.defines:
>
> confdefs.defines part:
>
> | # Break up conftest.defines because some shells have a limit on the size
> | # of here documen
Hi all.
Recently Rob Tulloh has notified me that he's no longer able to give the
maintenance of the Windows port of GNU make the attention he would like,
due to other demands on his time. I would like to publicly thank him
for his many years of dedication to and support of that effort, and I
hop
> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:
Akim> Why can't we expect sh5 being available?
Ian> Because sh5, as indicated by its name, is the System V shell. It
Ian> will not be found on a pure BSD system. Similarly, ksh, the Korn
Ian> shell, is a Bell Labs invention made well
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> IMHO, AC_REQUIRE and AC_BEFORE are broken by design.
Sorry, but I find your judgment a bit severe.
dv> Or at least, their behavior is far too basic (notably the calling
dv> of the required macro without any argument)to be satisfactory
Does anyone have a pure 4.3BSD system connected up to the net? If so
why not give the doubters a guest account so that they can see for
themselves.
Perhaps an ls -l and uname -a of such a machine would be equally
satisfactory?
Alex.
From: Akim Demaille <[EMAIL PROTECTED]>
Date: 09 May 2000 11:37:29 +0200
Jeffrey> You can't depend on ksh or sh5 being available on 4.3BSD
Jeffrey> boxes and the 4.3BSD shell certainly does not support shell
Jeffrey> functions.
Why can't we expect sh5 being available?
Because
Akim Demaille wrote:
> Greg> One of the things that I find frustrating in 'autoconf' is that
> Greg> dependencies between configuration tests are not explicit.
>
> Alexandre> Aren't AC_REQUIRE and AC_BEFORE supposed to fulfill these
> Alexandre> needs?
>
> Yep, same here.
IMHO, AC_REQU
Are you sure your patch changes something? I mean, the problem is
probably with the confdefs.undef file, not confdefs.defines:
confdefs.defines part:
| # Break up conftest.defines because some shells have a limit on the size
| # of here documents, and old seds have small limits too (100 cmds).
On Tue, May 09, 2000 at 12:42:40PM +0200, Akim Demaille wrote:
: > "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
:
: Akim> How can you imagine leaving with it?
:
: Gromph, sorrys/it/heat/ :)
"leaving wheath it"? Now I'm lost ;)
Lars J
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Greg> One of the things that I find frustrating in 'autoconf' is that
Greg> dependencies between configuration tests are not explicit.
Tom> FWIW: this is one of the things that Metaconf (the package used
Tom> to build Perl-style Co
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> How can you imagine leaving with it?
Gromph, sorrys/it/heat/ :)
Akim Demaille wrote:
> Well, we already have [...] AC_COPYRIGHT (shouldn't it be
> AC_LICENSE btw?),
Well, maybe both: you output a copyright notice with --version, but
you include a license at the top of configure. These should be different.
> I don't feel good to see those names being
> "Keith" == Keith Thompson <[EMAIL PROTECTED]> writes:
Keith> I recently discovered that the generated configure scripts have
Keith> problems when the software is installed in a directory whose
Keith> name contains ':' characters. (I was using a timestamp as part
Keith> of the directory nam
Your point is very valid. Could you come up with a specification of
what you think should be the right behavior? autoheader could check
that the set of the AC_CONFIG_HEADERS properly templates all the
symbols which are used.
Or a missing template could be a warning instead of an error. I don'
Akim Demaille wrote:
> dv> However, if I'm right about this, that should be clearly documented,
> dv> probably in the `writing macros' section.
>
> Well, you are right, it is new that they are being renamed, before
> they were just removed :)
Oh my God :-)
> currently the Autoconf docu
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> I worked around this issue by always using 3 arguments to
Mo> AC_DEFINE.
Nope, you just did the right thing :)
> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes:
Lars> There is no bug in autoheader.
Lars> autoheader itself is a bloody bug,
Wow :) What is it that is so wrong with autoheader? How can you
imagine leaving with it? I certainly don't want to write my
config.h.in by hand, and I do w
> "Michael" == Michael Bletzinger <[EMAIL PROTECTED]> writes:
Michael> When running a configure.in script that has no AC_DEFINE
Michael> calls the config.status script that is generated contains any
Michael> empty if/then/fi structure which bash croaks on. This patch
Michael> fixes the behav
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Hmm. I'm pretty sure autoconf 2.13 set target to "NONE".
Yes, it did, definitely. But it makes the code much simpler not to
give a default value. Now, if you think this is the beginning of
troubles, we might change it back :(
Well, we already have AC_PACKAGE, AC_COPYRIGHT (shouldn't it be
AC_LICENSE btw?), and now AC_COMMENT.
I don't feel good to see those names being used. Maybe we should use
a sub name space? Either a new one, or CONFIG: AC_CONFIG_PACKAGE,
AC_CONFIG_COMMENT?
Grmph. Maybe not.
> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:
dv> Hi!
dv> While writing a macro to be aclocal'ed, I discovered that
dv> the m4 macro `eval' is not expanded by autoconf. I guess that's a
dv> `feature', since snarfing in the code gave me the feeling that I'm
dv> su
Akim Demaille <[EMAIL PROTECTED]> writes:
>> "Jeffrey" == Jeffrey A Law <[EMAIL PROTECTED]> writes:
> Jeffrey> You can't depend on ksh or sh5 being available on 4.3BSD
> Jeffrey> boxes and the 4.3BSD shell certainly does not support shell
> Jeffrey> functions.
> Hi Jeff,
> Thanks for the fe
> "Jeffrey" == Jeffrey A Law <[EMAIL PROTECTED]> writes:
Jeffrey> You can't depend on ksh or sh5 being available on 4.3BSD
Jeffrey> boxes and the 4.3BSD shell certainly does not support shell
Jeffrey> functions.
Hi Jeff,
Thanks for the feedback. But I am still suspicious. There are way
to
Hi!
Sometimes, you'd like the ability to insert comments at the top of
`configure'. The following patch implements this with a new diversion and a
new macro, AC_COMMENT.
BTW, I noticed that AC_PACKAGE is not documented. Is it intentional ?
2000-05-05 Didier Verna <[EMAIL
Hi!
While writing a macro to be aclocal'ed, I discovered that the m4 macro
`eval' is not expanded by autoconf. I guess that's a `feature', since snarfing
in the code gave me the feeling that I'm supposed to use the macro `m4_eval'
instead. However, if I'm right about this
64 matches
Mail list logo
