On Fri, 4 Mar 2005, Paul Eggert wrote:
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
Should dependency-name be a package or a desired feature, which the
suggested package(s) support?
A feature, obviously. But I don't see the need for dependency-name in
the first place. I think it won't wo
On Fri, 4 Mar 2005, John W. Eaton wrote:
On 4-Mar-2005, Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> wrote:
| > it from their package system) or you have to embed this knowledge in
| > autoconf, which seems bad and would only work for a few tools in
|
| So where does it go, then? People have sai
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
> Should dependency-name be a package or a desired feature, which the
> suggested package(s) support?
A feature, obviously. But I don't see the need for dependency-name in
the first place. I think it won't work in practice -- actual
dependen
On 4-Mar-2005, Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> wrote:
| > it from their package system) or you have to embed this knowledge in
| > autoconf, which seems bad and would only work for a few tools in
|
| So where does it go, then? People have said not to put it in a text
| file, becau
On Fri, 4 Mar 2005, John W. Eaton wrote:
On 4-Mar-2005, Stepan Kasal <[EMAIL PROTECTED]> wrote:
| My idea was to have AC_MSG_NEED with args
|(@var{dependency-name}, @var{dependency-text}, @ovar{priority})
| used like
|
I think I understand why you want these kinds of messages. There have
On 4-Mar-2005, Stepan Kasal <[EMAIL PROTECTED]> wrote:
| My idea was to have AC_MSG_NEED with args
|(@var{dependency-name}, @var{dependency-text}, @ovar{priority})
| used like
|
| AC_MSG_NEED([flex],
| [Get the latest version of lex from ftp://ftp.gnu.org/gnu/flex/.])
|
| Which would disp
On Fri, 4 Mar 2005, Stepan Kasal wrote:
Hi,
thanks. I'll make a few comments, but we should wait for Paul's
Well, you'd reduced it to something manageable, so thank you.
opinion, it's more important than mine.
On Fri, Mar 04, 2005 at 01:16:08PM +, Hugh Sasse Staff Elec Eng wrote:
+Display a m
Hi,
thanks. I'll make a few comments, but we should wait for Paul's
opinion, it's more important than mine.
On Fri, Mar 04, 2005 at 01:16:08PM +, Hugh Sasse Staff Elec Eng wrote:
> +Display a message when @code{AC_OUTPUT} is called.
The node describing AC_OUTPUT should be changed, too. We
On Fri, 4 Mar 2005, Stepan Kasal wrote:
Hello Hugh,
Thank you for your helpful comments. How is this, below?
Hugh
--- ./autoconf.texi-1.880.orig 2005-03-02 10:35:08.489794000 +
+++ ./autoconf.texi-1.880 2005-03-04 13:06:47.185023000 +
@@ -7645,8 +7645,15 @@
@section Printin
Hello Hugh,
On Thu, Mar 03, 2005 at 05:38:54PM +, Hugh Sasse Staff Elec Eng wrote:
> >>>"I suggest you to install package foo, which can be grabbed from foo.org,
> >>>in order to proceed with this build."
> >>
> >>Ouch. That's not how I interpreted your output. Perhaps we should
> >>rethink
On Thu, 3 Mar 2005, Stepan Kasal wrote:
Hello,
On Wed, Mar 02, 2005 at 10:25:00AM -0800, Paul Eggert wrote:
Stepan Kasal <[EMAIL PROTECTED]> writes:
I wanted to say:
"I suggest you to install package foo, which can be grabbed from foo.org,
in order to proceed with this build."
Ouch. That's not how
Hello,
On Wed, Mar 02, 2005 at 10:25:00AM -0800, Paul Eggert wrote:
> Stepan Kasal <[EMAIL PROTECTED]> writes:
> > I wanted to say:
> > "I suggest you to install package foo, which can be grabbed from foo.org,
> > in order to proceed with this build."
>
> Ouch. That's not how I interpreted your
Stepan Kasal <[EMAIL PROTECTED]> writes:
> I wanted to say:
> "I suggest you to install package foo, which can be grabbed from foo.org,
> in order to proceed with this build."
Ouch. That's not how I interpreted your output. Perhaps we should
rethink the output format.
> Please note that my pro
Dan Manthey <[EMAIL PROTECTED]> writes:
> Ergo, I propose AC_NONFATAL([STATUS=1]) has the effect of setting the
> shell variable `ac_exit_status' (or something else *shrug*)
That could be done by adding an argument to AC_MSG_ERROR, which would
operate similarly to the new argument just proposed f
Hi,
On Tue, Mar 01, 2005 at 02:16:53PM -0800, Paul Eggert wrote:
> Stepan Kasal <[EMAIL PROTECTED]> writes:
>
> > AC_MSG_NEED(PACKAGE, TEXT)
> > --
> > Prints a message and saves it for later usage.
>
> My main comment is that the suggestion should be generalized.
Ge
On Tue, 1 Mar 2005, Paul Eggert wrote:
> For example, we could add an optional argument for AC_MSG_NOTICE, that
> says the notice should be appended to the end of the output rather
> than put into the middle. Then the user could do something like this:
>
> AC_MSG_NOTICE([Suggestion for foo: grab
Stepan Kasal <[EMAIL PROTECTED]> writes:
> AC_MSG_NEED(PACKAGE, TEXT)
> --
> Prints a message and saves it for later usage.
My main comment is that the suggestion should be generalized.
Users should be able to append arbitrary messages, not just
suggestions for particu
On Tue, 1 Mar 2005, Stepan Kasal wrote:
Hi,
let me formulate a proposal. I try to be as specific as possible.
Thank you, this is a help (I'm somewhat overloaded at the moemnt).
AC_MSG_NEED(PACKAGE, TEXT)
--
Prints a message and saves it for later usage.
Example: AC_MSG
Hi,
let me formulate a proposal. I try to be as specific as possible.
AC_MSG_NEED(PACKAGE, TEXT)
--
Prints a message and saves it for later usage.
Example: AC_MSG_NEED(foo, [grab the latest foo from foo.org])
prints:
Suggestion:
foo grab the latest foo f
Hi,
a quick comment.
On Thu, Feb 24, 2005 at 02:58:14PM -0500, Dan Manthey wrote:
> Actually, we've already got AS_IF [...] but using that may conflict
> with part of the proposal for conditional macros; don't know yet.
I don't think we should expect any conflicts. We should encouradge
wide us
On Thu, 24 Feb 2005, Dan Manthey wrote:
On Thu, 24 Feb 2005, Paul Eggert wrote:
Dan Manthey <[EMAIL PROTECTED]> writes:
AS_PACKAGE_SUGGEST([flex 2.5.x],[http://gnu.org/whereever_flex_is.html])
OK, but what is the practical difference between that, and something
like this?
AC_MSG_FAILURE([you need
On Thu, 24 Feb 2005, Paul Eggert wrote:
> Dan Manthey <[EMAIL PROTECTED]> writes:
>
> > AS_PACKAGE_SUGGEST([flex 2.5.x],[http://gnu.org/whereever_flex_is.html])
>
> OK, but what is the practical difference between that, and something
> like this?
>
> AC_MSG_FAILURE([you need a suitable implemen
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
> Like what? Let's pick something really small, so at least it can be
> held in one's head.
Autoconf is really small, by Autoconf standards. It has a 181-line
configure.ac, and a 29-line auxiliary file (config/m4.m4). That
is partly why I s
Dan Manthey <[EMAIL PROTECTED]> writes:
> AS_PACKAGE_SUGGEST([flex 2.5.x],[http://gnu.org/whereever_flex_is.html])
OK, but what is the practical difference between that, and something
like this?
AC_MSG_FAILURE([you need a suitable implementation of "lex" to build
this package. We suggest the
On Thu, 24 Feb 2005, Dan Manthey wrote:
On Thu, 24 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
On Thu, 24 Feb 2005, Dan Manthey wrote:
AC_MSG_END([A lexer is needed for yacc.]
AS_PACKAGE_SUGGEST([flex 2.5.x],[http://gnu.org/whereever_flex_is.html])
AS_PACKAGE_SUGGEST([lex]))
[OT] I don't u
On Thu, 24 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
> On Thu, 24 Feb 2005, Dan Manthey wrote:
>
> > AC_MSG_END([A lexer is needed for yacc.]
> > AS_PACKAGE_SUGGEST([flex 2.5.x],[http://gnu.org/whereever_flex_is.html])
> > AS_PACKAGE_SUGGEST([lex]))
>
> [OT] I don't understand this ext
On Thu, 24 Feb 2005, Dan Manthey wrote:
I have a modest proprosal that may capture the desired features, and
[...]
We've been discussing in another thread on this list that Autoconf tests
are usually preformed unconditionally because of issues with calling
prerequisite macros conditionally
I have a modest proprosal that may capture the desired features, and
requires only quite minimal help from Autoconf (other than completion of
another proposal that stands quite well on its own merits).
We've been discussing in another thread on this list that Autoconf tests
are usually preformed u
On Thu, 24 Feb 2005, Paul Eggert wrote:
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
AC_NEEDS(AC_PROG_YACC, AC_PROG_LEX,
"A lexer, (lex or flex, perhaps) is needed for the Yacc functionality to work")
Sorry, I don't understand this example. First, as a technical matter,
one does not need
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
> AC_NEEDS(AC_PROG_YACC, AC_PROG_LEX,
> "A lexer, (lex or flex, perhaps) is needed for the Yacc functionality to
> work")
Sorry, I don't understand this example. First, as a technical matter,
one does not need Yacc functionality to use Lex.
On Wed, 23 Feb 2005, Paul Eggert wrote:
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
* some macro such as AC_NEEDS(Tthis, That) expresses the idea
that This feature is KNOWN to depend on the existence of That
feature.
This is a bit vague. Can you give some specific examples
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
>* some macro such as AC_NEEDS(Tthis, That) expresses the idea
> that This feature is KNOWN to depend on the existence of That
> feature.
This is a bit vague. Can you give some specific examples of
invocations of this macro? F
On Wed, 23 Feb 2005, Paul Eggert wrote:
Perhaps you can flesh it out a bit more by saying exactly what
should go into the DEPENDENCIES file for Autoconf itself, and
what "configure" should do in some common cases. To be honest,
I still don't really understand what you're proposing.
I'm sorry, I t
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
> But we have already agreed that we would be testing for features,
> not version numbers,
Then I'm afraid I still don't understand your proposal. Autoconf
already tests for features.
Perhaps you can flesh it out a bit more by saying exactly
On Tue, 22 Feb 2005, Jacob Meuser wrote:
On Wed, Feb 23, 2005 at 01:24:06AM +, Hugh Sasse Staff Elec Eng wrote:
too soon implemented. Autoconf cannot test for versions of
packages, because there is no standard way to present this even with
a --version option. But we can say that you need GNU
On Wed, 23 Feb 2005, Paul Eggert wrote:
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
I'm proposing that Autoconf tell me as much as possible when things
go wrong. "Possible" includes knowledge that the authors of a
configuration have.
But typically the information that the authors have is
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
> I'm proposing that Autoconf tell me as much as possible when things
> go wrong. "Possible" includes knowledge that the authors of a
> configuration have.
But typically the information that the authors have is quite limited,
compared to the
On Wed, Feb 23, 2005 at 01:24:06AM +, Hugh Sasse Staff Elec Eng wrote:
> No. I'm proposing that Autoconf tell me as much as possible when
> things go wrong. "Possible" includes knowledge that the authors of a
> configuration have. "As much" includes not dying prematurely,
> using dependency
On Tue, 22 Feb 2005, Paul Eggert wrote:
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
As to my providing patches for this: well, if I was familiar with
the internals, then it would be practical for me to do that.
Part of the problem here is that your proposal is almost diametrically
opposed
On Tue, 22 Feb 2005, Bob Friesenhahn wrote:
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
configure script simply record that the function is not available and
the app
record it to announce at the end and move on...
More often than not, if something important is missing, the configure scri
On Wed, 23 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
However, it is not a *known* (to the configure script developer)
dependency. The failure is due to an indirect dependency.
In which case we are no worse off than we are now, but where things
are known, we are better off.
Yes, indeed.
Your ideas
On Tue, 22 Feb 2005, Bob Friesenhahn wrote:
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
Yes, so library 5 is a dependency of library 14.
That's what I'm trying to express (in my later post).
However, it is not a *known* (to the configure script developer) dependency.
The failure is due t
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
If it is known to be provided by a package, suggest that package.
It should not quit: it should look for other things it needs.
Then list the info before exiting.
configure script simply record that the function is not available and the
app
rec
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
Alas, it is not that easy. If you have 16 possible libraries you need to
link against, it may be that library 5 provides what you were looking for
(and need), but library 14 needed something else from library 5 (maybe
optional symbols, or an
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
> As to my providing patches for this: well, if I was familiar with
> the internals, then it would be practical for me to do that.
Perhaps you could find someone who is willing to implement the
proposal? I'm afraid I lack the time. And it se
On Tue, 22 Feb 2005, Bob Friesenhahn wrote:
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
totally wrong though, since failure to detect a header or library could
actually be due to an earlier error in the configuration process
(config.log needs to be carefully inspected).
Tsort. If an e
On Tue, 22 Feb 2005, Bob Friesenhahn wrote:
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
I think that at present there is no structured dependency
information in the ac files from which configure and so on are
built. I would suggest that some directives for expressing
dependencies be adde
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
totally wrong though, since failure to detect a header or library could
actually be due to an earlier error in the configuration process
(config.log needs to be carefully inspected).
Tsort. If an earlier thing fails for a given branch of dep
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
I think that at present there is no structured dependency
information in the ac files from which configure and so on are
built. I would suggest that some directives for expressing
dependencies be added, so that tsort could be used to determine
On Tue, 22 Feb 2005, Paul Eggert wrote:
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
This message is a request to implement the suggestion that configure
produce a listing, when it finishes, of the packages needed to build
this package
That would be a nice thing to have, but I don't see ho
On Tue, 22 Feb 2005, Bob Friesenhahn wrote:
On Tue, 22 Feb 2005, Thomas Dickey wrote:
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
A few weeks ago I wrote to the Gnu coding standards people, with a
suggestion that there should be a DEPENDENCIES file, so that
It would be nice if autoconf di
Hugh Sasse Staff Elec Eng <[EMAIL PROTECTED]> writes:
> This message is a request to implement the suggestion that configure
> produce a listing, when it finishes, of the packages needed to build
> this package
That would be a nice thing to have, but I don't see how to implement
it easily. Perha
On Tue, 22 Feb 2005, Bob Friesenhahn wrote:
On Tue, 22 Feb 2005, Thomas Dickey wrote:
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
A few weeks ago I wrote to the Gnu coding standards people, with a
suggestion that there should be a DEPENDENCIES file, so that
It would be nice if autoconf di
On Tue, 22 Feb 2005, Thomas Dickey wrote:
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
A few weeks ago I wrote to the Gnu coding standards people, with a
suggestion that there should be a DEPENDENCIES file, so that
It would be nice if autoconf did that for itself. I don't recall a "recent
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
A few weeks ago I wrote to the Gnu coding standards people, with a
suggestion that there should be a DEPENDENCIES file, so that
It would be nice if autoconf did that for itself. I don't recall a
"recent" release which satisfied that goal (and
55 matches
Mail list logo
