Hi.
I'm new to this list, so I may be fuddled. Please flame me only for my own
benefit.
I'm using autoconf 2.59, so I copied the relevant parts of the new
AC_PROG_CC_C99 macro to my aclocal.m4 to use it. I used the version Roger
Leigh posted as a diff on December 2nd.
I noticed two issues:
I
slow-to-execute configure
script?
Find below a patch of _AC_OUTPUT_FILES.
-Dan Manthey
--- status.m4.old 2005-01-13 15:03:43.702862400 -0500
+++ status.m4 2005-01-13 16:53:33.338292800 -0500
@@ -852,6 +852,20 @@
m4_define([AC_LIST_FILES_COMMANDS])
+m4_define([_AC_CONFIG_STATUS_SED_CMD
On Mon, 17 Jan 2005, Stepan Kasal wrote:
> Hello,
>
> You decided to use 2), which is the most correct solution. Unfortunately,
> the performance penalty may be high. I'm afraid it's to high to be worth it.
Yeah, that's what I was afraid of.
>
> I think that if we choose a sufficiently unusu
Well, this took me longer to get to than I had hoped, but it came out
pretty well:
I've rewritten my solution from scratch in order to clean it up and
document it. Find the diff from 2.59b attached.
Some things are worth nothing:
I've made a new macro that is just the max number of sed commands
On Tue, 25 Jan 2005, Stepan Kasal wrote:
> > Rather than counting the delimiters to just _notice_ when an output
> > variable containing the delimiter would foul up the escaping mechanism, I
> > use it to instead modify the delimiter and redo the whole process. It's
> > now guaranteed to alway
Here's what I hope is a final solution to multiline output variables and
the related rework of _AC_OUTPUT_FILES.
I needed to change the delimeter to not contain @, since I now escape all
@ in output variable values as |[EMAIL PROTECTED]@#|. No, there's no really
good reason
that I chose this str
On Thu, 3 Feb 2005, Braden McDaniel wrote:
> Paul Eggert wrote:
> > Gregorio Guidi <[EMAIL PROTECTED]> writes:
> >>it is very important when creating a package to know in advance what
> >>features will be enabled in the software at the end of the process,
> >>without knowing the details of the ho
Hi, again. This took a while because I was working on other things. I
hope that this is the final patch for supporting multiline output
variables. (Though I bet that I've made some dumb typo.)
The attached patch is 'cvs diff'ed from anoncvs as of this afternoon.
On Fri, 28 Jan 2005, Stepan Kas
On Tue, 8 Feb 2005, Stepan Kasal wrote:
> Proof: Let's have an occurence of [EMAIL PROTECTED]@'. If its left `@' wasn't
> in the
> original input, then it has to be followed by |#_!!_#|, so it's not [EMAIL
> PROTECTED]',
> contradiction. So the left `@' had to be inthe original line.
> If som
Does anyone have any feelings on this? It's a simple macro to allow one
to write case patterns with both open and close parentheses, to make tools
like emacs play more nicely with your source code.
-Dan
Index: lib/m4sugar/m4sh.m4
===
Okay, hopefully this is the last version of this patch, finally.
On Wed, 9 Feb 2005, Stepan Kasal wrote:
> > > m4_define([_AC_SED_CMDS],m4_defn([_AC_SED_CMDS])[| sed 's/|#_!!_#|//g' ])
>
> Thank you for explaining me this.
>
> This line appears twice in the source, though.
> Can't the duplication
On Wed, 9 Feb 2005, Stepan Kasal wrote:
> On Tue, Feb 08, 2005 at 02:37:59PM -0500, Dan Manthey wrote:
> > +m4_define([AS_CASE_PATTERN],
> > +[m4_if($#,0,[[$0]],$#,1,[[$1 ) ]],[[$1 | ]$0(m4_shift($@))])])
>
> Wouldn't a simple
>
> m4_define([AS_CASE], [$1)])
On Wed, 9 Feb 2005, Stepan Kasal wrote:
> 1) Let's introduce a macro:
>
> AC_IF(TEST, THEN-CODE, [ELSE-CODE])
>
[...]
>
> The problem with this is that it would be probably next to impossible to
> teach people to use AC_IF instead of a normal `if'.
Of course, wouldn't the people who use
The Autoconf manual describes the macro AC_DEFAULT_INCLUDES, but at least
as of version 2.59, it's named AC_INCLUDES_DEFAULT.
-Dan
On Fri, 11 Feb 2005, Stepan Kasal wrote:
> Hi Paul.
>
> On Thu, Feb 10, 2005 at 09:25:07AM -0800, Paul Eggert wrote:
> > Why not implement this stuff using "make" rather than "sh"?
> > "make" is designed for dependency handling; the shell isn't.
> >
> > (If that's too drastic for you, I suppose
On Tue, 15 Feb 2005, Stepan Kasal wrote:
> On Mon, Feb 14, 2005 at 10:25:56AM -0800, Paul Eggert wrote:
> > Fair enough. But why not support parallelism while you're at it?
> > This can be done in the shell, albeit less elegantly than in 'make'.
I'm not impressed with the idea of parall
Ah, I do stand corrected on several accounts.
On Tue, 15 Feb 2005, Paul Eggert wrote:
> Dan Manthey <[EMAIL PROTECTED]> writes:
>
> > Broadly speaking, the act of configuration is that of setting variables to
> > describe the build environment.
>
> Autoconf often
On Wed, 16 Feb 2005, Stepan Kasal wrote:
> An idea:
> I don't believe it's worth the work to have configure to run the individual
> tests in parallel. If someone is able to invent a way to get several
> independent results from one run of compiler/preprocessor, that would
> help substantially.
On Fri, 18 Feb 2005, Stepan Kasal wrote:
> when I was thinking about the issue, I imagined several #include's in one
> file,
> to detect the presence of headers.
> We both come to the same conclusion: we can speed up the common case when all
> headers are present, but we cannot get several ind
On Wed, 9 Feb 2005, Dan Manthey wrote:
> Okay, hopefully this is the last version of this patch, finally.
Sadly, no, it wasn't.
I've finally gotten to try this patch on a different machine, and I
encountered two problems, now fixed.
On my Solaris 10 machine, I found that `expr
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 Sat, 12 Feb 2005, Stepan Kasal wrote:
>
> OK, back to reality: let's just suppose functions for this work.
>
So, do functions work portably?
It seems that it should be possible for each function foo to define a
shell variable $fn_foo, and that these could get set prior to the body of
configure
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]))
>
>
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
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
On Tue, 15 Mar 2005, Patrick West wrote:
> I am interested in doing something like this:
>
> ./configure --with-package=package1 --with-package=package2
>
> But I am not sure how to do this. I try to use AC_ARG_WITH, but that
> only takes package2 and ignores package1.
>
> Any help would be grea
On Tue, 15 Mar 2005, Dan Manthey wrote:
>
>
> On Tue, 15 Mar 2005, Patrick West wrote:
>
> > I am interested in doing something like this:
> >
> > ./configure --with-package=package1 --with-package=package2
> >
> > But I am not sure how to do this. I
> On Tue, 15 Mar 2005, Patrick West wrote:
>
> > I am interested in doing something like this:
> >
> > ./configure --with-package=package1 --with-package=package2
> >
> > But I am not sure how to do this. I try to use AC_ARG_WITH, but that
> > only takes package2 and ignores package1.
> >
> > An
On Tue, 15 Mar 2005, Braden McDaniel wrote:
> While you can use any value you want as the argument to a --with-*
> option, anything other than "yes" or "no" usually complicates the UI and
> should generally be avoided unless it is a clear simplification (IMO).
>
> So why not:
>
>./configure
On Tue, 15 Mar 2005, Braden McDaniel wrote:
> On Tue, 2005-03-15 at 16:25 -0500, Dan Manthey wrote:
> > You're confusing the semantics of --enable-* and --with-*.
>
> I'm not.
Okay. It just seemed that --enable-foo=a --enable-foo=b setting
$enable_foo to only 'b
I've got a header in which I want to replace both #undef FOO and @[EMAIL
PROTECTED]
At the moment, I do this by
AC_CONFIG_COMMANDS(foo.h,
[$as_myself --header=-:foo.h.in | $as_myself --file=foo.h:-])
This works tolerably, but has some irritating limitations.
The most obvious one is that I'm now
On Wed, 1 Jun 2005, Ralf Corsepius wrote:
> On Wed, 2005-06-01 at 18:33 +0200, Stepan Kasal wrote:
>
> > I think the best solution is to drop caching from programs.m4.
> Only over my dead body ;-)
>
> > Caching was invented mainly for expensive tests which involve
> > calling a compiler, which can
On Thu, 2 Jun 2005, Stepan Kasal wrote:
> it usestest "x$VAR" = x
>
> Thus the manual should use the term "is nonempty", not "is set".
>
> (One of the reasons for this behaviour is that unset is not portable.)
It's documented that the builtin `unset' is non-portable, but what about
the use o
On Thu, 2 Jun 2005, Paul Eggert wrote:
> Dan Manthey <[EMAIL PROTECTED]> writes:
>
> > For that matter, I know you can set bash to error out on $var for an
> > unset var
>
> Let's not do that, please. Let's stick to traditional behavior
> blessed b
One of the last steps that ./config.status does when making config.h is to
check whether the newly generated file differs from that being replaced,
and if it does not, the old one is not overwritten. This is done to
reduce unnessary rebuilding of source dependented on config.h. This I
understand.
On Tue, 25 Oct 2005, Stepan Kasal wrote:
> 3) There is an MSYS build of bash. Though MinGW/MSYS is not ready
> to run Autoconf, you can use it to unpack a tarball and run ./configure
> there.
> Is it possible that ./configure will then run in the 8.3 environment?
> I don't know and that is why I
36 matches
Mail list logo
