On Thu, Oct 30, 2008 at 3:47 AM, Paolo Bonzini [EMAIL PROTECTED] wrote:
Nothing prevents a configure script (written in sh) from using scraps of
Perl. Hopefully the script would check that Perl exists before actually
using it.
But is there a clean way without having to watch the m4 special
On Wed, Oct 29, 2008 at 8:25 AM, Bob Friesenhahn
[EMAIL PROTECTED] wrote:
On Wed, 29 Oct 2008, Tom Browder wrote:
...
Nothing prevents a configure script (written in sh) from using scraps of
Perl. Hopefully the script would check that Perl exists before actually
using it.
But is there a
Nothing prevents a configure script (written in sh) from using scraps of
Perl. Hopefully the script would check that Perl exists before actually
using it.
But is there a clean way without having to watch the m4 special
characters, etc., i.e., some kind of escape so we can change to Perl,
On Mon, Oct 27, 2008 at 9:51 PM, Eric Blake [EMAIL PROTECTED] wrote:
According to Tom Browder on 10/26/2008 5:38 PM:
Any chance of getting (autoconf configure.ac configure) to be able
to use a Perl script if a macro finds suitable evidence of a modern
Perl capability?
Autoconf already uses
On Mon, Oct 27, 2008 at 10:41 PM, Bob Friesenhahn
[EMAIL PROTECTED] wrote:
On Mon, 27 Oct 2008, Eric Blake wrote:
Autoconf already uses perl to convert configure.ac into configure. I
...
rather than sh. But what would it buy us? sh is more portable than perl
(as measured by the number of
Perl is also quite rapidly losing popularity to other scripting languages
such as Python and Ruby. There was an over five year span without a Perl
Popularity shouldn't be a metric here, in that case sh would would lose, too.
Not really, sh is not going to be replaced for system tasks,
On Wed, Oct 29, 2008 at 5:08 AM, Paolo Bonzini [EMAIL PROTECTED] wrote:
...
Anyhow, I would like to be able to use Perl (or any other language) if
it is found during the configure process.
You can already do that. Whatever is found is placed in $PERL.
Paolo, can you please point to an
On Wed, 29 Oct 2008, Tom Browder wrote:
Popularity shouldn't be a metric here, in that case sh would would lose, too.
:-)
Anyhow, I would like to be able to use Perl (or any other language) if
it is found during the configure process.
Nothing prevents a configure script (written in sh)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Tom Browder on 10/26/2008 5:38 PM:
That sounds like a good thing to me! Somehow I was able to get
autoconf (2.61) to use bash functions in my configure.ac. Was that a
lucky thing somehow?
Any chance of getting (autoconf
That sounds like a good thing to me! Somehow I was able to get
autoconf (2.61) to use bash functions in my configure.ac. Was that a
lucky thing somehow?
Any chance of getting (autoconf configure.ac configure) to be able
to use a Perl script if a macro finds suitable evidence of a modern
Perl
* Paolo Bonzini wrote on Fri, Oct 17, 2008 at 09:18:30AM CEST:
[...] you will want to put something like
$as_debug
at the start of each function (either being empty, or 'set -x'), for
ksh.
Do you want to put that in AS_REQUIRE_SHELL_FN? It's fine by me.
I'd love to. However:
-
Hi Paolo,
* Paolo Bonzini wrote on Thu, Oct 16, 2008 at 06:38:19PM CEST:
Also, the zsh issue has to be understood better (and could be a deal
breaker, though I don't think so).
It basically means that you cannot call exit nor trap inside a shell
function. Nor can you use $? at the start of a
Also, the zsh issue has to be understood better (and could be a deal
breaker, though I don't think so).
It basically means that you cannot call exit nor trap inside a shell
function. Nor can you use $? at the start of a function. But you'll
deal with that anyway since you will want to
Eric Blake wrote:
According to Paolo Bonzini on 10/16/2008 10:38 AM:
Hi all, this is *the* patch to add shell functions to Autoconf at last.
I am submitting it in one piece for testing, but I'm not really calling
for review; for that, I'll submit it split in 12 pieces. Also, the zsh
issue
Hi all, this is *the* patch to add shell functions to Autoconf at last.
I am submitting it in one piece for testing, but I'm not really calling
for review; for that, I'll submit it split in 12 pieces. Also, the zsh
issue has to be understood better (and could be a deal breaker, though I
don't
Paolo Bonzini bonzini at gnu.org writes:
First thought, before I even begin a thorough review:
# AC_CHECK_FUNC(FUNCTION, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
# -
AC_DEFUN([AC_CHECK_FUNC],
-[AS_VAR_PUSHDEF([ac_var],
What do you think?
Agreed on everything.
BTW, I think it's best for your sanity if you wait for the 12 separate
patches. :-) This is just a call for test; the basic idea won't change
even if the implementation details of the shell functions (and not of
the calls) change, so it is safe to do it
17 matches
Mail list logo
